These are chat archives for jdubray/sam

5th
Dec 2018
Jean-Jacques Dubray
@jdubray
Dec 05 2018 02:31
@nerdo I forgot to mention that the most up to date implementation is this one. The view is based on Google's lit-html which I like a lot.
I would recommend that you decide on a component model. I would not create a class Actions, or put all the acceptors in the Model. A lot of the thinking around the implementation was shaped in this forum, and I really want to stay at the pattern/principles level rather than point people at the best implementation. In reality, it depends on what you are trying to do. Your implementation might work, or might scale well (in scope).
The Components folder shows another way to break down actions, acceptors and reactors.
Jean-Jacques Dubray
@jdubray
Dec 05 2018 02:37
In general, I try to avoir OOP as much as I can. Over the years, I came to the realization that OOP, FP, RFP... and SAM are all patterns rather than a structural programming model.
Dannel Albert
@nerdo
Dec 05 2018 03:17
I'll take a look at that repo, thanks @jdubray I see from the readme in that repo that it is a boilerplate, which is what I intend to eventually create/settle on and re-use. My main goal in adopting SAM is to be able to separate the "business" logic from the UI in a way that makes it easy to swap out UI frameworks with few or no major sacrifices. I still have a lot of experimenting to do before I settle on anything, but so far the SAM pattern seems the most promising.
Dannel Albert
@nerdo
Dec 05 2018 03:24
I guess I don't really see the rationale of trying to avoid OOP with SAM. The documentation on sam.js.org describe parts of SAM as functions, but the implementations I've seen don't seem to conform. State, for example is described as "a pure function" but in the implementation sI've seen, state is actually an object with functions, one of which happens to be a "computeState" function. Rather than fight what seems to me to be the natural structure, I think OO should be embraced. In the code samples I've seen it appears to be using the most basic form of OO - an object with methods, but I don't see a reason to shy away from OO, classes, and all that ES6+ has to offer.
Dannel Albert
@nerdo
Dec 05 2018 03:46
When you say you recommend that I decide on a component model, I'm not really sure what that means. Can you clarify?
Also, I thought the Model was responsible for accepting changes proposed to it. Why do you recommend against putting all the acceptors in the Model?