These are chat archives for jdubray/sam

13th
Feb 2016
Michael Solovyov
@msolovyov
Feb 13 2016 00:36
While I like the concept of SAM, I don't see many designers really embracing writing their html in js functions. It's awkward and still relies on their ability to read/understand the code to make sure it's fitting in the right areas.
Jean-Jacques Dubray
@jdubray
Feb 13 2016 01:10
Fair point, I'd like to see how we can rebalance the workflow between the designer(s), front-end and back-end devs. With Framework like React and Angular, the center of gravity of all decisions is at the Front-End ("can't implement your design, sorry" or "don't care what you think that API should be or whatever you want me to reuse, here is the one I want"
I felt that giving them back some control would be enough to convince them to write these functions.
Jean-Jacques Dubray
@jdubray
Feb 13 2016 06:23

I am cross-posting some of the discussion I had in the ngrx/core room
@jdubray
When you compare Redux with SAM, the arguments boils down that in Redux, when you write this kind of code:

case INCREMENT:
            return state + 1;

the reducer is coupling the action itself: counter += 1 which adds one to a given value
and state.counter = counter which assigns a value to the counter property.
All I am suggesting with SAM is to take the action logic outside the reducer, the reducer keeping its core role to mutate state. The same "reducer" logic could work just as well with different actions (incrementByN).

I am not quite sure anyone would see this kind of factoring in the context of mutating state as a bad idea