Components are not (just) rendered based on their internal state. In fact most components have no internal state. They are mostly rendered based on properties that are passed in right before calling render.

Also stores don't update the views. Stores emit change events and can be queried for a single large plain javascript object. The top level view listens to the change, gets the plain object, and cascades it down the view hierarchy as properties.

Views are also written as if everything is rendered at once. I don't see this in the article. Views don't care if there is optimization behind the scenes. There is no concept of sending repaint messages to particular widgets, or invalidating rectangular portions of the screen.

This article describes flux and partially describes react. Then it describes WndProc old-school windows GUI programming. Then it follows with:

This is exactly what Flux does. You can see this design very clearly in the official Flux repository’s example app.

Instead of explicitly stating piece by piece which parts of each are analogous to each other, the onus is on us the readers to "see this very clearly". I see some of it, but definitely not all of it. Is GWLP_USERDATA for passing in internal state? Are wParam and lParam for passing in data along with an action? Then what corresponds with the properties that are queried from the store?... a return value from an action handler invoked inside of the switch statement within WndProc?

There is one paragraph towards the end making explicit comparisons. Message types are enums in both, and both stores and WndProcs have switch statements on the message type. And in both, components don't modify the internal state while rendering. These are the only explicit comparisons.