These are chat archives for jdubray/sam

19th
Mar 2018
Victor Noël
@victornoel
Mar 19 2018 10:21
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.
Daniel Neveux
@dagatsoin
Mar 19 2018 12:34
Do you have a way to know what changed into the model from the State function ?
Victor Noël
@victornoel
Mar 19 2018 12:37
@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 :)
Janne Siera
@jannesiera
Mar 19 2018 12:53
@victornoel if your state functions are pure and don't actually mutate the state I see no problem with applying memoization as an optimization technique.
Victor Noël
@victornoel
Mar 19 2018 12:55
hmmm, could be an idea yes @jannesiera
Daniel Neveux
@dagatsoin
Mar 19 2018 12:56
@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)
Victor Noël
@victornoel
Mar 19 2018 13:07
yep, it's true, but it makes thing much more complex with that :/ but I suppose there is no silver bullet :)
Daniel Neveux
@dagatsoin
Mar 19 2018 13:14
Yes, that means more SAM code :)
devin ivy
@devinivy
Mar 19 2018 13:54
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!
Victor Noël
@victornoel
Mar 19 2018 13:56
@devinivy yep, I will go without any optimization and just put stuffs where they seem to belong the best, and we will see how it goes from there :)
devin ivy
@devinivy
Mar 19 2018 14:37
: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.
Janne Siera
@jannesiera
Mar 19 2018 15:57
A memoize decorator would already get you a long way, no? https://github.com/developit/decko
Victor Noël
@victornoel
Mar 19 2018 16:42
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)