These are chat archives for jdubray/sam

19th
Apr 2016
Jean-Jacques Dubray
@jdubray
Apr 19 2016 08:26
@foxdonut @brusand thank you for this discussion
as Bruno said, Actions can invoke 3rd party APIs to validate / enrich the user data (e.g. getPostalAdressFrom(userAddress)) before it is presented to the model. In particular the action itself could be a 3rd party API which would present data to the model (using a OAuth token for instance).
Jean-Jacques Dubray
@jdubray
Apr 19 2016 08:34
Theoretically the CRUD operations should be in the nap(), the actions would position the model to fetch/update the back-end store. Practically this approach makes things a bit more complex for virtually no gain. IMHO, the CRUD that persists the model should be dealt with in the Model since the State can be truly rendered once the persistence layer has returned its status/data. When the model runs on the server that would make it harder to render the view.
Alternatively the Read operations could be implemented in the actions and proposed to the model that could facilitate caching with an attractive level of granularity, if would also logically give a chance to the model to accept/reject proposed (cached) values based on the other property values. For instance hold the last four digit of a bank account number by default or if the model allows it, hold the full account number.
Jean-Jacques Dubray
@jdubray
Apr 19 2016 08:44
I agree with Bruno, you always want to wrap the AJAX calls in an action and have nap calls your action, I would keep nap as: if (condition) { invokeAction(g(model),present) }
dnson
@imnutz
Apr 19 2016 09:32

hi guys,

Thanks for great discussion so far about SAM, I learned a lot from that. I have built a small Contact Manager using SAM pattern, I posted source code to github, here is the repo:

https://github.com/imnutz/sam-csp

Would you please take a look and have comments on it?

I’m not good at talking about state, imitation, mutation… so I hope my code can explain my understanding about SAM.

Fred Daoud
@foxdonut
Apr 19 2016 12:40
thank you for the feedback @jdubray
I had a quick look at your code @imnutz , I like what you are doing with csp and snabbdom, but as far as SAM is concerned I will let the experts speak :) I am also interested in what the comments will be on your approach.
devin ivy
@devinivy
Apr 19 2016 12:44
yeah, the idea of using snabbdom with SAM sounds much nicer to me than concatenating bits of html together.
Fred Daoud
@foxdonut
Apr 19 2016 12:49
I agree, it makes the view easier to compose with functions.
devin ivy
@devinivy
Apr 19 2016 12:50
anyone worked with incremental-dom?
Fred Daoud
@foxdonut
Apr 19 2016 12:59
hadn't heard of it until now, looks interesting
dnson
@imnutz
Apr 19 2016 14:37
@foxdonut thanks. Yeah, i feel must easier to work with snabbdom, specially in event handling stuffs.

anyone worked with incremental-dom?

@devinivy does it work the same way as snabbdom?

I like SAM because I can start working on anything I want
without thinking of Redux/React or Angular + the ecosystem around these framworks
Jean-Jacques Dubray
@jdubray
Apr 19 2016 14:46
@imnutz looks like a great option to wire the components together especially when it comes to services, I'll add to the sample list. I am not 100% sure, but It seems to me that you could factor your code like SAFE such that the CSP code does not show up in the mode/state/actions.

I like SAM because I can start working on anything I want
without thinking of Redux/React or Angular + the ecosystem around these framworks

I like that quote...

dnson
@imnutz
Apr 19 2016 15:15
@jdubray thanks for your comments

but It seems to me that you could factor your code like SAFE such that the CSP code does not show up in the

i will check this.

