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
@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
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
@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.
yeah the state function not receiving the values is acceptable due to the fact its transient non-transformed data
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
are there any implications on the programming model?
risks
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.
appreciate your reasoning
it felt wrong to bypass it, but seems okay
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.
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.
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
Talking about spaghetti code:
https://www.youtube.com/watch?v=InOWBvseRYU
https://www.youtube.com/watch?v=InOWBvseRYU
This.JavaScript 01/28 - Vue, React, Angular, RxJS, Polymer & Ember
Fascinating to hear Dan's talking about what Fiber is trying to fix...
It is an interesting time :)
Yes! That panel explains well I like Angular2 and have no problem using it or recommending it, and why I'd never tough React.
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?
@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.
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
:)
I also included it in my excercise: https://github.com/sladiri/sam-simpler/blob/master/src/main.js
:)