I don’t see why this is happening, though. Why would encoding normally not be an issue, but in this case it would? Not doubting this fact, but would like to know why.
coen.bakker
sodapopcan
JS functions return JSON that gets hardcoded into the DOM, so anything you pass in has to be serializable into JSON. Jason knows how to do this for primitives but is not implemented out of the box for structs. So you have to explicitly say they’re serializable with @derive Jason.Encoder which is metaprogramming a defimpl behind the scenes.
As @benwilson512 pointed out, using @derive will make all fields in your struct available which can be dangerous if any of your structs fields contain sensitive data.
0
coen.bakker
coen.bakker
So swapping phx-click=“some_event” (including phx-value-…=…) with JS.push(…) is not without potential implications, also for performance?
I have been quite liberal in my use of JS. push(…) 
0
sodapopcan
Ya, it’s a bit weird at first, especially if you’re coming from React or the like as even though it’s pretty clear that do_it()) in phx-click={do_it()} is an immediately-invoked function, your brain is thinking it’s a closure that is getting executed on click. Really it’s returning a datastruct that describes a procedure to be executed when clicked. If you inspect the element you can see exactly what it’s returning.
0
sodapopcan
Yes. I was actually going to suggest that this should all just be done with phx events, but I feel I’m always saying that stuff and have been feeling like an old curmudgeon so I decided to take a break from that
But now that I’ve started: for something like this, if you’re making a network call anyway (ie, querying the user by id once opening the modal), I would just keep it simple and store the modal state in LV state and forgo JS commands altogether.
0
coen.bakker
Yes, that’s starting to make more sense now. I designed my modal in a way that it can take any JS command by using attr :on_some_click, JS, default: %JS{}. The JS commands of the attr would then be chained to the JS commands that are hardcoded into the function component. This seemed to made sense initially.
0
sodapopcan
Perhaps you already have something like this but I think even better would be to have routes to your story cards. Then you can just push_patch on clicking a story link. Now you can get the story id from the URL which you can load in handle_params. I feel this is better UX as you now have a shareable URL to a card and better DX as there are slightly less moving parts. This is still possible with JS commands, of course, but I feel they are a bit overkill if you’re hitting the server anyway.
EDIT: I wanted to make clear that it can still be a modal. You can just use the presence of a story_id in the URL for the open state of the modal.
1
coen.bakker
Yes, I have implemented something along this lines before. I like the approach.
I am going to make some changes to the modal, but also the pages from which the modals are opened, because this thread has made me realize that my more general approach to when I am fetching what data from the server is a bit weird. The author variable from the comprehension expression contains a lot of unnecessary data, for example.
I’m glad we had this exchange, because it makes me realize some weak spots in my understanding of LV still.
0
coen.bakker
What would you say is the most important technical differences between phx events and JS.push. So they are not identical under the hood? So the difference between the JSON returned by the LiveView.JS and the JavaScript internals of LV that handle phx events on the client side. I imagine that they are meant to have as little difference between them as possible.
0