These are chat archives for jdubray/sam

Jun 2018
Fred Daoud
Jun 14 2018 00:00

@devinivy interesting! what do you think of it?
as for me, I don't particularly like event busses, having writing a large SPA with it and finding it difficult to follow.
I also wonder about passing a single state object all the way down to every component. This couples components too strongly to the top-level structure, and makes reusable components difficult, wouldn't you say?
Finally, this part:

Whenever a store updates its state, you update the counter in the store. When a component checks if it should re-render, it compares the last known value against the current value of the counter. And if the new value is higher, it re-renders. This means no more need for (shallow) object compares anywhere.

Shallow object compares are one-liners; no more of those, but then you need to add counter updates and comparisons. To me it just seems like exchanging one thing for another without any gain.

If I'm wrong or I missed something, please do tell me, my mind is open :)
david kaye
Jun 14 2018 00:25
@foxdonut My two cents here: I think the issue with object comparisons is that comparison means iterating keys, which means multiple comparisons at the time of render(). If we have a single key dedicated to recording last update/counter/vector on an object/component, we can skip key iteration at both update() and render().
Should qualify that: update means responding to some event and/or setting a property.
Fred Daoud
Jun 14 2018 00:30
@dfkaye_twitter it says shallow object compares; these are just === comparisons which are cheap and fast, no key iteration needed.
@dfkaye_twitter it just seems to me that implementing a vector clock, or adding a dependency to one, and taking care of incrementing the counter, to finally compare the counter in order to determine whether to re-render, is actually more work than just next !== previous
Arguably, trying to determine whether to re-render a component is often premature optimization; if you're using a good/fast virtual-DOM library, that's the whole point, you don't need to micromanage re-renders. I recently wrote a short article about this.
devin ivy
Jun 14 2018 01:20

@foxdonut i generally agree with your assessment. i mean, event busses don't bother me. whether you use an event bus, streams, observables, or plain old functions, i think for this purpose they are pretty much comparable. i would probably not use an event bus as a matter of preference, and to make any middleware simpler to write.

i haven't wrapped my mind around the upsides of using vector clocks for this, but i am interested in seeing what the approach looks like in practice. i am interested in paths forward for performance and finer tuning of re-renders, but i agree we tend to way over-optimize here.

i would definitely avoid passing around the entire state object—i find SAM's "state representation" to be critical to allow for refactoring.

as for FSMs, hmm...

devin ivy
Jun 14 2018 01:35
i guess the most i can say for now is that i appreciate @jdubray's points about FSMs not being a great way to model state in general, but i can see them being a good tool to help handle some UI transitions.
david kaye
Jun 14 2018 04:05
@foxdonut - I was not aware that shallow comparison means strict equality checking between next and previous
Jean-Jacques Dubray
Jun 14 2018 07:51
@foxdonut totally agree
@devinivy that's why I feel SAM being aligned with FSM gives you the best of both worlds because, yes sometimes it's easier to think in terms of control states (even Dr. does it with the PC variable), but often you need to reason in a pure temporal way (e.g. cancellations). Even when you use control states, SAM alleviates the need to design an overall FSM, which would be too rigid and difficult. SAM allows you to model "local" control states and transitions.