Personally, I kept the concept of unidirectional flow of data, but instead use a Web Worker as storage of state, which emits immutable props to render.

Components can post messages to the worker to request an action on the state that will most likely change its data, but they can't edit the data directly, and props are only emitted if there is really a change in data.

Inside the worker, state is stored as immutable data, and action handlers are only allowed to make one non-async change (because the return value is the modified state). If it needs to do multiple things (e.g. download then process the result), it must schedule another action when it's ready to do the sync operation. This splits into granular easy-to-test operations on the state.

That way, it limits React (or Preact) to rendering (so it can also be used with other libraries, e.g. WebGL), and you can record the messages going through the worker to replay and analyze a scenario.

So far I'm happy with this setup, but I can understand the allure of thirdparty libraries instead.

I've become a big believer in separately managed state. Even if something would convince me to move away from Redux I would still stick to the pattern of dividing code into three stacks: data/state management, components, and stateful glue code (AKA reducers, components, and containers in the React universe). Redux is most useful in that it keeps you honest to this paradigm and that it provides some nice dev tools -- the library itself doesn't really matter. I don't think there's anything wrong with a global event bus in theory but in practice it often lends itself to abuse. In fact, I'm currently moving a legacy application to React/Redux and found that the global event buses were a good idea in theory, a spaghetti factory in practice.

I also think seperating state from the view components is a great idea. But I don't see that a Redux-like approach is needed for that. What I deployed successfully in a larger app was just some normal kind of MVVM architecture: I implemented service components (in form of Typescript/ES6 classes) which store the state they care about and expose getters for the current state and mutating functions for changing the state. These are basically the M(model) parts of MVVM. The view components (Angular2 viewmodels as well as React components) get the services injected and use the latest data from the services in order to render it into the view (oneway data binding). If realtime updates from the service to the view are required then the services can expose their state as Observables, to which the ViewModels can subscribe. I like the approach, because it allows the data-consumers (view-components) to see the sources (models / services) just as a domain specific strongly typed interface, which allows to change the state and retrieve it with normal object-oriented patterns. Dispatching some non-strongly typed action into an eventbus and hoping that anybody will care about it seems less type-safe approach to me.

Have you considered something like Cycle JS (https://cycle.js.org/)? It seems to line up with your aim to maximize separation of concerns and make things predictable.

Having used both Flux and Redux for fairly large projects for the past two years, I have finally come to the conclusion that I really don't need either. I tried to summarize my alternative here, although I'm sure many will disagree:

http://zen.lk/2017/05/08/you-might-not-need-redux/

I have been using React Native for a year now on a large project and came to the same conclusion. I find using Redux can quickly lead to over-engineered software.

As goes with every extra dependency: don't use it until you actually need it.

It's worked out really well for a large dashboard I'm working on. Compared to what we had before which was a mess of duplicated API calls in views with the same error handling code copy pasta'ed everywhere, with all different flavors of state management. It's not perfect (like the explosion of constants), but is probably 10x easier to maintain than what we had before.

I will say that using it by itself is probably going to be challenging. You'll want to use a connector library (like react-redux in this case), invest in some good API middleware, etc.

I hate to pile on, but we introduced react and redux at my startup and it (the project, not the company) largely failed due to the increased complexity of redux itself, and a coding style of hyper abstraction.

Maybe it works on large teams and code bases, but it is unnecessary on smaller teams where sane code practices are enough.

Can you give some details on what issues you ran into, and what "hyper abstraction" meant?

I wish "Redux" would go away. It's the worst thing about the React ecosystem. I use quotes because it's not even much of a library. It's like 100 lines that no one needs because the abstraction they provide is leaky to the max (e.g. no support for nested denormalied data). And it comes with pages and pages of documentation that says little or even nothing while tricking newcomers into thinking they're learning something about a useful tool.

It's remarkable to me that real clients like Relay haven't caught on as much while Redux wastes so many peoples' time.

I've worked at one fortune 100 and one fortune 500 both using React and Redux. I second the notion that Redux is over complication.

I'm a Redux maintainer, so I'll address the Redux side of things.

The author of that post primarily claims that the main reason to use Redux is about keeping state in sync. That's _a_ reason to use Redux, but not the _only_ reason. Having a single store allows use of a middleware pipeline for centralization of things like logging, API calls, data transformations, and much much more. Having a single state tree and serializable plain object actions allows powerful developer capabilities like time-travel debugging, state persistence, and even synchronization of remote stores via transmitted actions. Use of "pure function" reducers is also key for time-travel debugging, as well as making it straightforward to trace where state changes came from, and are generally easier to test.

The author _is_ correct that a centralized store does make encapsulation harder to work with. That's a deliberate tradeoff. (Encapsulation isn't _impossible_ with Redux, but it definitely takes more work.)

