Passing comprehension data from inside function component up to call of that function component

coen.bakker

I have story_cards that render a list of authors, among other things. Clicking an author should open a modal, via a function set_modal_data/1. This function needs the to be passed one author (not all authors).

Is there a way to pass the set_modal_click/1 function to the story_card function component call (e.g. <.story_card ... on_author_click={...}/>? Currently, I am using slots to be able assign the set_modal_click/1 to the phx-click that should open the modal.

# current solution
<.story_card
  :for={story <- @stories}
  story={story}
>
  <:author let={author}>
    <span
      class="pub-cover-author-tag"
      phx-click={set_modal_data(%{"id" => author.id, "modal" => "user"})}
    >
      <%= author.username %>
    </span>
  </:author>
</.story_card>

# hypothesized solution
<.story_card
  :for={story <- @stories}
  story={story}
  let={author}
  on_author_click={set_modal_data(%{"id" => author.id, "modal" => "user"})}
/>

21 comments

/phoenix #bindings #liveview #callbacks

2 1246 21

2023-05-06 21:51:45 UTC

Showing Posts 11 to 20

Show Best Posts
Show All (oldest first)
Show All (newest first)

coen.bakker

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.

Post #11

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.

Post #12

coen.bakker

I see. That was the missing piece for me.

Post #13

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(…)

Post #14

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.

Post #15

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.

Post #16

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.

Post #17

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.

Post #18

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.

Post #19

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.

Post #20

Load more posts (1 remaining)