Flux is the new WndProc

With one-way workflows combined with immutable state, and idempotent components, it's much easier to log/replay/test any given scenario.

It makes some things a whole lot "easier to reason about" (so sick of that phrase), but other things not so "easy to reason about", like, for instance, error handling. Getting my head wrapped around the fact that asynchronous errors had to live in their own stores and be handled in the same way as all other data passed to the view was certainly not "easy" to reason about and still doesn't sit right with me to this day. You make concessions with every pattern and there is no silver bullet.

Instead they kept things simple and low level, to the point that writing vanilla React and Flux is kind of verbose. However, I much prefer this approach to some of the other frameworks that try to do everything for me, but which mostly just end up confusing me with too many abstractions.

Flux/React are actually quite simple and I can put the core architecture together in under 50 loc of Elm.

React is also pretty simple when compared to libraries like Angular.

I'd also note that we know that this style of design scales amazingly well. You can build and maintain applications as complex as Word, Myst, Netscape, and so on indefinitely. So we definitely know that this design has some historical precedent of working really well, and we're probably not way off track.

That in turn means I think we can answer the "what learning can we apply" by looking at what worked well historically.

For example, one of the things you have to do is to hide the low-level event loop. That's what frameworks like OWL and MFC did very early on, and I think what frameworks like Reflux are trying to do now. You even have some of that in the form of observers and so on in Flux itself. But I think that getting those types of things standardized, and a bit higher-level, will help a lot. I suspect, although I don't know, that ES5 was a bit of a blocker on getting that in Flux earlier, and suspect that Babel's pervasiveness will let that situation start changing, but that's entirely a guess.

