Make `JS.t()` a public data structure, or json serializable

I’ve build custom executions of js commands just be sending the string and using LiveSocket.execJS: JavaScript interoperability — Phoenix LiveView v1.2.5

That works of course, the problem is that liveview doesn’t control the rendering of the toast element(I’m using toasts here as an example, but the same applies to other “js sprinkles” that render content with js in a container with phx-update="ignore"). For that approach to work I’d need again to serialize the js command, which apparently isn’t possible with the current public apis.

I’m not sure I understand the issue then. You can call execJS whenever you need.

execJS is JS code; the point is to not have to drop to JS code to run a JS command. It also relies in me having access to the serialized JS command, which I don’t.

Normally, with templates, you can do this:

<button phx-click={JS.add_class("active")}>Foo</button>

However, in my case the rendering of the “button” happens in JS code, outside of Liveview’s reach. This means that I need to write a JS hook or some other code to run that command or something equivalent. In other words, I need to write specialized JS code for each interaction I want to add to that dynamically created element and I want to avoid that.

To avoid that, I can tell the js rendering code to render the attributes I pass as the payload for the “show toast” event, meaning I can leverage phx-click for this and not have to worry about anything else in the JS code, letting me write elixir code like:

socket
|> show_toast(%{message: "Something happened", actions: %{"Undo" => JS.some_command(...)}})

Which would render the following in JS land:

<div class="toast">
  <span>Something happened</span>
  <button phx-click="serialized js command here">Undo</button>
</div>

The problem is that there’s no public api to serialize the JS struct here, so it will throw an error. I can still do that with Jason.encode!(JS.some_command(...).opts) but because the :opts is private api I have no guarantee this won’t break in upcoming liveview releases, nor that it will keep being JSON.

The whole point of the exercise is to not have to resort to hooks or any other JS code whatsoever. phx-click and similar are already stable public api, and they rely on some sort of serialised JS command as the value, so I think it wouldn’t be a stretch to expose a to_string or encode function to Phoenix.LiveView.JS to support this use case or any other use case that escapes templates yet can still avoid the burden of having to drop down to writing js hook/bindings/whatever.

Oh. I thought it would just implement to_string already. Thinking about this some more I might have used Jason.encode!(command.ops) in the past as well. It would certainly be useful to be able to use the serialization phoenix uses.

This is a reasonable proposal, maybe it needs to go to the Proposals section on the forum for better visibility?

There is still no official way to serialize JS commands on the server side.

Here’s an example use case of exec’ing server-pushed JS commands: Animating list items with LiveView streams - #6 by rhcarvalho.

What I found is that, in testing, JS commands are serialized using Phoenix.HTML.Safe.to_iodata(), but that HTML-encodes the input, making it not directly usable on client JavaScript (e.g. " becomes ".

https://github.com/phoenixframework/phoenix_live_view/blob/f5ee3f88b91cd51f0711c07e207ec992cc64b3f3/test/phoenix_live_view/js_test.exs#L1136-L1141

https://github.com/phoenixframework/phoenix_live_view/blob/f5ee3f88b91cd51f0711c07e207ec992cc64b3f3/test/phoenix_live_view/js_test.exs#L67-L70

What works is what is described in the OP, JSON-encoding the :ops field of the struct, with no forward-compatibility guarantee.

LiveView only exposes APIs for working with the encoded JS, so using Phoenix.HTML.Safe for serialization is the best approach, I’d say.

Thanks for the answer!

Phoenix.HTML.Safe treats the input as if it would be placed in a generic HTML context. When using JS commands within a HEEx template, the engine is smart enough to escape the resulting string according to context, most often within an HTML attribute (this is the common case that works great).

In terms of APIs for encoding JS commands on the server, are we limited to those two options?

The OP wanted to encode the value on the server side and send it down to the client via push_event that encodes the value in transit as JSON and becomes a JavaScript event, with JS payload on the client. If encoded with Phoenix.HTML.Safe, JS code could need to manually unescape HTML entities like " → ".

I’d love if there would be a JS.to_json(_iodata) function. I know phoenix cannot implement any json library protocol given it doesn’t depend on a specific json library. But having such a function would allow anyone to implement the protocol for the library they’re using.

Ugh, sorry. I thought we’d handle unescaping in execJS, but I was mistaken. So yeah, I don’t think there’s anything that prevents us from implementing String.Chars.

https://github.com/phoenixframework/phoenix_live_view/pull/4044

You’ll still need to do write it like the following, but you can implement Jason.Encoder by just delegating to to_string and then omit the extra to_string call.

push_event(socket, "do-something", %{data: to_string(JS.add_class("foo"))})