I'm not sure that I agree with the article... the view logic DSL that is JSX isn't bad at all, it couples your render structure with your components. Beyond this, you can have simpler dumb, static-rendering components with react.
What really strikes the chord with me is the Redux pattern for control flow... your state is driven by action creators and dispatchers. With a single state tree, broken up as appropriate, it works very well, even for moderately complex applications.
As far as react's size, I've got a stand alone control (may as well be an application) with a payload (min + gz) of 16.2kb [1] for a date picker control. It's using preact, preact-compat, redux and a few other pieces. So it can be lighter still, still using JSX.
Another lesson learned is to structure by feature, not file type... by coupling your render layer with your components, as opposed to separate templates, you don't have a complicated DSL to learn the behaviors of, but a simple prop="string" vs prop={JsLogic()} ... same for inline js {{js}} vs whatever weird dsl is used for iteration, conditions, etc... in React and its' ilk, it's all JS. Even JSX is a DSL that translates directly to JS.
I don't know enough about Catberry to comment, but having worked in web applications for two decades with I lose count of how many rendering systems, frameworks, toolkits, and techniques over the years... React (or preact) and Redux is the first time I've experienced a set of tools that feels like the "right way" to do it... now, Webpoack, Babel, and the configuration mess is a different story, but once that's setup, it's pretty smooth sailing.
[1] http://tracker1.github.io/md-datepicker/ (note demo isn't gzipped payload)
Better demonstration than most on this topic... It's important to understand how to compose higher level components from lower-level ones.. in the case of the simple redirect component wrappers, they could very well be static functions with the dispatch action inside the render function...
// require-auth.js
export default (redirectTo, component) => (props, context) => {
const {user} = context.store.getState();
if (user) return component;
setTimeout(() => context.store.dispatch(push(redirectTo)), 0);
return null;
}
Having a defered dispatch method would make it a bit easier, in any case, it can be simpler still...
Just the same, very nice article.
It's almost funny, but I've been heading in this direction for a few years, and it works out a lot better.. having related things together, instead of isolation by type just makes it easier to come (back) into a project you may not intimately remember, or otherwise be familiar with.
I can improve on angular performance with one line too!
npm install webpack babel babel-preset-react babel-preset-es2015 babel-preset-stage-2 react redux react-redux redux-thunks
;-)
I'm mostly kidding, but honestly, after working daily on ng1/ng2 and having used redux + react on a few side projects now, I feel so much stronger about react+redux than ng* ... I'm biased as all hell, but my bias is backed by much less complexity in the codebase for an application.
Jumpin in late, but having the "recent" article pages have a rel="nofollow" until they've seen 3 upvotes may be worth it too, real spam will likely be reported before sufficient upvotes... maybe requiring a certain karma from posts before being able to upvote articles? Just a few thoughts on this one.
I mostly prefer to do more front end work, but like to control the back end as well. I don't like to be pigeon-holed... People assume that because you're good on the front end that you aren't a good/great developer, or that you're weak on the back end, or even more core understanding.
That kind of mindset always irked me to no end.
I find that the lines may get muddled... Something that should reset if the page is reloaded should not go through redux/flux. This includes modals for a calendar control, search boxes, like in tfa, etc.
However, there are interactions, and states that should be part of the application state. A better example, even though it is per-control, would be form/control validation state... was a control focused, if so, then it should show a validated state, otherwise, it shouldn't until a submit is attempted.
There are other controls that may very well go either way. It really depends on your need. I can see the desire to separate the control state from application state, but really, it should be a matter of the guiding parent's feature that controls this... the containing feature's form/screen should have its' own data state, and that state should guid the lookup through a determined service. Then you can still have structured components, but then separate the logic not to a generic control provider, but the parent becoming responsible.
Interesting take... I spent a good deal of time integrating the redux library into an angular2 application, and it was "interesting" doing so, to say the least. Although I don't like this pattern quite as much, it is a much better fit with Angular2.
I have to admit, I'm really biased in favor of React + Redux, but seeing Angular 2 in this article makes it feel much more tolerable. There are quite a few bits of ng2 that I disagree with, and I just don't care for the template engine. The syntax is leaps and bounds better than ng1, that said, I still prefer React+Redux ... going a step farther, I'm playing with preact+redux currently, and getting a working starter app in under 20K payload (min+gzip) is pretty sweet, compared to over 10x that for ng2.
DMCA takedown in 5... 4... 3...
I jest, but I've seen several Spotify API apps like this get shut down on bogus DMCA claims over the source code... hopefully I can clone this at home while it's still up.
I'm not sure that I agree with the article... the view logic DSL that is JSX isn't bad at all, it couples your render structure with your components. Beyond this, you can have simpler dumb, static-rendering components with react. What really strikes the chord with me is the Redux pattern for control flow... your state is driven by action creators and dispatchers. With a single state tree, broken up as appropriate, it works very well, even for moderately complex applications. As far as react's size, I've got a stand alone control (may as well be an application) with a payload (min + gz) of 16.2kb [1] for a date picker control. It's using preact, preact-compat, redux and a few other pieces. So it can be lighter still, still using JSX. Another lesson learned is to structure by feature, not file type... by coupling your render layer with your components, as opposed to separate templates, you don't have a complicated DSL to learn the behaviors of, but a simple prop="string" vs prop={JsLogic()} ... same for inline js {{js}} vs whatever weird dsl is used for iteration, conditions, etc... in React and its' ilk, it's all JS. Even JSX is a DSL that translates directly to JS. I don't know enough about Catberry to comment, but having worked in web applications for two decades with I lose count of how many rendering systems, frameworks, toolkits, and techniques over the years... React (or preact) and Redux is the first time I've experienced a set of tools that feels like the "right way" to do it... now, Webpoack, Babel, and the configuration mess is a different story, but once that's setup, it's pretty smooth sailing. [1] http://tracker1.github.io/md-datepicker/ (note demo isn't gzipped payload)Better demonstration than most on this topic... It's important to understand how to compose higher level components from lower-level ones.. in the case of the simple redirect component wrappers, they could very well be static functions with the dispatch action inside the render function... // require-auth.js export default (redirectTo, component) => (props, context) => { const {user} = context.store.getState(); if (user) return component; setTimeout(() => context.store.dispatch(push(redirectTo)), 0); return null; } Having a defered dispatch method would make it a bit easier, in any case, it can be simpler still... Just the same, very nice article.I can improve on angular performance with one line too! npm install webpack babel babel-preset-react babel-preset-es2015 babel-preset-stage-2 react redux react-redux redux-thunks ;-) I'm mostly kidding, but honestly, after working daily on ng1/ng2 and having used redux + react on a few side projects now, I feel so much stronger about react+redux than ng* ... I'm biased as all hell, but my bias is backed by much less complexity in the codebase for an application.