We also know that, for the overwhelming majority of apps that are actually written, having a GUI designer building on the underlying framework (e.g. Interface Builder, VisualAge's form designer, etc.) can both decrease development time and reduce bugs, and we know that such tools work best with certain patterns in how callbacks work in the underlying framework. Specifically, you want one-to-many observers, strongly typed events that can be exposed and described via reflection, etc. So I'd hope that implementing that kind of thing in Flux can be done in a forward-looking way from the beginning, rather than getting bolted on later. More generically, designing the framework with an eye towards making it tooling-friendly is probably a really good way to future-proof things from the beginning.

I guess we'll see as we move forward. Each situation is a little different, so while there are parallels, it's hardly a slam-dunk that things will go exactly the same. But I do think that keeping an eye towards tooling is a really logical way to look forward and learn from the past.

I certainly think that we're going to see more migrations to RxJS (or Bacon or other relatives) from Flux (or in addition to Flux).

Personally, I've been preferring Cycle (http://cycle.js.org), which is directly RxJS-based, over React and Flux, but there are an increasing number of options and maybe no "perfect" answers just yet.

I am using React/Flux (Redux) as well. I generally love it and find it easy to write dynamic UIs and without making very many mistakes. Each React and Flux component is small, focused, testable, and easy to reason about.

The only gripes I have are the small amounts of boilerplate I end up with. Redux cuts this down a lot over a homebrewed Flux implementation I wrote. Also, testing complex trees of components can be a bit of a drag.

Original comment:

The weakness of typing in the switch blocks. I'll alter that sentence a bit; it's a leftover from an earlier version of that article where I was going to focus very narrowly on how uMsg/wParam/lParam, like the way actions are usually done in Flux apps, are decoupled to the point where it's very easy to make typing errors. Then I described why I thought they were similar to begin with, and then axed most of the original post when the entire thing switched to showing how Flux is an old pattern we've done before. I'll see if I can tweak that sentence in a way that keeps the flow going.

Angular is Adobe Flex Builder reborn. In fact it's created by the same guy

My guess: Borland Delphi.

https://news.ycombinator.com/item?id=10380508

Err, that's not entirely true for MVVM apps, where views are just declarative markup that are rendered (retained mode) based on logical state provided by data bindings. It's been like that ever since XAML was introduced in 2006.

One nitpick I have though is the giant switch statement they mention. I typically put all this into an object so you don't need to traverse through some huge switch. Not sure why everyone just doesn't do something like -

  AppDispatcher.register(function(action) {  
    actionMapper[action.actionType](action);  
  }

> React by itself doesn’t actually solve how to propagate changes

In my experience, it really doesn't solve the problem all that well for a sufficiently complex app. I'm willing to give the author the benefit of the doubt on that point.

That's not all that different from what DispatchMessage does in the Win32 API.

Anyway, I think that what FRP, React, and Win32 all have in common is a reliance on explicit local state. Components are not supposed to maintain references to other components and send them messages directly; instead, components are supposed to pass messages back to the top-level event loop of the component hierarchy, which then dispatches them to the appropriate subcomponent, which is supposed to take the appropriate action based only on information in the message and its own local state.

This is in contrast with later OOP frameworks like Swing, MFC, NextStep/Cocoa, or the DOM, where it's common to hold a direct reference to another component and then update it via observer. These hold implicit global mutable state; the state of distant components in the tree may be silently updated in response to an event firing in some other component.

The trade-off here is whether you want spaghetti code or ravioli code. Functional frameworks (FRP, React, Win32) tend to locate logic for the details of what should change outside of the components themselves, which focus only on how it should change. That keeps component logic simple and prevents unexpected side-effects, but means that the code for the controller itself can become ginormous. OOP frameworks tend to move logic for what should change into observers, which then reach across the component tree and update a number of different components directly. You break up the logic into a number of bite-sized pieces, but there's no way to see or predict what the effect on the system of a whole of an event will be.

Interestingly, Polymer/webcomponents goes back to OOP-style ravioli code. I suspect that like the rest of the computing world, we'll see a see-saw effect on a roughly 4-5 year cycle, so maybe around 2018 observers and mutable state will become popular again.

The author understands React quite well, it's this comment that, while also understanding React, misses the author's point by insisting on the superficial differences.

>It does actually - you update the state, then React propogates the changes for you through it's props mechanism.

That it achieves something (change propagation) it doesn't mean it's the solution to that thing. There's a reason the author used the wording "doesn't solve" (instead of "doesn't handle", "doesn't allow" etc). Flux (and it's variations) is what really solves propagation in React without it becoming a tangled mess.

>Flux is not message passing

Nobody said it is.

>React components do not redraw themselves

They do, that's the whole point. React components manage, compose and return their DOM representation structure which is the HTML analogous to "drawing". return(<b>{msg}</b>) IS drawing.

The fact that they don't have low level rendering code embedded in them is just an implementation detail (because of course the DOM already exists).

>React provides the view as a function of state. Windows is nothing like that.

Only the author doesn't mention Windows, the abstract OS, he mentions a specific implementation of its UI engine that clearly provides the view as a function of state.

Similar miscomprehensions of the article drive the other objections.

I think this is where people run into problems with React and it is what gets them running for something like Flux early on (I agree that it is not necessary in many cases).

If instead of putting the state for a node in the same node that renders it, you put it in the parent node, suddenly things get a whole lot simpler. To look at it the other way around, a node keeps the state of its children and passes that state as props to the children. That way the children are all idempotent with respect to rendering.

So what do you do when the child wants to update the state? The parent passes a callback to the child and the child calls that callback. This updates the state in the parent and passes new props to the child.

The effect of this is separation of rendering logic from update logic. Every React component knows how to render itself from props. It knows how to request an update to itself with callbacks that are passed as props, but it doesn't know how to update itself. The parent holds the state of the children, but doesn't know how to render them. It simply passes that state to the children. The parent knows how to update the state of the children.

You may recognize this pattern. The parent is the controller for the child. The state that the parent holds is the model for the child. The parent node together with its children form an MVC structure. Of course each child can be a parent too, which leads to a hierarchical MVC structure.

With this, you will usually not need Flux. Of course, one could imagine that passing callbacks is tedious. We could create a special object that handles all the "actions" that the child might make. Then we could simply pass that object in the props. Sometimes, the state that you want to update is several layers up and you end up passing this object down the tree just so that the very bottom node can call "actions" on it. So, instead, we could make this a singleton object and call it a "dispatcher".

Also, you sometimes have situations where, for convenience sake, you might want to store the state in several places in the tree. Let's say every terminal node needs a certain piece of state, so you end up having to put it in the top node in the tree. Then when it changes, you end up rendering the whole tree. So instead, you can create an object (let's call it a "store") that holds the state. Individual nodes observe the "store" and when it changes, they pass the relevant values as props to their children (never updating their own state or rendering it directly!!!). We can even make this "store" get updated by pushes form outside events.

And there you have Flux. Useful in certain circumstances, but I would suggest that if you are finding that you absolutely need it, it's because you are trying to render local state, which you should not do.

With respect to the original article, this is what Windows got wrong (with everyone else, of course). The code that renders the state, holds that state, which makes you reach for WndProc().

Beyond that, though, they have way more in common than they do different. I'm not sure it makes sense to talk of one of them as a better model than the other, versus maybe a better implementation of the same workflow.

I think the word he's looking for is "pure".

EDIT: I was wrong - apparently "idempotent" can also describe a consistent relationship between the input and some state. In that sense, it's actually a very good description of how the input to a React view affects the DOM.