Either I'll be unnecessary stubborn and miss this awesome new tech or I'll shovel my opinion aside and do try working with this approach.... or at least until someone else introduces new framework that comes with code separation.
It's not the end of the world.
After learning react something conked in my brain. As I rehashed the arguments against logic in views, I realized that they recapitulated FP's arguments against uncontrolled mutable state, just without the nuance. Nothing wrong with purely functional logic/computation itself. And that delineation feels a lot less arbitrary than "logic in views is bad".
To be clear, I'm not arguing you should implement domain logic in your views. That's a dumb strawman.
But the religious fervor that people have against logic in views is absurd. Reexamine why you think logic in views is bad, and I think you'll find the arguments are actually against 1. poor factoring resulting in ridiculously complex views (and hiding logic is a halfass, crappy way to control complexity) or 2. mutable state.
When you think of it this way, it makes sense. From a designer perspective it doesn't, and you have to adapt designs into a view, just the same, you usually do anyway.
Events happen to be triggered by the view and they affect global state which is then reflected in the view.
This is the separation of concerns you want. Components don't need to know about events beyond triggering the ones they need. Components only worry about rendering state.
You should also check out Mithril: https://www.npmjs.com/package/mithril
The approach that raynos/mercury takes where state is fully decoupled from layout/rendering is the way to go. In mercury, all the render functions are composed together to make one large pure function. You give it the current state and it deterministically will always render the same layout. So much better than the react approach. Furthermore, the complete decoupling from the rendering functions and the reliance on using bijective lenses with shallow copying means you get time travel debugging for free (i.e. undo redo is available right out of the box)
I just want to emphasize again that Flux is entirely possible without singletons, and works just as well on the server if you create new instances for every request. Flummox does it, Fluxible does it (at least for stores). It's just a shame Facebook pushed singletons and then everyone followed their lead.
I also think flux's real-world implementation came from the necessity to build React components within pre-built apps, where they simply didn't have the ability to pass down props because they had to create complete separate components.
Not everyone is ready to go into FP-land right now.
React lets you take these decisions yourself.
Whether local state is practical for your team or not.
You must be living in a very different world than mine if you think that compared to its rivals (Angular, Ember, etc), React is somehow “encouraging” local state. Sure you could go more functional than that, but take a look at the mainstream frameworks and you'll see it's such a long way to go, that had React not allowed local state, it would not have gotten adoption at all.
All I'm saying is that when people praise React I wish they were really praising what you call "declarative component model".
React is receiving 100% of the attention in this space when imo it should be receiving about 75%.
I long for time when these concepts are boring enough no one thinks of React anymore. Sadly we're not there yet.
Its true innovation is its declarative component model.
You are missing the point of React.
https://medium.com/@dan_abramov/youre-missing-the-point-of-r...
FRP is based around the idea of declarative components, but a lot of developers have an aversion to it because of the academic aura around it.
React's innovation is using virtual DOM to make declarative components usable without delving into FRP.
Not just that. I may be stupid but personally I find it mentally simpler to `setState` than to `flatMapLatest`. To each their own I suppose.
>React's innovation is using virtual DOM to make declarative components usable without delving into FRP.
Precisely.
>The "declarative component model" is not an innovation, it's an obvious approach [..] can achieve the same [..] by [..] obviously doesn't perform and has some edge cases where it breaks things (textboxes, for example), but the idea is the same
React is not an academic paper, it's a tool. It doesn't need to have new ideas, it needs to execute on them in a practical way. Which it does.
Separating `props` and `state`, component boundaries, lack of two-way binding and predictable top-down data flow make it easy to reason about where any data comes from, and how UI will change over time.
Read this:
http://jlongster.com/Removing-User-Interface-Complexity,-or-...
So we agree, you're just separating the concept from the implementation and I'm talking about them as one.
In React, components are not just functions that return their own virtual DOM. AFAIK for many vdom-based libraries this statement wouldn't be true.
React components may have local state (as much as some people hate it, some find it useful), they have a lifecycle, can react to receiving new props with side effects, can implement diff bail-out hook. And you can nest such components declaratively.
And declarative nesting is a feature of all of the frameworks I've come across, I'm not sure why you think that's unique to React. The advantage feature I would credit React for is the size of its community and influential advocates like you.
Declarative nesting of lifecycle-ful and stateful components without going full FRP.
I'm actually excited to learn about other frameworks that do this! Which do you have in mind?
If you are interested in academics, I published such a system at ECOOP in 2006:
http://research.microsoft.com/pubs/179366/mcdirmid06superglu...
It really has nothing to do with React's approach, at all.
[1]: https://github.com/muut/riotjs/blob/master/lib/view.js#L75
This is in contrast to a model where you mutate an existing UI model each time something interesting happens.
React is closer to an immediate-mode UI model: you write programs that compute exactly what the UI should look like on each frame, rather than mutating a scene graph each time something interesting happens (as occurs in retained-mode UI models). Substitute DOM for scene graph, and the distinction might hold.
But I'm not sure.
But yes, exactly. React is similar to an immediate mode graphics API. Except that also has weird connotations, because people think of things like canvas that are very low-level: all you get are lines, arcs, and fills. React's primitives are at the same level of abstraction as the DOM, you just work with them in immediate mode, not retained mode.
In contrast, a UI model like WPF uses (declarative) data binding to achieve something similar, but without as much flexibility and with more verbosity.
I'm working on a system that allows for state retention in an immediate mode model, though wrapping WPF rather than HTML:
http://research.microsoft.com/en-us/people/smcdirm/managedti...
I know Andy (former UIKit team) was quoted in the intro thread but I'll do it again:
>I say with confidence as a former UIKit author: React's model for the UI layer is vastly better than UIKit's. React Native is a huge deal.
https://twitter.com/andy_matuschak/status/560511204867575808
If you're averse to React because of JSX, “mixing templates and views” and similar superficial “best practices”, you're missing out. Engineers embracing React are not dumb. You should consider a possibility that they think it's good for a reason, and that reason is something you should learn about instead of armchair-rejecting it.
Try tuning out your inner rule-of-thumb linter for a weekend and really give it a try.