Reusable LiveViews - automated messaging between parent and child LiveViews

Phoenix Forum Questions / Help
,
1

For example let’s say i want to implement this flow with autocompletes (like select2):

  1. pick a department from first autocomplete
  2. pick a user under that department from second autocomplete (that only shows selected department users)

The autocomplete should be reusable.

The problem here is that this requires some kind of reactive data passing between parent and child. For example:

  1. a LiveView form is rendered that has two autocomplete LiveView’s: departments and users
  2. department is changed in departments autocomplete
  3. parent form would receive this change
  4. parent passes this change to child users autocomplete
  5. users autocomplete will filter by selected department.

At the moment there seems to be only one way how parent can pass arguments/parameters to its children it uses: session, but there is two problems with it:

  1. It is not private: data goes through client and is publicly readable
  2. It is not reactive: when the assigns change in parent view that are used in session there is no mechanics to update them in child.

This could be achieved by custom messaging between the LiveView processes but i think this is such a common pattern and potentially complex to implement that it should be abstracted.

What makes this critical is that it is not straight forward to fallback to any javascript components in LiveView. If LiveView renders (after first load) how would javascript initialise itself on this changed content? So i think then that LiveView should be able to replace javascript libraries like select2.

If this makes sense then what are your throughs of how this should be implemented and if similar thing is planned in LiveView itself or should it done in third party libraries?

5 Likes
2

you can pass messages between them… or using pubsub

say like here Phoenix LiveView: How would you build forum (Discourse-like) in it?

though “the best pattern” is surely emerging… and it always depends on the specifics…

3

I agree with both of you seems like there are two patterns, both of which can be handled with messages/PubSub but seem like they will be common enough to warrant some support.

  1. Communicating between parent/child views - yes you can wire them up along the lines of the example above, but one would hope there is a way to do this that is simpler/more straightforward since it is likely to be so common.

  2. Broadcasting updates to multiple users (e.g. a chat room or game). Again you can obviously do this with PubSub as shown in the user management examples, but you can imagine this being very commonly required. Without speaking to the internals, I like how drab includes a macro, broadcasting, that let’s you specify a topic for a view, and then in an event handler you use one function to update the calling view, or you can use a different function to update all the views subscribed to the broadcasting topic. I’m not suggesting Live View has to do it this way, or even that it is all that hard to roll your own PubSub to do this, but it seems reasonable to give everyone a common way to do it and that level of simplicity is pleasant.

None of these are criticisms of where Live View is now. I just wanted to agree that these seem like good candidates for future work as the patterns get clearer.

1 Like