How to Manage Global State in LiveView (Compared to Javascript)

In this episode of Software Sophistication:
- Explaining LiveView.JS why this is required and what problems does it solve?
- Do you need to multiple region deployment in LiveView, and how should it be done?
- How do you handle global state in LiveView in comparison to React and other JS libraries
💻 Pragmatic Studio’s course is the most efficient way to learn Elixir/Phoenix LiveView. Use the course that I use to teach all my apprentices:
➤ Phoenix Liveview Course: pragmaticstudio.com/courses/p...
➤ Elixir Course: pragmaticstudio.com/courses/e...
📝 Have a question about software development? Write a comment and we will answer your question in an upcoming Software Sophistication Q&A show.
🔥 I’ve built an expert team at Or Equals that will revitalize your codebase. Use our experience in Elixir and Phoenix LiveView consulting so you can get back to focusing on the business. Schedule a meeting with me, and let’s chat 👉 OrEquals.com
00:00 Preview
00:14 Intro
00:52 Our Guest: Micah Woods
01:58 Micah's views on Elixir
03:10 Arpan's Mega LiveView Architecture Comment
03:47 What Problems does LiveView.JS Solve?
06:09 Multiple Region Deployment in LiveView
10:07 How do you handle global state in LiveView?
#liveview #phoenix #elixir #software #softwaredevelopment

[@arpanghoshal2579]

Hey guys, thanks a lot for taking the time to reply to my questions. This is was indeed a very nice discussion.
For anyone interested about the process dictionary and live view, this is one way we currently solve the global state problem.
On mount of the top level live view we can store something in the live view process memory/dictionary like so
`if connected?(socket), do: Process.put(:current_user, user)`
So now inside any deeply nested live component I just do `Process.get(:current_user)` to access anything in the global state. This works since all live components will live inside the same live view process and therefore have access to the process dictionary.
(Note: This global state is saved in the process memory/dictionary of the live view process this means once the user disconnects the live view process shuts down and everything in the process memory or dictionary is lost.)
With this strategy I no longer have to pass the common assigns like current_user, current_locale, current_role, current_user_feature_flags, etc down the component tree which can be very tedious, image writing this for every live component
``
However there are downsides of using process dictionary, if something changes inside the Process dictionary then the UI wont update automatically since only assigns are change tracked in live view.
For instance suppose if I change my current role inside some live component like `Process.put(:current_role, :admin)` this wont trigger a UI update but doing `assign(socket, :current_role, :admin)` will trigger the UI change.
So, as the speaker rightly says there is always trade offs :)

[@liveviewmastery]

Thank you! And well said. I pinned this.
Part 2, addressing the rest of your original comment coming soon 😀

[@CodyLandry]

I'm really surprised that agents or genservers weren't discussed as solutions for managing state. To me these can be used very similarly to atomic state frameworks like recoil and jotai. You have to learn a bit about otp, but once you do, you can build a separate state application which you can call into from anywhere in your phoenix app.

[@nacs]

Host called F5 networks a "startup" in the intro lol. Glad the guest clarified they've been around since before 2000.

[@RafiDude]

Great interview!
Thank you for answering LiveView related questions. Anyone working with LiveView will find this content valuable.

[@liveviewmastery]

Glad you enjoyed it Rafi!

[@david_99999]

React uses contexts to solve the problem of passing state through every component layer. The downside is that if your component subscribes to a particular context, it will re render every time the context changes.

[@pauloffborba]

Great talk! 🙏🏻

[@liveviewmastery]

Thanks Paul!

[@asdf3568]

LiveView solves the problem with the complexity of SPA's

[@michaellatta]

For multi-region the only real approach is to partition the data for geography and replicate to other regions.