These are chat archives for jdubray/sam

31st
Jan 2017
Slađan Ristić
@sladiri
Jan 31 2017 00:28

I created a simple exercise for me to test the action hang-back and cancellation:

I ended up with putting the logic just in state-function and actions, looks simpler than the one below:
https://github.com/sladiri/sam-simpler/blob/feature/actionID_in_actions_and_stateFn/src/main.js

An alternative looks a lot more complex, where the model checks too, but it does not seem worth it:
https://github.com/sladiri/sam-simpler/blob/feature/actionID_in_model/src/main.js

Jean-Jacques Dubray
@jdubray
Jan 31 2017 14:19
@foxdonut thank you, I'll try to write a reply.
@sladiri apologies, I am busy at the moment, I'll try to take a look later today
Edward Mulraney
@edmulraney
Jan 31 2017 15:49
what's the risk of performing actions for transient state outside of the SAM loop?
say for example i have a type-ahead/auto-complete component. im not interested in keeping the results, i just want the list of results to show up
Jean-Jacques Dubray
@jdubray
Jan 31 2017 16:19
@edmulraney Nothing, the present reference is not hardwired to an action, so you could present new properties to the State function. As long as you understand the implications on the application state (here none), then it's ok. Of course the state function would not receive the model, so you need to account for that.
Edward Mulraney
@edmulraney
Jan 31 2017 16:19
yeah the state function not receiving the values is acceptable due to the fact its transient non-transformed data
Jean-Jacques Dubray
@jdubray
Jan 31 2017 16:20
exactly, that's a big advantage of keeping the application state (model) seperate from the state representation.
and of course, keeping the state representation stateless
Edward Mulraney
@edmulraney
Jan 31 2017 16:20
are there any implications on the programming model?
risks
Jean-Jacques Dubray
@jdubray
Jan 31 2017 16:21
Not that I can think of, this is only an optimization of the pattern, not breaking the pattern. You simply stating that the result set is neutral vis a vis the application state, I can flow it through the model or not, other parts of the model don't need to know anything about it.

The alternative would simply have been:

// action
      actions.model.present({resultSet})

// model
     if (data.resultSet) {
         model.resultSet = data.resultSet ;
    } 

   model.state.render(this)

// state

      stateRepresentation = state.view.theme.results(model.resultSet)

You are just skipping a step that has no incidence on the application state.

Edward Mulraney
@edmulraney
Jan 31 2017 16:27
appreciate your reasoning
it felt wrong to bypass it, but seems okay
Jean-Jacques Dubray
@jdubray
Jan 31 2017 16:28
as long as accepting the resultSet doesn't depend on any other parts of the model and vice versa, then it's logically equivalent.
What would be wrong is start pulling other parts of the model in the action to decide whether you "accept" the resultSet or not before you compute the state representation.
Jean-Jacques Dubray
@jdubray
Jan 31 2017 16:38
In essence that was the event/event handler model we have been using prior to React (credits to the React team). An action happens, some bits of application state need to change and you make all the decisions in one place, as long as the scope of the changes to the application state remains limited that is manageable, when the UX becomes more complicated with lots of events firing (including server side events) with broad reach over the DOM, then that model is no longer applicable.
Jean-Jacques Dubray
@jdubray
Jan 31 2017 16:44
That's why I insist (perhaps too heavily) on vetting and agreeing on a programming model, then you can make decisions as to when you can use an approximation/optimization with full knowledge of the benefits and when these approximations are no longer applicable. IMHO, Redux 101 is making the approximation that it's ok to commingle the (SAM) action and model, just to turn around and have to bring Thunks and Sagas as soon as they have to deal with an asyn action.
They are also making the approximation that the State representation IS-THE model, just to turn around and use selectors.
I don't like the notion of expanding a programming model like that, I prefer have the full programming model and then identify optimizations, why they are optimization and when I should not use them. Your code is a lot more maintainable when you use a stable programming model. In your case if I ever wanted to flow the ResultSet via the Model, it would be a very simple change, with no conceptual overhead
Jean-Jacques Dubray
@jdubray
Jan 31 2017 17:14
Talking about spaghetti code:
https://www.youtube.com/watch?v=InOWBvseRYU
This.JavaScript 01/28 - Vue, React, Angular, RxJS, Polymer & Ember
Jean-Jacques Dubray
@jdubray
Jan 31 2017 17:59
Fascinating to hear Dan's talking about what Fiber is trying to fix...
Slađan Ristić
@sladiri
Jan 31 2017 19:07
It is an interesting time :)
Jean-Jacques Dubray
@jdubray
Jan 31 2017 19:30
Yes! That panel explains well I like Angular2 and have no problem using it or recommending it, and why I'd never tough React.
Jean-Jacques Dubray
@jdubray
Jan 31 2017 20:04
From Ember, data layer is still a big pain point: "data synchronization with server is underdiscussed, communicating with the server, off-line data synching" really?
Fred Daoud
@foxdonut
Jan 31 2017 21:15
@jdubray now that Mithril 1.0 has been released it's definitely consideration-worthy IMO.
It's easy to use JSX if you prefer closer-to-HTML syntax so don't get caught up in the m() syntax if it's not your preference.
Slađan Ristić
@sladiri
Jan 31 2017 23:50
I tried animation by state: http://codepen.io/anon/pen/VPQQBP
I also included it in my excercise: https://github.com/sladiri/sam-simpler/blob/master/src/main.js
:)