State Management with Phoenix LiveView

Hello,

I think that MUTATIONS mutate, shouldn’t be used in your code because they are terms associated with graphql(absinthe) ecosystem and a lot of people will get confused.

It may even have conflicts.

I hope you found this info useful.

Good luck with your project..

Thanks @wolfiton, however the naming convention is given by the Vuex flux flow. Unless somebody uses these 2 libraries side-to-side, I don’t expect the naming will be confusing though since the application contexts are quite different.

So, 2 major things happened since I started this thread:

1. I finished a first implementation of LiveEx - a state management library for Phoenix LiveView. Please check it out and comment, recommend, contribute to it

2. I wrote on Medium about how to use the library. Hopefully, this article clears up what the flux pattern is, why it might be important for LiveView, and how to use the LiveEx dependency.

Also, some other cool things happened:

3. Chris McCord pointed out the assign_new/3 function to share parent state with child LiveViews. I will look further into this function and will check out how to use it in LiveEx.

4. Guido Tripaliresponded to my Medium article and suggested to bring the discussion about how to manage state to this forum.

I would like to pick up Guidos suggestion and start a discussion about what you think about how state can be managed best between nested LiveViews. A couple of questions to start with:

1. Have you run into issues already where state changes became unclear? If yes, how did you solve this?
2. Do you think that a flux based state management like implemented in LiveEx will be useful?
3. Do you think state management should be baked into the Phoenix LiveView library or should third-party libraries offer that functionality instead?

I’m curious about your answers

IMO state management should (eventually) be baked into LiveView itself. With React, navigating the many flavors of 3rd party Flux libraries has been a productivity killer.

just to give out a sign of life! After commenting your article on Medium I’ve start writing my thoughts about the status handling, but I realised that it will take me much more time to elaborate a satisfactory analysis to share with all of you here, because the matter have complex structure and maybe can be useful to have a sort of ontology of which are the actions, the events and the states involved in a typical full Phoenix app.

Very cool library. I’ll be following the development.

I agree with you. At least a certain combination like React/Redux should become a standard so that the decision making effort is mitigated.

Looking forward to your findings

Thanks! Feel free to test it and potentially contribute

Does current implementation assume that there is a single root LiveView for the whole app, and all routes are implemented via child live views? I mean, if I want a global state shared between all live views.

For now there is a one-to-one mapping between a store and a root LiveView, and if I have something like live "/one", OneLiveView; live "/two", TwoLiveView, live views One* & Two* will get different stores and state will not be shared between them, right?

Also, in the readme I found a notion of feature/integrate-genserver branch, which seems capable to share state between live views, but I haven’t found the branch itself, has it been removed for some reason?