Dan Abramov's article "You Might Not Need Redux" [0] discusses many of the common complaints about use of Redux, and the tradeoffs that Redux asks for and gives you. Also, my recent two-part post "The Tao of Redux, Part 1 - Implementation and Intent" [1] and "The Tao of Redux, Part 2 - Practice and Philosophy" [2] goes into detail on what actual technical limitations Redux requires and why, why common Redux usage patterns exist, and my opinions on the pros and cons of many "variations" in how Redux _can_ be used. (In particular, it's entirely up to you how much abstraction you apply, how you structure your codebase, and how much "boilerplate" you are comfortable with.)

Redux is certainly not the perfect solution for every problem, and it's generally not going to be the solution with the fewest LOC. However, it _is_ a powerful and useful tool for organizing your state and logic, and there _are_ valid reasons why its constraints and common use patterns exist (and complaints about those patterns rarely take those reasons into consideration).

[0] https://medium.com/@dan_abramov/you-might-not-need-redux-be4...

[1] http://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao...

[2] http://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao...

You can have a centralized store in MVC. Here's a simple MVC framework (less than 500 lines) that works with React: https://github.com/rajeev-k/mvc-router In this framework the Application object holds the centralized store. No need for MVVM, Redux etc. React is the V in MVC.

I'm using redux both at my day job and on my side startup. For the day job, right now, it's simple enough we don't really need redux. But it was already in play when I joined and it's not really a bad thing in terms of team communication in code so... On my side startup, I definitely need redux. I have a lot of related data that is rendered in multiple ways and soon I'll be hooking up websockets and emitting changes from server-side that will flow into the client UI via redux to keep some things in sync.

Redux does add complication. But it also cleanly solves a big problem. I've heard good things about mobx instead of redux in terms of reducing boilerplate/total lines of code. So that might be one thing to try if starting a new project today or refactoring.

