These are chat archives for jdubray/sam
@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.
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
updatemeans responding to some event and/or setting a property.
===comparisons which are cheap and fast, no key iteration needed.
next !== previous
@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...