@jdubray : the
Counter can be even easier:var Counter = function(props) {
return (
<button onClick={actions.click}>
Click me! Number of clicks: {props.count}
</button>
);
};
Interesting, I tried to pass the action as well:
theme.display = (m) => ReactDOM.render(
theme.counter(m.count, actions.click),
document.getElementById('container')
)
var Counter = function(props, action) {
return (
<button onClick={action}>
Click me! Number of clicks: {props.count}
</button>
);
};
but it didn't work
SAM aside, would you consider it a better way to keep the app logic outside the component?
yes, this is akin to redux-react's connector http://redux.js.org/docs/basics/UsageWithReact.html . you should be able to pass the action just fine.
it's not a bad read, but if you want to see it used search the page for
{ connect }
Ah, I get the component to display but the actions is not triggered. Not sure why:
theme.display = (m) => ReactDOM.render(
theme.counter(m.count, actions.click),
document.getElementById('container')
)
var Counter = ({count, action}) => (
<button onClick={action}>
Click me! Number of clicks: {count}
</button>
)
@jdubray Here you have a working copy http://jsbin.com/kavalomate/1/edit
Yes, sorry, I got it to work the same way, I had forgotten to update the theme's function:
theme.counter = (c, a) => <Counter count={c} action={a} />;
cool :thumbsup:
JSX is so elegant!
Why is that :)
Not sure, just feels elegant compared to everything else I have seen
Not really correlating with the view given in http://www.infoq.com/articles/no-more-mvc-frameworks :)
ah ah...
But in general I agree that its a big improvement in general
What I always said was V = f(M) is a major contribution from React/JSX
True
I had done a lot of work with 0.13.x and in React 15 they made it even better
Indeed and following the last discussions its really heading that direction
I still think that the React ceremony (willMount, state,...) is a major drag to React's adoption
facebook/react#6170
redux are moving these days as well. reactjs/redux#1528 composing effects ect
I hear all the time the pain people have with React's programming model.
I would always have prefer something like elm or more pure but again, where the community is thats where the value is for me, to be productive.
but neither of them composes well.
Thats why they are looking for a new model to handle it
well, I believe that "purity" is the issue in both Redux and MVI based approaches like ELM/Cycle
All right. Might def be so
This is an unnecessary constraint
Well I think having control where side effects happen can be really powerful in terms of execution and error cases
In the end there are many better implementations of virtual dom, state handling than react and redux but it doesnt really matter as long as they dont provide the ecosystem value react brings from that point of view
not sure this is true
I come from haskell background so I'm def biased
The difficulty that React and Cycle have in weaving API calls in their programming model is not accidental
Yes, I understand the source is Haskell / Erik Meijer
Perhaps it is time to take a fresh look at the question. No offense to Erik's work, but this needs to be fixed
People cannot write apps if they cannot connect front-end to back-end
I have no problem updating my mind :) and always looking for stuff mapping to a better mental model
I agree with that
Again, I would suggest you look at TLA+
I've done it before
But can't remember all the details. TBH
I have provided an interpretation, happy to be challenged on that interpretation
But I believe the solution is there
TLA+ is so foundational that I am surprised when Reactive/Functional "enthusiasts" don't even want to look at it
Can you point me to a blog where you explain why you think this model solves the front-end to back-end interactions much better? I've read your blogs but can't really see I'm sold.
I discovered TLA+ in a Lamport interview many years ago. So again I'm not fresh on the topic. Will reread
Please do, it's all about understanding how state mutation occurs, the way he defines actions and the "prime" notation.
Not to mention the temporal logic piece
I don't have much more than the InfoQ article at this point and a lot of painful experiences with MVC/Templates and APIs
SAM (and React) isolate the view from the APIs, then the questions is where to they fit in the programming model?
Redux was cornered to break its "action" model and then break its 1st principle (single state tree) by using Sagas
All SAM is suggesting is:
- Action as functions (directly aligned with TLA+)
- Use the "Accept" phase of TLA+ to implement the APIs because you cannot deliver a coherent application state until you persisted what you needed to persist
Thanks, thats very explicit
The reason why SAM does not require Sagas is because of the nap() function which computes what is the next action
that way SAM is able to preserve the single state tree constraint which is essential IMHO
Need to continue to work :) Thanks for the discussion. Will read up on TLA+ again.
thanks for the code
You're welcome!
From the github/#1528 discussion:
I feel quite unhappy with Redux after my app became quite large, with many side effects and quite strong coupling between reducers, actions and appropriated react components (via connect(..)). Initially i've created separate actions, sagas, reducers, react component for each "feature" of the app, but it became too complex very quickly - anyway all these files 'import's each other a lot and cannot be splitted into different npm packages. So I'm still looking for less-coupling solution.
Not really surprised
Same here, easy to see how that could degenerate. the elm architecture suffers from the same problem IMHO.
IMHO, it's inherent to try to isolate the side effects. Even Erik Meijer explains that's not possible.