harmon25
Redex - Predictable Server Side State Containers - à la Redux for Elixir
https://github.com/harmon25/redex
Here is part of a proposal/idea for bringing server side state - I.E LiveView minus the view bit - into an SPA or whatever UI. I envision this working on mobile, web, maybe even Scenic, does not need to be coupled to JavaScript or Phoenix.
This is following up on the thread: Phoenix LiveView vs SPA - #48 by harmon25
I have played around a bit with the API and it is very doable - still some work to finalize it. Not in a currently working state - but should be soon.
I am sure people who are fully sold on LiveView and using it in its current state don’t really get why.
The flip side are all of us who have spent the last 5+ years mastering the JS stack/ecosystem, and just cant throw out the baby with the bathwater…
So, onto the real questions.
- Is this a good idea?

- The API look OK?
- Foreseeable challenges or issues?
Thanks everyone who gave this a read!
Most Liked
sb8244
I’m not sure what it would look like, but it would be interesting to see this integrated into redux as a proxy that reflects the state and updates it based on changes (from Channels). Bonus points if it can be combined with an existing store so that you can have some client side redux state if necessary (not everything is serializable).
I’m a huge fan of redux, and I think that a lot of interesting use cases can come from separating your store across boundaries. An example of this is the webext-redux library, which allows for redux state to live across a Chrome extension background/foreground boundary.
One use case that becomes trivial to implement if the redux state is synced with the server is that you could have 2 different pages staying in sync with each other by subscribing to the same state reference on the server.
KekKekington
So if I understood correctly you’d be able to use whichever frontend library you want and keep state on the server? That sounds very cool and could mean a bit more flexibility to select tools for a project.
harmon25
Last Post!
harmon25
I did think about this. It is an awful lot of processes for just a map.
There maybe a tiny concurrency benefit when ‘casting’ the action down the tree.(if it’s big enough)..but probably doesn’t outweigh the msg overhead. Also have not really tried, but failure may also be isolated…an action that crashes a reducer might some how be recoverable at only that level and below on the state tree…
Am considering @sasajuric ‘Parent’ to flatten that tree…each aggragate reducer is a genserver and a dynamic supervisor… So could remove atleast 3 processes from that tree I believe.
If my thoughts are wrong, would definately consider a simpler design…
Every stateful LiveView is a process, so if they can do it… ![]()
Thanks for checking it out!
Popular in Discussions
Other popular topics
Chat & Discussions>Discussions
Latest on Elixir Forum
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #elixirconf-us
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #metaprogramming
- #security
- #hex









