These are chat archives for jdubray/sam

Nov 2018
Nov 05 2018 00:05
@dagatsoin :thumbsup: thanks for your input!
Nov 05 2018 00:42

@jdubray, regarding example 2 (Stateful Component): From my point of view it looks pretty wired because you mutate the state inside the view component. Though maybe there is something else which I didn't catch.

I am not an opponent to local user interface state in React if it is a non-functional component and nothing else in the app requires this data. Though if all components are just functions I would definitely move all state to the store respectively to the single model/state with SAM.

I think the clock example is a good idea, so here is what I want to build with the SAM pattern:

A stopwatch with a start, stop and reset button for multiple users. There is only one real user, the others are randomly simulated, each tries to use the stopwatch but only one can actually use it. There should also be some alarms and restrictions under certain conditions like usage time per user. Schedule: completion some time this month.

Jean-Jacques Dubray
Nov 05 2018 01:21

@karlhp in this case we are dealing with a leaky abstraction (setInterval or start spinner), that's why it has to be moved to global state, you can also take the point of view that even if "nothing else require this data", this is by no means a local state, it could well be that in the future this state would be needed, then you need to refactor your app. I really consider that very few components have some local state (as I mentioned, they would be mostly display state, such as a date picker which would display the date drop down or now). But even then you could use a local area in the global state to keep that "local" state like this

 if (data[id] && data[id].direction) {
     model.components.model[id].offset += data[id].direction

Here id is the component's unique id and the local state area is kept in model.components.model[id]. Sorry I never got to finish that sample, so it's not running.