Thank you for your suggestions.
Regarding getters in the model and pushing precomputed maps to the view. I startet with this approach (which also is the re-frame approach), but I abondened it for the following reason:
When the view is completely stateless, all the intermediate ui state and it’s management has to move somewhere else and the reuse of ui components get’s divided into two parts that have to be synchronized.
An example: Given a page which displays a person (just the name) in an expandable material ui card. When the card is expanded, details for the person get displayed. For the details a separate call to the server/database is required.
In my current architecture the view has it’s own state (card collapsed/expanded) and subscribes to the database query by itself instead of getting data pushed. That way there is a person details component, which only get’s rendered, when it’s parent (the card) is expanded. You get lazy loading of the details for free and don’t have to manage this state by yourself. You get a reusable expandable person component. If you want a second person card on the page you just put a second view component there with a second person-id parameter.
In the push all data to the view architecture such components seem a lot harder, because you can not package all the functionality in one view function. You have to have some code which manages the view state (expanded/collapsed) and then the render function which uses this sate. When you need a second person card on your page, you have to put it there and then you have to refactor some other code which previously was a simple boolean person-expanded? into a map of expanded persons and then more code which distributes this values to the view components. And then you have even more code which subscribes to the db based on the expanded states and passes the results to the view. Following this architecture, you will gat a tree of view components plus a corresponding tree of state somewhere else which kind of matches the view tree. And since a react application already has the state (the component tree) where corresponding data/models can be put alog with the view components, managing another tree of state by hand seams a waste of time and introduces more complexity.
I see, you get pure view functions from the stateless view. But I don’t get how this could be worth it. Will see when the app grows… 