These are chat archives for jdubray/sam
To bring my story to the table I'll lay it out by saying that I've been creating a large app with many options. I've been through a number of technology stacks and at the end of the day I had a desperate feeling of having to save the higher purpose of my app from the straitjacket frameworks and languages that have been available.
So what did I end up with? Essentially a state-machine and execution flow pattern that is feature driven and where it no longer really matters much what damn framework I use or if I use one at all.
How did this come to be? Well first off the app I'm building involves multiple tools that need to be used together in a natural way and then there were the endless variations that my industry wants, so I needed to accommodate all this.
So how did it turn out? In the end my app was stratified into configuration based models, logic modules, UI surface widgetry and the core thin client, with almost all of it residing on a BaaS.
Configurations turned out to be a key, with two primary ones, a schema for the apps content and what I sometimes have called a manifest, a one atom type of model representing the apps constitution.
Lets focus on the app constitution, which is comprised of many states. Since it is a configuration that can be stored, activated and exchanged the JSON format turned out to be very handy. The JSON graph is then a map with states that can be transitioned between.
From here I discovered all the ways I can activate states and what all their possible params expressed as simple KV pairs could be. This arrangement afforded me a place to put everything from scalars to nap auto invoked ops plus the total environment a given app tool/mode/state needed to work with, in an open ended way.
So I had all this in the bag and arranged, then I encountered Cycle.js. The immediate thing I like about it is actually simple but a nice abstraction not seen in other frameworks, namely the Intent part of the MVI pattern that Cycle.js promotes.
In my design up to the time and had already been calling this abstraction the membrane. Because I wanted to separate myself as much as possible from the DOM event capture mechanizm and jump straight back into my logic module functions. I had really started hating frameworks by this time and did not want to be entangled in them more than necessary.
OK, that brings the story to now where I have the patterns I've discovered and then MVI and SAM on either side. I believe that there is a good synergy between all patterns.
However, I have found that the Cycle.js community is largely sold on the idea that Rx can be used to dynamically calculate all state and therefore Cycle.js has a very under developed and meager model. So, I'm glad you have put forward SAM because my overarching app pattern is a hybrid between MVI and SAM.
I'll end this here for now, I'm hoping to align the key entities from MVI and SAM and see what that gives. Also, I have some more ideas on how this works itself out in code flow.
SAM_componentproperties and wire it somehow with cycle.js API.
translating model state to DOM
My take on it is that you don't need either React or Angular. I am certain you could show me an example or two where they add value, but for 98% of the cases I see, they simply don't (compared to the incidental complexity).
you still have to write that machine
well, the problem is that you have to write that code anyways, it's not like writing the machine is optional, you may think it is, but in the end the code you write must be equivalent to the state machine, in simple cases, you can use approximations and get it right, but on average the state machine will be more correct and save time for more complex projects
you end up rolling your own "framework" anyway
I'd like to challenge that, with the proper factoring, I would argue that the need for a framework goes away.
that's where frameworks kill you and push you to use stuff like BFF.<- i'd disagree there. the problem is that most frameworks dont make a recommendation there