State Management with Phoenix LiveView

Recently, I completed a first product with Phoenix LiveView and ran into the classical problem that it became unclear how, when and from where the State of the UI was changing. Facebook tackled this problem by developing the Flux pattern, which was adopted by every major SPA Framework out there (e.g. Redux, Vuex, Ng-Redux). I took the time to write an example Framework/Module that tries to replicate the Flux pattern inspired by how Vuex was implemented. I created an Example repository here. The core logic can be found here. Your opinion on the usefulness of such a library and comments/improvement suggestions on the implementation are most appreciated :slight_smile:

2 Likes

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…

1 Like

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 :slight_smile:

  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:

  1. 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.

  2. 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 :slight_smile:

4 Likes

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 :slight_smile:

Thanks! Feel free to test it and potentially contribute :slight_smile: