6 ms·

Just curious, what do react folks think about this blog post:http://joonhachu.blogspot.com.au/2015/12/dont-use-flux-or-redux-for-react.html http://joonhachu.blo

Just curious, what do react folks think about this blog post:http://joonhachu.blogspot.com.au/2015/12/dont-use-flux-or-redux-for-react.html http://joonhachu.blogspot.com.au/2015/12/dont-use-flux-or-re... To me, the application wide bus paradigm is elegant, and find it surprising that redux is currently more fashionable than this approach. Thoughts?

nemothekid 9y ago
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.
- sfifs 9y ago
  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.
- deleted 9y ago
  [deleted]
acemarke 9y ago
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-be46360cf367 https://medium.com/@dan_abramov/you-might-not-need-redux-be4... [1] http://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao-of-redux-part-1/ http://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao... [2] http://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao-of-redux-part-2/ http://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao...
- petilon 9y ago
  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 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.
ng12 9y ago
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.
- Matthias247 9y ago
  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.
- PettyAdm 9y ago
  Have you considered something like Cycle JS (https://cycle.js.org/ https://cycle.js.org/)? It seems to line up with your aim to maximize separation of concerns and make things predictable.
mhd 9y ago
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.
- acemarke 9y ago
  Per the "Win32 event loop" comment, I suspect you're referring to https://bitquabit.com/post/the-more-things-change/ 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 https://news.ycombinator.com/item?id=10381015 .)
ngsayjoe 9y ago
I don't use Redux for my website @ https://www.land.plus/ 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?
- acemarke 9y ago
  No, that's not "wrong". But, it does sound like the kind of case where Redux might be useful.
  - ngsayjoe 9y ago
    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.
- wry_discontent 9y ago
  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.
  - ngsayjoe 9y ago
    Yes, agree it is a bit messy now but still manageable as i wanna delay using Redux / Mobx as long as possible.
    - wry_discontent 9y ago
      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.
_pmf_ 9y ago
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?
- vbezhenar 9y ago
  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.
  - acemarke 9y ago
    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.
- allover 9y ago
  > 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 https://www.youtube.com/watch?v=kp-NOggyz54 [2] https://medium.freecodecamp.com/functional-setstate-is-the-future-of-react-374f30401b6b https://medium.freecodecamp.com/functional-setstate-is-the-f... [3] https://medium.com/@dan_abramov/you-might-not-need-redux-be46360cf367 https://medium.com/@dan_abramov/you-might-not-need-redux-be4...
hliyan 9y ago
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/ http://zen.lk/2017/05/08/you-might-not-need-redux/
- thedjinn 9y ago
  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.
- chrshawkes 9y ago
  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.
- linkmotif 9y ago
  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.
- yesimahuman 9y ago
  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.
wildpeaks 9y ago
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.
sb8244 9y ago
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.
Cymen 9y ago
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).

nemothekid 9y ago

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.

sfifs 9y ago
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.
deleted 9y ago
[deleted]

acemarke 9y ago

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-be46360cf367 https://medium.com/@dan_abramov/you-might-not-need-redux-be4... [1] http://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao-of-redux-part-1/ http://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao... [2] http://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao-of-redux-part-2/ http://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao...

petilon 9y ago
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 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.

ng12 9y ago

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.

Matthias247 9y ago
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.
PettyAdm 9y ago
Have you considered something like Cycle JS (https://cycle.js.org/ https://cycle.js.org/)? It seems to line up with your aim to maximize separation of concerns and make things predictable.

mhd 9y ago

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.

acemarke 9y ago
Per the "Win32 event loop" comment, I suspect you're referring to https://bitquabit.com/post/the-more-things-change/ 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 https://news.ycombinator.com/item?id=10381015 .)

ngsayjoe 9y ago

I don't use Redux for my website @ https://www.land.plus/ 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?

acemarke 9y ago
No, that's not "wrong". But, it does sound like the kind of case where Redux might be useful.
- ngsayjoe 9y ago
  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.
wry_discontent 9y ago
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.
- ngsayjoe 9y ago
  Yes, agree it is a bit messy now but still manageable as i wanna delay using Redux / Mobx as long as possible.
  - wry_discontent 9y ago
    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.

_pmf_ 9y ago

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?

vbezhenar 9y ago
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.
- acemarke 9y ago
  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.
allover 9y ago
> 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 https://www.youtube.com/watch?v=kp-NOggyz54 [2] https://medium.freecodecamp.com/functional-setstate-is-the-future-of-react-374f30401b6b https://medium.freecodecamp.com/functional-setstate-is-the-f... [3] https://medium.com/@dan_abramov/you-might-not-need-redux-be46360cf367 https://medium.com/@dan_abramov/you-might-not-need-redux-be4...

hliyan 9y ago

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/ http://zen.lk/2017/05/08/you-might-not-need-redux/

thedjinn 9y ago
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.
chrshawkes 9y ago
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.
linkmotif 9y ago
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.
yesimahuman 9y ago
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.

wildpeaks 9y ago

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.

sb8244 9y ago

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.

Cymen 9y ago

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).