I was listening to Richard Feldman’s talk on relational immutable data. One of the big takeaways from this talk is that when dealing with immutable data we want to avoid nested data and have a single source of truth.
In Elm this is very difficult when we have things that are for all intents and purposes are a “component”. I define a component as something that has it’s own view model and update function. Often we don’t need them but sometimes they are unavoidable like Elm-sortable-table and page navigation. In the Elm spa example, the approach in elm-spa-example suffers from a few problems:
- Potential for multiple sources of truth if pages have shared data.
- We have a cardinality that is too high in our update function. We need to account for cardinality(Msg) * cardinality(Model) amount of different values when in practice the cardinality is only Msg. There are a lot of cases that we have to ignore that are invalid states that should never happen. We also have a default case
(_,_), which means that there are no static guarantees that we’ve handled all pages.
- It’s cumbersome to modify components and adding new ones.
I made an attempt at implementing a relational component structure and you can find the result down below with the pros and cons of this experiment.