I’ve been building some projects using Phoenix LiveView, and have read the source code of quite a few more projects made by other people (thanks, Phoenix Phrenzy contest!).
One thing I am seeing, is essentially a dichotomy in two approaches to working with state and interactivity, when working with LiveView-powered applications that are essentially ‘single-page’ (i.e. rather than one or multiple pages with multiple independent LiveView snippets, the whole interface is driven by LiveView).
Approach 1: “Shallow State”
In this approach, we have many nearly-independent LiveViews/ (stateful) LiveComponents that mostly work with their own
socket.assigns is a map, and because all of these components are stateful, the data that is stored and the communication between them is mostly ad-hoc, i.e. non-normalized.
Approach 2: “Deep State”
In this approach, we have a single LiveView with potentially multiple nested (stateless) LiveComponents that contains the state in a (deeply) nested map in its
socket.assigns. Most or all changes that come in travel through this single LiveView’s
handle_event and potentially update (some nested part of) its
socket.assigns consists of one or a few Elixir Structs, which makes it very clear what kind of data to expect, i.e. the data is normalized.
Using this approach, it is possible to extract most of the domain-logic out to its own separate module(s), making the code easy to test. Of course, you do end up with more code since you add a/some layer(s) of abstraction between the LiveView-module and the place where the actual state-transition logic happens.
This kind of architecture has strong similarities with first-order functional reactive programming (also known as ‘the Elm Architecture’(TEA)).
Now, I don’t know which approach is better suited for what kind of situations, but I find it very interesting to see that there are these two sort-of opposed kinds of working with LiveView going on, and I’d love to start a discussion on the pros and cons!