dnson
@imnutz
Apr 19 2016 15:21
while working with CSP, i see that it can be fit well with SAM, because:
actions ---> put/propose data to model
model ---> put value to its channel, State will take this value and play with the View :smile:
i think this is aligned with the way SAM works.
actions (proposer) is active
model (acceptor) is passive
@jdubray is this correct?
unlike the stream option, where
actions is passive
model is active, because it needs to subscribe to stream to receive the proposed data.
Jean-Jacques Dubray
@jdubray
Apr 19 2016 15:25
it's definitely aligned, but SAM relies on a simple reactive loop, in other words, in a reactive loop a component never replies to the caller.
So any wiring approach that is based on a one-way message paradigm will work (observers, pub/sub, csp,...)
dnson
@imnutz
Apr 19 2016 15:28
uhm, i see
Jean-Jacques Dubray
@jdubray
Apr 19 2016 15:42
SAM is "step-based" in other words you must perform the loop (A->M->S) as a unit of work (a step) before you can process another action, any wiring that could help enforce that constraint is good, specially considering that when you call CRUD services you may be in a situation where an action tries to present data to the model, before the step completes, which would be bad.
@imnutz to answer specifically your question, on passive/active, this is not so important, IMHO. The only reason I don't like streams is that I cannot control easily whether an action is allowed to be triggered in the current state. Do you have a stream of actions (any action) that you can filter? do you have multiple streams for each type of action that you turn on/off. Streams seem to be overkill in most cases.
Jean-Jacques Dubray
@jdubray
Apr 19 2016 15:50

It looks to me that streams are part of the Cargo Cult of Reactive programming:

Pure functions without side effects
Immutable values, strict types
Functions operates on (immutable) streams of values
No mutable state (global or local)

No to mention that it's highly inefficient to keep all the stream values, and if you don't then what's the point? just wiring?
dnson
@imnutz
Apr 19 2016 15:59

SAM is "step-based" in other words you must perform the loop (A->M->S) as a unit of work (a step) before you can process another action

yup, i understand this.

i am no expert about stream things, so i cannot clarify your points about streams
but you're right, im using it for wiring only :smile:
Jean-Jacques Dubray
@jdubray
Apr 19 2016 16:02
for me, you have to always keep the programming model, the wiring and the architecture as decoupled as you can
framework s that too coupled/constrained should be avoided. it's like pouring concrete on your app, it may look sleak and smooth, but one or another you'll have to break it.
Fred Daoud
@foxdonut
Apr 19 2016 16:56
great discussion
@jdubray one thing I struggle with is the circular dependencies. Do you have thoughts about this?
  1. model needs state to call state.render
  2. state needs actions to call actions.x in nap()
  3. state needs views to call view.rep and view.display
  4. views need actions to call actions.x from UI event handler
  5. actions need model to call model.present
    So the circle of dependencies is model - state - views - actions - model
brusand
@brusand
Apr 19 2016 20:14
Fred, start with actions to initiate the model and back to actions for the next step. Othervise you right for the rest . :)
Jean-Jacques Dubray
@jdubray
Apr 19 2016 20:20
you can "assemble" the elements of the pattern. For instance, @imnutz has created the run function (main.js) to do just that. In SAFE that's the role of the init method. You could even wire simple data transformations to adapt the actions' outputs to the model inputs and state to model.
That being said the important decoupling that you do not have in React/Redux or MVx patterns is between the view and the model. The actions act as natural adapters between the view and the model and similarly, the State function will adapt the model to the view components' inputs. It truly allows the view components and the model to be reusable across applications (actions + state).
Jean-Jacques Dubray
@jdubray
Apr 19 2016 20:26
The way to decouple the view from the actions is to use "intents". You can can see an example here
In that case a view component (theme) uses a mapping between its callbacks and the application's actions. That way the theme components can be reused across any application.
brusand
@brusand
Apr 19 2016 20:50
JJ i ve just understand intents :) by reading the theme function ;-) thx for your great "pédagogie"
Fred Daoud
@foxdonut
Apr 19 2016 21:02

Perhaps the model could be decoupled, i.e. the model is independent and not tied to anything else (namely, not tied to state to call state.render directly). I think this is what @imnutz did in his example with the use of js-csp. @jdubray I think you approve of this, yes?

So any wiring approach that is based on a one-way message paradigm will work (observers, pub/sub, csp,...)

I like your use of intents as well as how you describe how the business model and the view model can be separate, and adapted by actions and the State function :thumbsup: