Changing phx-update dynamically based on assigns?

Phoenix Forum Questions / Help
,
1

Working on a game that uses both client-side JS and LiveView, I’m facing a challenge that currently boils down to the following question:

Is it at all possible to dynamically change phx-update on an element based on assigns (or is the “ignore” value prevents changing itself)?

If it’s not possible, would you be able to come up with any work-around idea that I could explore?

1 Like
2

I haven’t tried dynamically changing phx-ignore. Something to explore would be placing all the things that need to be ignored in a single phx-ignore container.

If the contained elements depend on changing data, you could store the data outside of the container, for example in data-* tag attributes, and access that from JS.

3

Thanks for the suggestion, I hope to find a simpler way, though. Basically, I need that container to be handled by LiveView at some condition, and by the JS otherwise.

4

Would changing the id of the component declaring the phx-ignore work? That should remount it and the “ignore” value of phx-ignore would then also be ignored?

1 Like
5

This sounds like a very fresh idea, will give it a try :+1:

6

What exactly do you mean by “the container”? Couldn’t you set the phx-ignore on a child element then?

1 Like
7

An HTML element.

Thanks for chiming in, let me add some further details.

I need a single HTML element (a game board) with phx-update, behaving such that I can toggle the phx-update value from ignore to replace and back dynamically, w/o reloading the page.

8

This worked like magic for now, thanks!

1 Like
9

So both LV and the JS are meant to affect the children of that element? I’d strongly suggest not having concurrent modifications to the DOM from different sources. If by replace you mean something like “new game” changing the id to force the dom node to be replaced (and hooks to remount) would imo be the option to go for.

2 Likes
10

Yep, this is exactly why I came to need this switch. You almost guessed it right about a new game, only that it’s about taking turns: if it’s a player’s turn, I want the board to be fully controlled by JS (to provide instant optimistic game board updates), sending the moves to LiveView (so that all other players get the updates in real-time). That’s when I need phx-update="ignore". Otherwise, the board gets updated from the LV (meaning, phx-update="replace").

Hope, it makes sense. Maybe there’s an even better approach to the above.

11

I wonder how you came to this knowledge. I couldn’t find any mention of this behavior anywhere. Would you be able to point to a spot in the documentation? Or is this some common sense that I simply missed? Thanks again!

12

Honestly I don’t know how I came to it. I just figured something has to be used for LiveView to “target” specific parts of the page with updates. I just drew the conclusion that if an ID changes like that, it has no choice but to rerender the whole thing inside the tag that got a new ID (because to the LiveView it’s like the element wasn’t there to begin with, i.e. it is new).

2 Likes
13

I’ve been given this solution before (by @LostKobrakai at that) and when I didn’t think of it myself, it’s sorta half-common sense but agree it could be more prominently talked about in the docs. It’s just a matter of how and where. Perhaps a section on the importance and power of ids within LiveView since everything essentially works off of them? This extends out further than phx-update to be clear. I’m currently working on an inherited codebase where there are random ids assigned to LiveComponents as a convenience measure which is Bad. This is a mistake I made myself in the past and when you’re starting out is an easy mistake to make—“Ok, I need to give an id to a component, but does it need to be deterministic?” Common sense may dictate that it does but, you know, it’s not always so common as they say. It’s something I had been thinking about recently… like a “Drilling in the concepts” section or something? I really didn’t come up with much of a solution. The key would be discoverability.

4 Likes