These are chat archives for jdubray/sam

7th
Mar 2017
majo44
@majo44
Mar 07 2017 08:17
Hello
What do you think about such implementation of SAM-like arch:
https://gist.github.com/majo44/564e1cfb969d7218d00b6ea2e8a82ca5#file-1index-html
My motivation was to made this simple as possible, without frameworks/libs, with only essence code, without providing many abstractions layers, ceremony code.
Jean-Jacques Dubray
@jdubray
Mar 07 2017 12:51

@edmulraney thank you for sharing, that is musing to my ears

First off state is going to become mutable. At the moment state is immutable at any given time. But given that views are snapshots of the state anyway, it makes no sense to also make the state immutable — it creates unnecessary work for the garbage collector so we’re tossing it out.

Jean-Jacques Dubray
@jdubray
Mar 07 2017 13:08
@majo44 thank you for sharing this sample, it will take me some time to parse your code. I would say at a high level that proxies may not be the right approach for the model since the model does not expose getters and setters. In a reactive loop, I am not sure you want to use getters and setters at all. The actions create proposals (no setters), the state functions create properties for the view (no getters). But that's really my first reaction, I need more time to go through your code.
majo44
@majo44
Mar 07 2017 14:23
@jdubray thanks, I'm very interested of your opinion. In general my intention was to provide much simpler implementation of 'predicable' state than redux/flux or sam. This solution is not inline with SAM (or any other arch). Firstly I want to know that such solution creates really predicable state, and is covering all cases (async, nap, ...), secondary I want to compare this with existing solutions :)
I used Proxies because this was simplest/cheapest way to implement middlewares pattern, but this can be done in totally implicite way.
Setter (and getter) is just a function (can be pure), nothing more. Inn my example action do not creates setter but is propose next state to model, which will be accepted/rejected/decorated by middleware (which is setter).
What is key point here is that there is one contract between view-model-action which is a state (this can be advantage eg. when you have bff, or disadvantage), and the second is that actions do not have to know anything about how the model process proposal.
Jean-Jacques Dubray
@jdubray
Mar 07 2017 15:18
all right, let me go through your code in details before I comment further. Could you elaborate what you mean by predicable state?
majo44
@majo44
Mar 07 2017 22:44
For me this mean, that the system will never comes to incorrect state (eg some conflict values).
majo44
@majo44
Mar 07 2017 22:49
Or more Redux related definition, that the system always ends in same state after apply same set and in same order of operations on it.