Hacker News new | comments | ask | show | jobs | submit login

As someone who has written several things with Flux and Flux-esque architecture, I see it as a step in the middle, rather than where things are ending. It's not a large step from Flux (Stores update themselves in response to actions) to Redux (Model the entire application as reducers on a sequence of Actions) to RxJS Observables.

What's shared in there is the idea that unidirectional data flow is a whole lot easier to reason about, model, and simulate than 2-way data flow. Everything else is semantics.




I really appreciate that Facebook resisted the urge to build the Ultimate Framework, with one thousand bells and whistles.

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.


> What's shared in there is the idea that unidirectional data flow is a whole lot easier to reason about

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.


I'm not saying easy to reason about in the sense of "easy to learn because it isn't a change from how we used to do things", but rather, in that it allows one to easily answer:

- What is the current state of things? - How did we arrive at the current state of things? - What should the UI look like given the current state of things?

It means that we can say: "Thing A happened, then Thing B happened, then Thing C happened". And then conceptualize "what should things look like after that chain of events". I've found this to make errors a whole lot easier about, because I don't need to piece together the state when an error happens -- just fire an action that says "An Error happened", then the stores figure out how to act accordingly. It's just another action.


couldn't agree more. React makes unidirectional data flow mainstream first time in the history. it's the important bit.


HTML forms? Win32? Curses/INT9?

Unidirectional data flow has been mainstream at least as often as nests of observers and component state. Probably moreso, if you count the 20 years of computing where the only thing you could do was batch processing.

What React does do is bring unidirectional data flow into the modern SPA web era. That's an accomplishment now, but it's important to put it in its proper place in history. Most of the history of programming had unidirectional data flow, it has its share of flaws as interfaces get more complex and interactive, and it's likely that at some point in the future people will move back towards multidirectional data flow.


I should've pointed the context: GUI.

Win32 is not unidirectional data flow. there is the API SetWindowLong to modify/update a component anywhere you like. It's used so widely everyone must've done it.


React has enough APIs to do ugly hacks too. That doesn't mean you should use them.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: