Then I would like to tip you on the following blog regarding structure large applications. http://jaysoo.ca/2016/02/28/organizing-redux-application/
You may want to look at the TODO application
SAM is just a programming model, it is not prescriptive as to how you "wire" the elements of the pattern together (observables would work just fine). It is not prescriptive on the architecture of your app either. I believe it's one of the simplest way to write isomorphic JavaScript.
The SAFE library may be useful to you when you deploy some elements on the server.
Sure thing. Will take a look
Thanks
The things you want to watch for:
- make sure that your theme (the view components) is as decoupled as possible from the application. SAM should be able to achieve close 100% decoupling
- State needs to know about actions because of NAP()
- The State function and the View can be reasonably decoupled
- you have to decide how the present method routes the requests between the actions and the model. I prefer a DataSet type of interaction, but it's really up to you and there will be cases where you need to know which action/intent is presenting the data, it's not possible to achieve 100% decoupling
As we discussed SAM is less concerned about effects (and decoupling the logic from the effects). SAM factors the logic in three buckets: Propose/Accept/Learn, it is that decoupling of the different types of business logic that I believe leads to a better outcome. In particular, as I said the phase that is missing in other frameworks is the "accept" phase. In Redux for instance the store must accept everything the reducer proposes. There is no room (as I understand it) for the store to decide whether to accept / reject some values.
That is def true
Thats why I think the semantics of a event would be better in the context of Redux
Since its not possible to reject it, rather make a compensating action (but again this is only possible with sagas, you can't dispatch from a reducer)
yes, exactly my point
and Sagas have their own state tree
Indeed
I am not saying never use Sagas, but if you use them to tackle that problem, you are dead, your code will be awful.
Why do you think so? The sagas per se, or the combination of reducer to write to state tree and saga's outcome/conclusions?
It's a fundamental reason, I know a thing or two about stateful orchestration since I built some of the early integration brokers / business process engines in the late 90s. I also built the chorus.js project (stateful orchestration for node.js) and contributed to many related specifications (WS-TX, ebBP, WS-CDL).
State Machines have "no memory", once you are in a state you don't need to know how you got there. The problem with Sagas is that they have a "memory" you write your code as if nothing else is happening. As you mentioned they are good (and were designed) for compensating transactions, but they have to be written in an imperative style.
As soon as you are going to need to write this logic in sagas you are going to start coordinating across sagas, it will become ugly very quickly
That's why I think the right way to do it, is:
- do as much work as you can in the acceptor
- use nap() when true compensation is needed or trigger new units of work
The other aspects that Redux does not have is the notion of "step", which important in some scenarios when you need to do action cancellation for instance. This kind of logic is very hard to model in Redux/Sagas
All this is coming from TLA+ for free (it's not like I made it up)
I know it's cool to put on your resume that you know how to use generators, but it's better if you know when not to use them...
Hah. Do not care about my resume ;-) Rather trying to find pragmatic ways to use the technologies that are available and maximise the value i can get out of it.
I am with you
I do recognise some concern you highlight. That everything gets intertwined pretty fast with the structure of React applications these days
Yes, that's exactly my point
Now don't get me wrong, SAM is not magical but because it is closer to the semantics of "state machines" it has less of this "memory effect" where you write your code from the point of view where you know exactly the sequence of events
because what we know is precisely that the sequence of events cannot be predicted
there lies the value of SAM/TLA+
everything around scheduling is indeed unpredictable.
That's why you need to control with precision the boundary when you start mutating the application state
Have you tried out using SAM as a pattern at the server side as well? On other languages
Yes, this is actually where I started
I think that was the goal of having a single dispatcher in flux as well
To remove concurrency
It works very well
And then the enhances around a single state tree came because it made it more simple
Yes, SST is essential, cannot be compromised
Perfect. Will take a look at that bitbucket repo later today.
This is more "state machine" like because it is trying to solve the problem of complex API orchestrations.
I see. And that makes perfect sense. Since we're in that situation across the world now.
There are some examples using WebSocket and a Queues
More apps, more integrations, more complexity in terms of api's, multiple versions running ect
Is that using message passing then?
Since you broke the temporal coupling with a queue?
Well this is just wiring, you can still do request/response with a correlation id
Indeed.
The state machine makes sure you don't get out of sequence
I tend to be very specific in decoupling programming model, wiring and architecture
All too often in our industry we tend to force fit one into another
E.g. the wiring or the architecture drive the programming model
What are examples of other programming models besides SAM
I can't google a definition of programming model that seems to fit your discussion
programming model simply refers to the way you factor your code. The programming model is generally very opinionated and somewhat arbitrary. Sometimes the wiring or the architecture get in the way, for instance when MVC is wired over HTTP you lose an important aspect of the original programming model where the controller updates the view (it's true with SAM too of course).
As we have seen there are multiple ways to factor the same code (keeping architecture and wiring aside) and even though Redux and SAM are fairly similar at a high level, in the details very small opinions drive major factoring differences such Sagas.
Sagas were carelessly introduced in the Redux programming model, to fix some deficiencies and probably because it was a way to use generators.
so programming model is SAM, MVC, MVVM, etc?
design patterns
It's a bit more than design pattern. It's the underlying semantics you overlay over programming constructs from which your solution is built.
An algorithm does not have a programming model per se
sure and no one calls that a design pattern
JEE is a bit more than a design pattern
I agree that the boundary is fuzzy
what is jee
but it's a bit more opinionated than a design pattern
? JEE?
yes
Enterprise Java?
Or Spring
Spring is based on a pattern DI
Luckily I've never had to do any Java
You are so lucky
JEE is a programming model similar to SAM?
No, not at all
JEE is a bit more than a design pattern
What did you mean by that?
But it has opinionated semantics: session bean, entity bean, ...
I see
but isn't some of this wiring pretty opinionated semantics?
I think cycle.js is opinionated
As I mentioned, JEE comes with strong semantics in which you fit your code
I guess that's the difference for me between framework and library. JEE is a framework, Redux is a framework
Yes, that's the problem sometimes the wiring you choose drives some of the programming model, that's ok as long as you understand the implications
But often, like in the case of Cycle.js, people feel that the wiring IS_THE programming model
Pub/Sub is also a wiring that ends up to be pretty opinionated because you cannot overlay your code seeamlessly
I guess what I am trying to say is that everything we code amounts to executing actions reaching specific states. It does not mean that this has to be your programming model, that's not a good one, we all know that.
Wiring meaning the way events and/or messages flow through the system?
Yes
That being said, anything we overlay on top of these actions and states will have a huge impact on the clarity, stability and maintability of the code.
That's why Spring won over JEE for instance
And what do you characterize as being part of the architecture?
Client/server over HTTP?
That's where the elements of your programming model runs (how many tiers,...)
HTTP is wiring
I could use Websockets too
WIth SAM you have a choice as to where all the element are executed, in separate processes, not just client/server.
You look at Isomorphic React (at least that's how it looked last fall, I don't know if React 15 changed anything) and you know you don't want write React Isomorphic code.
Right, right, so what's an example of architecture then
AWS Lambda
Serverless !
You'd have to start making decisions about session management for instance.
That is an architecture concern, not a pattern or programming model concern
So architecture is heroku vs google app engine vs aws lambda vs colocation vs etc
I guess a pattern can have several programming models, which can be implemented with different wiring technologies over several architectures
It's also deliberately deciding where you run actions, models, states and views
ah
When things are truly isomorphic, then you realize that architecture becomes a choice
not a constraint
Spring too was fairly isomorphic when compared to JEE
I've enjoyed some of the links you've surfaced
happy to hear
I liked the one on vanilla js modules
presentation
state management is really hard
I like to get news on it :)
No question about it...