The purposed solution in the blog is pretty bad. It only works if you have a few things being updated. It might work fine for the author's use case but it's a bad idea to assume it will work well for all use cases. If you want to go this route, please try Backbone.js and come back when you get sick of ghost event listeners (event listeners that didn't get unbound). Obviously, there are ways to work around those issues but it requires understanding them (both by you and any other devs who join the project -- some with less experience might have no idea about these gotchas).

Never mind any paradigms or anything, I believe a lot of the popularity of Redux boiled down to two things:

1. It was there at the right time, when people started getting serious with React and were looking for a way to structure their data flow.

2. Tooling. Soon after it was released, the author demonstrated a pretty neat hot-reloading utility.

So no matter whether you're really into functional purity or are reminded of Win32 event loops, it was a practical solution.

Per the "Win32 event loop" comment, I suspect you're referring to https://bitquabit.com/post/the-more-things-change/ , where the author points out that Flux+React looks an awful lot like a Win32 WndProc function. (HN discussion thread: https://news.ycombinator.com/item?id=10381015 .)

My use case for redux separates the state and view across a physical process boundary (and not for kicks). The store is crucial there because it gives a place to hook in as both a proxy and as a coordinator between the processes. This use case isn't normal but the recommended approach would not work without me reinventing all of those concepts at the end of the day.

What irks me about the Flux ecosystem / JS in general is the strange divergence between what is required (immutable data structures) and what new language features provide (ES6 classes). Immutable.js alleviates some of the pain of having to do full copies on state mutation, but this does not work in a satisfactory way with ES6 classes.

If the tendency of the developer community is towards (faux) functional programming, why is the language taking a OO direction (with the community actively discouraging using ES6 classes)? Coming from OO languages, I'd like to use ES6 classes, but I can't because I'm told it's not idiomatic and I don't want my code to stand out like a sore thumb. So, "native" JS devs don't want to use ES6 classes, and OO devs gone JS cannot use ES6 classes without looking like fools; why is the feature there?

>Coming from OO languages, I'd like to use ES6 classes, but I can't because I'm told it's not idiomatic and I don't want my code to stand out like a sore thumb.

Simply, ignore them. That's just noise from the huge influx of JS developers and the immutable/functional cargo cult train. ES6 classes are perfectly fine, they're a sugary layer on top of prototypal inheritance, that merely formalizes how almost everybody was already using it.

Nothing wrong about ES6 classes, and nothing that great about pure prototypal inheritance anyway (which they still are).

>cannot use ES6 classes without looking like fools

For one, ES6 classes are the recommended way from the React team.

Second, don't worry about how you "look".

Programming is a discipline, not a cargo cult or pop culture to fear of being "uncool".

> why is the language taking a OO direction

Classes are just sugar over how devs were already doing class-like stuff with prototypes (see backbone/ember/angular etc). So I'd disagree that the language is 'taking an OO direction'.

> If the tendency of the developer community is towards (faux) functional programming

Wouldn't agree with that either. Some sub-communities perhaps. But e.g. in React there's a big push back towards using (class-based) Components and good old setState().

> I'd like to use ES6 classes, but I can't because I'm told it's not idiomatic

These people need re-informing! React Components and setState() are what Facebook use. In my opinion, setState() plus a router will handle the vast majority of state in your app just fine.

To get more of a feel for this setState() vs Redux kerfuffle:

Ryan Florence (of React Router) is a Components/setState proponent, and great person to follow on Twitter. I like his intro to this talk [1] where he talks about the issue. Also highly recommend reading 'Functional setState is the Future of React' [2]. And of course I think it's already been posted elsewhere in the thread, but Dan Abramov's own 'You might not need Redux' is definitely worth a read [3].

[1] https://www.youtube.com/watch?v=kp-NOggyz54

[2] https://medium.freecodecamp.com/functional-setstate-is-the-f...

[3] https://medium.com/@dan_abramov/you-might-not-need-redux-be4...

Thanks; will watch/read!

Store is a dumb JSON object, you don't need methods for it. Actually ES6 has some very handy syntax like `{...old, newProp: newValue}` to support immutability. And React components can and should use ES6 classes.

If you want pure OOP approach, check out mobx. It's a popular alternative to Redux.

Note that the object spread operator is still only a Stage 3 proposal, although I believe it's just been implemented in Chrome. The array spread operator was in ES6, and JSX syntax also supports an object spread inside of angle brackets.

Those are two different things.

React, in its current form, requires classes or something class-like in order to implement stateful components with lifecycles. It also does not require that you handle data immutably - you can run `this.state.someArray.push(newValue); this.setState({someArray : this.state.someArray})`, and React will re-render just fine.

However, React also pushes you in functional programming directions: render methods should be pure functions, performance optimizations with `shouldComponentUpdate` work best if you've handled data immutably, and so on. The React team also plans to investigate a "stateful functional component" API at some point after the React 16 release.

It's also worth noting that React was not the only reason why classes were added to Javascript. There were hundreds of "pseudo-class" implementations out there already (all a little bit different than the others), and there was clearly enough demand for the concept to add it to the language in a standardized way.

Meanwhile, Redux has definitely helped popularize the idea of updating data immutably. The array spread operator was already added in ES6, and the object spread operator is nearing finalization. No, the language doesn't have full-blown immutable data structures, but handling data immutably is absolutely possible. If you don't like dealing with immutable updates yourself, there's Immutable.js (as you said), or dozens of immutable update utility libraries.

Particularly in the case of Redux, use of classes for data is discouraged because of the other constraints Redux asks you to follow. Plain serializable data is needed in order for time-travel debugging and persistence scenarios to work properly.

Overall, your complaints are split across a couple things. Classes exist because some JS devs want to use them. Functional-style approaches exist because some devs want to use them. Languages like C# and C++ have been "everything and the kitchen sink" for a while now, supporting multiple different paradigms in one language - Javascript is now the same way.

I don't use Redux for my website @ https://www.land.plus/ all states are managed locally in the component's instance variable. In some cases a global variable is used within the component file if single page persistency is needed. For inter-components state, i use Javascript CustomEvent & addEventListener instead. Am i doing something wrong for not using Redux?

THe problem I've found with this approach is that it gets very messy very fast. It's hard to track down bugs to their source.

One of my favorite aspects of Redux is how easy it is to follow the flow of data. Whatever you do, you start at a dom element, look at what action creator it calls, and check out the changes in the reducer.

Yes, agree it is a bit messy now but still manageable as i wanna delay using Redux / Mobx as long as possible.

I've also delayed introducing Redux to a project before, and it was a mistake. After a few weeks of convincing, I got time to add Redux to a project, and it's immensely difficult because of how much needs to be restructured. It's better to just start with it if you're going to end up creating something large enough or complicated enough to warrant it.

In theory, if you've been following a "container component"-type approach, you _should_ be able to start replacing those hand-written containers with Redux-connected ones.

What kinds of issues and restructuring problems did you experience?

No, that's not "wrong". But, it does sound like the kind of case where Redux might be useful.

Yeah, that's why i suspect it might be a a good use case for Redux but not very sure. Hopefully something better (Mobx, etc.) comes along when i decide to implement a state manager.

Well your site works, doesn't it? Can't do something wrong if your site is all right.

Compared to my JQuery days, it is a big improvement in terms of maintainability now. No complaints!

If your application is small enough where a global event emitter is makes your code clear enough to get the point across and wont make you pull your hair out - I'd argue that React, forget Redux, is probably overkill anyways. There are better frameworks (or just not using one at all), that are more fitted for this and won't have you spending the first 3 hours setting up webpack.

create-react-app works out of the box for small applications and automatically sets up webpack to sane configurations. I've found that setup ideal for small apps.

It's only on the larger apps with more complex customization where I have found the need to use anything other than the default webpack configurations other than the default create-react-app ones.