@jdubray ok, so if I try to rephrase what you said: the fact that with ngrx/store the only observable you can have is the current model (the store) instead of a derived state from the model makes using ngrx/store too much coupling for you? So the problem is not about observable but more about the fact there is only one observable exposing the model. Right?
(store exposes an observable, so I'm confused by the fact you oppose observable and ngrx's pub/sub in your discourse...)
(by the way, ngrx is now at https://github.com/ngrx/platform/, not ngrx/store, but it's the same API anyway)
is it considered reasonable to call model.present from within model.present? I am thinking of the case of serverside validation say on the password example where there is a business rule that you cannot use any of the your last 3 passwords when trying to change it. an actions proposes a change to the password... model.present must validate that password is no good... when ajax complete, I must re-inform model (model.present?) that the password is not acceptable.
calling model.present from model.present is kind of the same thing as doing multiple things in model.present once... so I would say yes, this makes sense, but maybe I wouldn't bother calling model.present, just doing whatever calling model.present would have done... no?
@victornoel well, IMHO, it's important to support (and use) the case where multiple component subscribe to the same changes. In a functional HTML case, that's easy to implement (orchestrated from the State function), but in a component based architecture we need the same capability, hence Pub/Sub. I also like the control of deciding when you publish the event. It's not a good idea to wire observables to some state being mutated.
@srconklin It's all about temporal logic, as long as you don't lose track of "steps" and you can reason easily about concurrency (if any) then you can do anything you like. For instance I call command APIs from the model because I make the assumption that commands are "blocking" from a UX perspective, so there is no need to throw an action and reenter the model. That approximation does not violate the temporal structure of my code.
Just like functional programming is about function composition, SAM (temporal programming) is about decomposing your application logic into Steps that form a behavior. I contend that a Step should be factored as Action->Model->State->nap.
@srconklin in your particular case, I would write a query/API that returns the response to the action that will present the result to the model (pass/fail). I don't think it's wise to move this kind of logic (especially for sensitive information) in the middletier, be it action or model.
Any query should be executed in actions, only commands should be executed in the model and that is an approximation.
@jdubray I'm sorry but I really feel like there is some kind of misalignement between the meaning you put behind terms and the meaning I put. What do you mean when you say "It's not a good idea to wire observables to some state being mutated."? Are you talking about "watching" the mutations of the model (stored in
Store in ngrx case) via an Observable? Or about mutating the state (via an OBservable?! that's where I'm lost)?
Or are you saying doing
store.select () is NOT subscribe in the sense of pub/sub?
the semantics should be:
- once the mutation phase is complete state representation is computed
- any number of component can be notified of the changes (deltas) in the state representation
I don't like the idea of wiring individual data elements between the view component and the state representation or the model.
I am a SOA guy, I like messages :-)
I understand what you say, but do we agree that "any number of component can be notified of the changes (deltas) in the state representation" is exactly what the observables on ngrx/store does?
(considering that the Store stores the state, not the model)
@jdubray per your comment
any number of component can be notified of the changes (deltas) in the state representation
Is that a NAP responsibility (i.e., to "notify" listeners of changes)?
Or is that better handled elsewhere by the state (i.e., the state that makes the representation and calls render())?
he is just talking about a mechanism to transmit the state info to the view, like render would update the view do if was a functional view, but here you are using a pub/sub subsystem because of the way angular works with templates for the view. It's not about SAM per-se, it's about how you implement the pattern with the help of pub/sub to transmit state to the view
If you observe the changes in state (wherever it's stored and in whatever way) I think there should not be a problem in terms of coupling. In a non reactive framework like angular you're coupling the view anyway with some event source, being it a message dispatcher or an observable state store.. what's important is not coupling with the model itself imho
@pfurini so for example if an abservable state store actually stores the state but not the model, that could be a good way to implement the SAM patter in angular?
(I realise writing this sentence that, duh, that's what an observable state store is for: storing the state, not the model)
What's important is that the view should observe (or listen to messages) that are relevant to its representation, nothing more
I understand what is important in SAM. My questions are about examples of how to do it in angular with ngrx/store as the pub/sub susbsystem
I mean, when multiple state functions compute their representation, they should post the outcome somewhere to be consumed by the view (or views) that knows how to render it. Producing a message payload tagged with a type, and publishing on a global queue, is a good way to have atomic and serialized changes consumed by interested recipients, with the least effort.. I think observables could do the same job, but maybe they'll be a little trickier to implement properly. I don't know of examples of such setup unfortunately
For serialized I mean they are ordered by nature, if the queue itself guarantees ordered dispatch
I think this could be very simple with ngrx/store, it works like redux. It would be good for SAM as long as we only use ngrx/store (or redux) for holding the state and have something else responsible of the model. The state would be for the whole application, but each view would selects just a subset of it as per typical usage of ngrx/store
You can even decide that some messages should replace older ones if not already consumed, OR you could want them dispatched anyway and in order.. observables do not have this capability
observable here is only to read the state, not to compute it
in ngrx/store you send event as you just said and they are consumed by functions that update the state (reducer in the redux parlance)
again, the important point being I would do the model stuffs somewhere else and would use the ngrx/store only for state
(and the actions too of course)
still sometimes I wonder what's the need for all those event subsystem when javascript has not concurrency by default, simple function call would have the same effect.. only advantage is that you can record history and replay it or have more adequate dev tools maybe too
I'm more a SOA guy like @jdubray, so I'm used to message oriented architectures, and way less to redux like stuff.. What I meant for an ordered sequence of messages to be consumed by a target view, is when you need to represent the sequence of events, and not only the final state representation. Take for example you want to show a countdown without losing intermediate numbers (it's a contrived example, just to explain my point)
I know that could be an event stream, if that's the correct name, but I never understood the complexity of redux style approach.. some things are easy to grasp, but I wonder if we really need all that stuff.. sometimes a simple message queue do the job and with less complexity
I agree :) personally I'm not from the frnted/js/redux world originally. If I wonder how to use SAM with a redux-like approach it is only for two reasons: angular views works better with an observable/reactive approach and a redux like susbystem can provide a basic implementation for emitting data in boservables that comes from a global state. After that, the fact that you have a complex infrastructure in front of that to update the state (not to get updates of it) is what I was complaining about.
Message queues are great, but in this context, I think they are lower level to what redux-like approaches achieve (which is not to say it's better to be higher level) and provide some adequate abstractions to deal with things related with "state to view"
Message queues are great, but in this context, I think they are lower level to what redux-like approaches achieve (which is not to say it's better to be higher level) and provide some adequate abstractions to deal with things related with "state to view"
(observable, event stream, are equivalent yes)
observables are at the same level than messag queue, but to me they answer a different need
I think the solution @jdubray arrived to in its article on sam+angular4 was actually maybe the best in terms of abstraction: a state manager that works with pub/sub, a model which is ad-hoc code, and the same for actions. I am just wondering if I could use something more mature for the state part
Maybe a specialized library that implement an event stream approach without too much fuss.. I'm sure there are many out there (I remember some articles I read some time ago)
I mean, redux is not the only answer, for sure
for sure there is yes :)
this whole discussion gave me clear ideas about how to tackle that. I have to start working with state in an angular applicatoin I'm working on at work, so I think I will try to make the model and the action clearly separated from any state needed to compute the views.
this whole discussion gave me clear ideas about how to tackle that. I have to start working with state in an angular applicatoin I'm working on at work, so I think I will try to make the model and the action clearly separated from any state needed to compute the views.
👍
Anyway I think a rxjs event stream could do the job.. do we need more?
well the ngrx store (and redux-like fwk) is a datastructure observable via an rxjs event stream (aka an Observable)
got to go, thx for the discussion, I understood things!
Oh well, as long as it plays nice with the KISS principle, let's try it 🤙
But every time I hear the word redux, I smell unneeded complexity.. maybe I'm too old ;)