everytime I find myself trying to add something in the State to derivate the data in the Model to something usable by my views, I end up moving the transformation to the Model because if not the state would be recomputing heavy stuffs every step (because the model knows when data mutate while the state does not…). Is that normal? Am I missing something?For example I retrieve some big datastructure from the backend with an action, it is proposed to the model (via an event to notify the model of the information), the model mutate its data based on this new information, and then the state is rendered with the current data of the model, and the state should compute some aggregated information on the big datastructure, but it's big, so it's costly to compute this every time the model change. So I find myself doing the computation in the model only when I know the big datastructure actually changed.

@dagatsoin I don't, or at least, I don't want to if I can avoid it (since the whole idea was to have the model the master of the mutations, but maybe I'm wrong about enforcing this constraint). I can always "hack" it because I'm using observables to actually transport data from model to state to view (one for model to state, and one for state to view), and because I'm using immutable datastructure, I can take advantage of it, but it feels wrong to me :)

@victornoel SAM enforces State has full read access to the model. But you are free to get it the way you want. Eg: just the difference between the old/new model ot the full model, or both (I choosed the third option for my part, like in Vuex)

depending on the wiring you're using, you could certainly express the state representation as "computed" values (i.e. with mobx). it's a performance concern and could very easily be prematurely optimized.

with vanilla js, it's definitely simplest to recompute state just like you're going to recompute the view!

:thumbsup: i similarly wonder just how far vanilla js can go! SAM examples, meiosis, etc. rely on recomputing/rerendering everything (which brings great simplicity). in the past when i've brought this up the answer i've heard is to split your application up into multiple roots once you run into perf issues. i'm definitely interested in other options, though.

well I wouldn't use that, each of the memoization I would like to do would have some kind of domain-specific configuration (sometimes I should keep only the last one, sometimes it depends on some of the arguments, and so on)