18 ms·

Redux – Not Dead Yet

228 points by fagnerbrack 9y ago

hliyan 9y ago
In 2016, we developed several very large applications using Redux. The clarity/simplicity gains quickly evaporated as the system grew in size. The experience led me to develop an alternative [1], which I have shared here before. We used it for several production components and the productivity and testability gains were very clear. [1] https://hackernoon.com/transmission-tx-a-flux-alternative-fe0630eed2a3 https://hackernoon.com/transmission-tx-a-flux-alternative-fe...
- atombender 9y ago
  What you describe in that blog post is essentially classical MVC, as far as I can see, except you don't use the term "controller" and all state changes are requested via events instead of being made directly on the data model. But many MVC systems work like that -- it's not like MVC is standardized. What this doesn't really get you compared to Redux is a consistent, serially updated, immutable state tree, and every state ("engine") becomes a somewhat ad-hoc event manager. Redux does get the concepts right, in my opinion. Your system doesn't really solve anything better, as far as I can see; it just calls actions "events" and splits the state tree into "engines". Redux is too simplistic, though. It does nothing to solve some of the actual hard problems people face in an MVC system, such as async loading (which comes with a bunch of can of worms: Retries, error handling, idempotency, progress events, cancellation, etc.). I don't know of anything that does this well on top of Redux. The fact that the event model and state tree are both global and shared means Redux makes it hard to encapsulate stuff, too. Encapsulation is less of any issue if there is a single instance of everything; if you have a single user controlling the page, then it makes sense that there's just one global user, and one global state for each of the user's things. But often you have multiple instances of state, and there are no tools to help you coordinate events and actions. For example, say you have a page that wants to display several charts in different boxes, and users can add new charts to the page. Every chart component "points" to which dataset it wants to render, and each dataset is a separate node in the state tree identified by ID. The actions and events then all have to refer to this dataset ID; you effectively get a little "routing layer" for actions where each action needs to look up the state by dataset ID to get the actual thing to operate on. I've not found any reusable tools to handle this. One reason Redux doesn't scale well is just the amount of boilerplate and repetition. You can solve this with some smart meta programming, especially in TypeScript. But it's not entirely a solved problem.
  - pests 9y ago
    For async, do you have issues with redux-thunk? Or the generalized concept of intercepting actions with a middleware and then responding with further actions that are handled exactly as normal? For the charts example, I would just instantiate a new redux store with its own state. The reducer can be reused between chart instances. Then just dispatch other action(s) to your main redux store if you need chart state in your main store.
    - lobster_johnson 9y ago
      I don't mean promises; thunks are fine, but don't solve the hard problems. I mean actions that start asynchronous processes such as fetching data remotely via XHR. In the end, such actions tend to be extremely similar. I tend to have groups of related actions that all such actions need. LOAD_FOO_REQUEST, LOAD_FOO_SUCCESS, LOAD_FOO_FAILURE, etc. A middleware can regex-match on the action name and count how many are in flight to render load progress. Similarly, errors can be caught that way. Idempotency is a bit harder. Often a load action has several dependencies (e.g. you want to load data based on a query and a limit) that need to be encoded in something that represents that request so that if another request is issued, it can be ignored if it's identical. This ends up being boilerplate, too. Maybe one could write a generic middleware that tracked what the in-progress request is and skipped duplicate actions. Cancelation is harder. I've never done this with Redux, as the biggest blocker is that promises can't be canceled. Last I checked, WhatWG's fetch API doesn't either. Retrying, ugh. At least this one isn't too hard to make generic, since any Redux action can, in principle, be retried. In a recent project, I rendered a notification box with a retry button if an error event embedded a retry function, which in turn just resubmitted the action. But it wasn't a very general-purpose solution.
      - acemarke 9y ago
        Legitimate question: how would you expect Redux _or_ any other state management framework to solve those problems for you? Or, to phrase it another way: how do other frameworks or libraries actually tackle this problem already, in a way that Redux doesn't? My own apps have been fairly simple in that regard, so while I've seen a bunch of libraries to handle data fetching in various capacities, it's not an area I've had to deal with myself. So, I'm not sure what kind of "other framework handles it this way" comparisons exist.
coding123 9y ago
Was on a team at a large company - and the architects had a decree that everyone must use React - good decision. Except one problem was that everyone was just using Redux like it was part of React or something. I don't know how many components that had to maintain their own state got stuck in Redux nightmare land where special keys were being used to keep each component separate - it was a complicated mess inside the react component. This component didn't map to a single concept of state, instead many "copies" and different versions of that copy could be on the screen at once - and no one really "got it" that they were feeding really deep into a major anti-pattern. I kept pointing out to members of the team that even Dan Abramov's post about maybe not needing Redux... but it fell on def ears like I didn't "GET" redux. I totally understand the enticing time-travel feature, but I think too many people jumped on the ship before it was ready for the use-cases different folks had in mind.
- 0xCMP 9y ago
  Yea seems like people reach too much for larger "state management" via Redux/Mobx/etc. too quickly without thinking what that means instead of just using State updated via callbacks passed as props. Clearly Redux solves the times where doing that isn't really clear or gets complicated, but often times it sounds from Twitter + Conversations that everything is getting thrown in to Redux for no reason.
  - ojosilva 9y ago
    I resisted for a long time, but finally switched from a callback model to Mobx and the reason was that ShouldComponentUpdate and ComponentDidUpdate started becoming unbearably hard to manage. So state management libraries are not solving a unsolvable problem, they are here so that we can write cleaner, more efficient code that potentially can become more performant. At least that's what happened in my case.
    - baddox 9y ago
      Can't you use pure components as long as you make sure that all your callbacks are called with new objects, e.g. using the JavaScript spread notation? I think the bigger reason that a global state management system becomes necessary is when the shape of your component tree doesn't closely match the shape of your state tree, because that means state (and callbacks) need to be passed down through components that don't care at all about that state simply because one of their distant descendant components does care about it.
bigtunacan 9y ago
I'm not going to make any claims that Redux is dead or dying; I'm mostly oblivious to the state of React (no pun intended). I'm coming from Knockout and Angular making the switch to Vue. This line from the article got me though. "plus all of its usage with other JS frameworks like Angular, Ember, and Vue" Are people actually using Redux with Vue? Everyone I know is using Vuex for state management for Vue.
- swyx 9y ago
  yes i have been wondering who uses redux without react. redux tries so hard to be a react independent library, but maybe it shouldnt. ¯\_(ツ)_/¯ the maintainers do not agree.
  - acemarke 9y ago
    And why shouldn't it be independent of React? While Redux and React-Redux were developed together, the Redux core is 100% pure plain vanilla JS, and the fact that bindings exist for a whole bunch of other frameworks shows that it works fine that way. Now, Dan and Andrew have suggested that in order to have React-Redux work properly with the upcoming async React rendering, we should possibly consider reimplementing the Redux store logic to use React component state as the basis. In other words, you'd probably do something like `import {createStore} from "react-redux"`. I'm not keen on that idea myself, and am hopeful we can find an approach that will allow use of a separate standard Redux store and still get the benefits of async React rendering down the road.
    - swyx 9y ago
      maybe what im really after is what react-router-dom does, which is reexport react-router. stop making me wire up the core library itself, if you have a binding it should "just work" (TM)
  - tomduncalf 9y ago
    Although anecdotally the opposite (people using React without Redux) is increasing (whether they are using component state, MobX or something else), so I don’t think from that point of view (as well as others!) it would make sense for Redux to be “part of” React
ghayes 9y ago
As an avid Elm user, I am happy to see continued usage of Redux. Redux does a great job of bringing functional reactive programming to React.
- swyx 9y ago
  functional, yes. Reactive? no.
tootie 9y ago
The react context API is an abomination. How is tag-nesting an API?
- mephitix 9y ago
  How is tag-nesting not considered an API for React? The entire point of the new context API is to get around prop-drilling. Being able to do that and express the intent in JSX is what it does well IMO...
  - hestefisk 9y ago
    Context to me seems like a sophisticated way of declaring global variables. Might as well do const GLOBALS = { ... } instead of another complex API that has to be loaded.
    - eropple 9y ago
      It's not, though, any more than dependency injection is "declaring global variables".
    - crooked-v 9y ago
      The new context API effectively makes variables available globally, but you're still using a separate (explicitly declared) Consumer for each, so you don't have any of the basic issues that go with using a single set of globals. For a very simple example: import { UserIdConsumer } from '@/contexts' const ThisComponent = () => ( <div> User ID: <UserIdConsumer>{value => value}</UserIdConsumer> </div> ) export default ThisComponent
      - hestefisk 9y ago
        Not sure I follow. Where does value come from?
        tym0 9y ago
daveidol 9y ago
Personally, I find Redux to be a joy to use and write code with. I agree that there is a lot of "boilerplate" for new developers, as Redux does not really come with a batteries-included "framework" to build CRUD apps -- that's on you to figure out and write. One you do write this framework in Redux, however, you can reuse it and the amount of unnecessary boilerplate goes to near zero in my experience. We just need a de facto open source framework built on top of Redux for people who haven't worked with it extensively to build with.
- acemarke 9y ago
  I know. I've seen _many_ other higher-level abstractions on top of Redux (per my comment elsewhere in the thread). A year ago, I opened up an issue [0] to discuss ways we could improve the "getting started" experience, reduce boilerplate, add better abstractions on top of the base primitives, etc. The thread got some decent comments, but nothing really concrete came out of it. A few months ago I had a little bit of free time, and threw together a tiny "starter kit" library [1] that is intended to simplify a couple of the common pain points (basic store config, and writing reducers with immutable updates). I haven't had time to push it further, but long-term it's likely to become an official Redux-branded "use this to get started" addon. I'm very open to further ideas and suggestions around this topic. [0] https://github.com/reactjs/redux/issues/2295 https://github.com/reactjs/redux/issues/2295 [1] https://github.com/markerikson/redux-starter-kit https://github.com/markerikson/redux-starter-kit
  - daveidol 9y ago
    Cool! I hadn't seen that. I like the idea of a solid starter kit library, although (from quickly reading the README for your starter kit) I think it should probably include more: specifically facilities for making HTTP calls, serializing/deserializing request and response data, caching data and fetch status for the requests, etc. From working with people who haven't used Redux before - these seem to be common things people new to Redux want to do but find difficult to get started. (The boilerplate around making actions and switch statements, etc. seems a bit secondary in my opinion) However, I realize the "proper" way to do the things I listed above is inherently pretty opinionated, so I totally understand why the Redux library itself has avoided including these things (it's much more flexible as-is; and probably why it's been so stable and stood the test of time).
bnchrch 9y ago
Redux is far from dead but I do think apollo-link-state has the ability to take its crown if GraphQL continues to gain wide adoption; which I believe it will. Though it's a very new library (Dec 2017) so it has a long way to catch up in terms of tooling and support. I just happened to write an article on apollo-link-state for those who are curious about how it's used. https://hackernoon.com/setting-up-apollo-link-state-for-multiple-stores-4cf54fdb1e00 https://hackernoon.com/setting-up-apollo-link-state-for-mult...
- colept 9y ago
  Love Apollo - they're a great team with many of great open source offerings. Apollo link state excites me because it unites remote and local data under a single source of truth. As a long time Redux fan, it will be nice to have one less layer and dependency to debug. GraphQL as a uniform layer for accessing that source of truth is in my mind, a Redux-killer.
- acemarke 9y ago
  So I haven't actually used GraphQL at all, although I've sat through a bunch of talks on it and am pretty familiar with the concepts. That said, I have to say that the examples I'm seeing for setting up link-state mutations don't look like they're particularly concise. Given that "boilerplate" is a typical complaint about Redux (which can itself be handled with whatever abstractions you want to put in place), I'm not seeing the appeal here. Is it just a case of "we're already using GraphQL, so GraphQL all the things" ? (Note that the article itself doesn't use the word "boilerplate", I'm just pointing at that as a reason I've seen people throw out for wanting to move to link-state.)
  - city41 9y ago
    apollo-link-state would almost certainly be considered a hack if it was made by anyone else other than the Apollo team. Just the fact you need to manually specify the __typename field feels wrong to me. But I do have hopes that Apollo will grow and improve here, and apollo-link-state will likely evolve into an elegant tool.
mephitix 9y ago
I started using Redux with container components and dumb presentational components - this worked and scaled well. Eventually though some containers started to have their own state, derived from props. Ultimately I was left with the feeling that I wasnt really getting the full benefits of redux (time traveling, centralized middleware, etc) without moving all state in my app to Redux. I think this is how teams get trapped by Redux - the pursuit of having nice dev accordances like time traveling leads them to adopt Redux everywhere and just by Redux’s nature (immutability, declarative actions) it ends up complicating things way too much. I think the article I’m most grateful for is Dan’s article on container vs presentational components. Sticking to that philosophy let me adopt Redux and try it out but still have the majority of my app in dumb, non-Redux presentational components. So now it’s easier to remove Redux if I need to.
- acemarke 9y ago
  We do try to emphasize that it's completely up to you how much or how little state you actually put into Redux: https://redux.js.org/faq/organizing-state#do-i-have-to-put-all-my-state-into-redux-should-i-ever-use-reacts-setstate https://redux.js.org/faq/organizing-state#do-i-have-to-put-a... . I've certainly talked to people who literally put every single value in their app into Redux (often in conjunction with _only_ using functional components). I can understand why they might choose that approach, but to me that's over-opinionated. Most of my app-type data does go into Redux, but it's absolutely fine to use React local component state for whatever doesn't need to be shared.
  - FundThrowaway 9y ago
    That's one of my favourite parts of Redux is how flexible it is, use a little bit here and there where it's appropriate. The current project I'm working uses Redux to manage all of the websocket communication but that's it.
- fastball 9y ago
  I think you should generally start by putting everything into Component state, and only move stuff to the store if you find yourself needing to do a lot of prop-drilling. Time travel is nice, but it is not worth putting everything into your Redux store.
sailfast 9y ago
Great post and good clarifications about the future of Redux - thanks! Happy user of Redux in both a React app and an Angular app. Makes managing state in Angular (not to mention testing where ordinarily multiple controllers might be involved) so much cleaner. Thank you for your hard work, maintainers!
acemarke 9y ago
Oh hey, that's my post. So, uh... Redux co-maintainer and author of that post here. Happy to answer questions and point people at possible solutions :)
- pimlottc 9y ago
  Any comments on the relationship between redux and rematch?
  - acemarke 9y ago
    Not sure what there is to comment about relationship-wise. From what I've seen, Rematch appears to be a higher-level abstraction library built around Redux. I've seen a lot of those (most of which I've linked in the "variations" page of my Redux addons catalog: https://github.com/markerikson/redux-ecosystem-links/blob/master/variations.md https://github.com/markerikson/redux-ecosystem-links/blob/ma... ). I haven't had time to try it myself, but it looks conceptually interesting.
- daveidol 9y ago
  Thanks for doing what you do. I contributed some of the initial documentation [1] for testing middleware back in the day. Wondering if there are any areas in particular you'd be looking for contributions? I use redux every day and would like to contribute back some (if it would be helpful). [1] https://github.com/reactjs/redux/pull/559 https://github.com/reactjs/redux/pull/559
  - acemarke 9y ago
    Yes, absolutely! I have a _ton_ of additional docs improvements I'd like to see. Most of those are currently listed as open issues with a "docs" tag [0], and I've got some other docs ideas floating around in my head besides those (like completely revamping our docs around React-Redux). Beyond that... oh, boy. I'd love help maintaining my React/Redux links list [1]. I've been really busy the last few months and have fallen behind on adding new links, and it could also use some maintenance attention to look at the existing links and figure out which ones are outdated and not really useful any more. The "starter kit" lib I threw together [2] could use more design work and ideas to figure out what other "batteries included" type things we would want to include out of the box as an official Redux-branded library to solve some of people's common pain points. React-Redux has some open PRs related to React 16.3 [3]. It's starting to look like we need to put together a bigger v6.0 major version release with some combined changes, and it would be good to get more eyes on the situation to figure out what's needed. There's also an open PR for adding an "object shorthand" for selectors with `mapState` that's been lying around for a while waiting for someone to add some tests so that we can say we're happy with how it works and merge it. [0] https://github.com/reactjs/redux/issues?q=is%3Aissue+is%3Aopen+label%3Adocs+sort%3Aupdated-desc https://github.com/reactjs/redux/issues?q=is%3Aissue+is%3Aop... [1] https://github.com/markerikson/react-redux-links https://github.com/markerikson/react-redux-links [2] https://github.com/markerikson/redux-starter-kit https://github.com/markerikson/redux-starter-kit [3] https://github.com/reactjs/react-redux/pulls?q=is%3Apr+is%3Aopen+sort%3Aupdated-desc https://github.com/reactjs/react-redux/pulls?q=is%3Apr+is%3A...
iandanforth 9y ago
I've had a mixed history with Redux. It always felt like a ton of overhead to maintain on top of React. However I recently started using Rekit (http://rekit.js.org/ http://rekit.js.org/) which is a web-based IDE specifically for React+Redux and I'm loving it. All the patterns the IDE defaults to (and in some cases enforces/automates) are ones that I had to learn painfully (and repeatedly) in other contexts. Now when I need a new action I get the paired reducer, top level reducer tie-in, tests, all for free. It's great! Try it out on your next project!
ralusek 9y ago
I've been using mobx-state-tree for the latest couple of projects after Redux. I like them both, but I prefer mobx-state-tree for a handful of reasons. 1.) There is an immutable data store with action-driven changelog, just like Redux. 2.) The immutability of the data store is baked in and enforced. The necessity to provide changes to the data store within an action is baked in and enforced. 3.) Having actions baked in as methods rather than having to create "action creators which in turn dispatch actions" is a nice reduction in boilerplate. 4.) Being able to add action listeners AND state listeners are baked in, and can be done at any level of the state's depth. To watch state changes in redux, for global changes not related to a particular component, I had to write: https://github.com/ralusek/redux-store-watch https://github.com/ralusek/redux-store-watch 5.) Mobx's observers on react render methods makes the renders far more efficient than what could be achieved with react-redux easily, without really ensuring that the props being passed in are as granular as necessary or shouldComponentUpdate is correctly identifying state changes. In mobx, the most granular access of the lowest level state can be detected within a render method, and only when that very specific value is replaced is the component rendered. 6.) Computed values on mobx-state-tree are baked in without the need for something like reselect I like Redux, I enjoy working on projects that use it, but I think that I think I'd have to admit that I prefer mobx-state-tree.
- johnwheeler 9y ago
  React ecosystem noob here. To point #5, I remember reading that MST has some overhead over Mobx, does it come into play with these renders?
  - tomduncalf 9y ago
    I investigated MST for a React Native project and found the the additional overhead it created for frequent state updates was too much - in a synthetic test updating state every frame, it resulted in a 30-40% increase in CPU usage on a real device vs. plain MobX which for our application probably isn’t acceptable. If you know you won’t be making really frequent state updates or CPU constraints are less important it seems like a great option!
  - 9y ago
twfarland 9y ago
Redux has been great, but after a few years, I've had enough of the action creator and reducer boilerplate, and now just use Proxy objects for external state (with a listener on the handler's setter). It's mutable but hasn't been a problem in practice.
elliotlarson 9y ago
I've built a couple of applications with React. I've spent the last 6 weeks on a contract where I'm building a React based Google maps widget. I'm getting to the point where I'd like to break up a large "smart" component into smaller, more maintainable smart components. So, I'm looking for a state management library to help. I've walked through some training courses at Udemy on Redux and I've built a small personal project with it. I don't want to beat a dead horse, but the boilerplate is really off putting. I feel like I'm being exposed to the internals of a framework that's missing some higher level API abstraction that makes state management less onerous. I think the Rematch library presents a nicer surface API: https://github.com/rematch/rematch https://github.com/rematch/rematch. But, I'm hesitant to use it over Redux for client work because I want to make sure I develop something that's easy to hand off, and Redux is sort of king right now. I just spent some time with the apollo-link-state docs. I know it's young, but this does not look like an improvement over the Redux state management API. Hopefully if this is to be the Redux successor, the API will improve with maturity. I kind of wish Ember Data was usable as a standalone library. It looks like such a nice, easy to use wrapper around state and data management.
- spicyj 9y ago
  Curious what things make you reach for a state management library vs staying with React’s built-in state when splitting up components.
  - elliotlarson 9y ago
    My main smart component is several hundred lines long at this point. The methods in the component are largely event handlers used to manipulate the component's state object. The methods are passed down into the hierarchy of "dumb" components via props, and are called when actions occur in those components (e.g. onClick some element). The methods are conceptually group-able into 4 distinct areas of data manipulation. However, the catch is that many of the event handler methods need to modify other pieces of the state object too. So, for example, I have a number of methods related to polygon state management. I'd like to move these into a <Polygons /> smart component, but when updating a polygon, I also, in some cases, need to update data for another potentially extractable smart component <Toolbar />. A state management library would allow me to move/group data management logic into smart components that would also still have access to other parts of the state tree.
sktrdie 9y ago
One major problem we had with Redux, especially in a large organization where reusability is very important, is that we found it hard to reuse most of the redux logic (reducers/thunks/selectors). The pure components were easily shared across different teams, but most of the other stuff was too much redux or app-specific that we couldn't really reuse it. We experimented with simply using large stateful react components instead of redux for certain areas of the app, and our reusability improved dramatically. Any thoughts on how this is tackled by some hardcore redux users?
- ff_ 9y ago
  It is a general problem (that is, not only Redux has it, but basically any React-based thing), and the pattern that works best for reusability (in my esperience) is the "pure component sandwich": you have a pure component which takes a bunch of functions as parameters (and is reusable, no framework-specific stuff) and wrap it in the app-specific component which implements these functions for the current app.
  - daveidol 9y ago
    Definitely agree, but I think the parent commenter was asking how to reuse redux-specific code, such as reducers, actions, etc.
- daveidol 9y ago
  Reducer, middleware, and "action creator" factories that take config will allow for a pretty high level of reusability. We have several internal redux libraries of generic reducers, middleware, etc. and they all export factories that return these things instead of naked reducers, middleware, etc. The factories can take config for which action types to handle, etc.
  - bshimmin 9y ago
    This is great progress; given a little more time, I hope we will be able to recreate the fabled AbstractSingletonProxyFactoryBean!
chvid 9y ago
To be honest I always thought Redux to be hard-to-understand, obscure in its terminology and terrible over-hyped essentially doing something that could be much better described/modelled as a straight out application of the command design pattern.
- cooervo 9y ago
  Yes, the documentation loves to use complicated concepts and is very hard to understand. also its a ton of boilerplate code. I think redux just became hyped because of its "time travel debugging" which is just pure functions returning some stored values.
  - citrons 9y ago
    I also had a bit trouble learning redux (adopted quite early), but now there is video series by Dan Abramv that goes trough entire redux features is is easy to understand. But the conectps in redux IMO are worth learning, made me think about my own code different. More pure functions, less sideeffects...
Yaggo 9y ago
I hadn't considered Redux dead, but after that title from "them", I am now.
- rejschaap 9y ago
  Or at least that it is dying, since it is "Not Dead Yet"
songzme 9y ago
For those who don't know redux, here's a quick 5 min video from vimgirl. Personally, I like her short, straight to the point approach. https://youtu.be/SV_reBvGKPE https://youtu.be/SV_reBvGKPE It shows you redux as it is using plain javascript, without involving react, which gave me a clear idea of what redux actually is.
- mcintyre1994 9y ago
  The plain JS example is nice too: https://github.com/reactjs/redux/blob/master/examples/counter-vanilla/index.html https://github.com/reactjs/redux/blob/master/examples/counte...
baronseng 9y ago
Did anyone use dvajs https://github.com/dvajs/dva https://github.com/dvajs/dva and any comments?
jopsen 9y ago
This is why projects/libraries/services should list the pros/cons of using them. So people know when something is a fit, and that it's not always a fit. This pattern of some _thing_ becomes popular; everybody says to use _thing_; people use _thing_ where it's a bad fit; tsunami of people says _thing_ is broken. _thing_ keeps living. Examples: redux, react, S3, EC2, AWS lambda, heroku, docker, angular, ruby-on-rail, rust, golang, well every _thing_ :)
k__ 9y ago
Redux and MobX are overkill. What most people want is an easy way to pass down state to nested components, but the context API is a bit verbose and otherwise you end up with the props-drilling problem, passing and passing and passing. Problem is, Redux and MobX solve far more than this problem and in the end you are stuck with all the complexity they add, even if you don't need the other benefits they bring. In 80% of all apps you don't need much state. They don't have deeply nested components so you can simply store the state in your root components (Screen/Page) via setState and pass everything down via props. If you end up with deeply nested probs, use "unstated", it adds a bit better usability to the context API and lets you avoid the props-drilling problem. You basically get something like the "connect" from Redux, without the rest Redux would require. If you somehow end up with an app that fits in the 1% who need fully predictable control over their global state, go for Redux. React is the simplest framework I've ever seen, sadly Redux and co made it much more complex than needed to be, which drove many people away from it.
- lilbobbytables 9y ago
  I've used it primarily for manaing logged in user info. It's one of the few bits that is useful globally.
- williamdclt 9y ago
  What I like in redux is not redux, it's everything built on it. Redux-form, redux-saga, react-redux-router, redux-persist...
  - k__ 9y ago
    Sure thing. That's what I hear from every Redux proponent. And I guess if you put in the time and became a Redux pro, there is no reason to switch. But if you're starting out or have to work with non-pros, you're probably better served with unstated.
    - williamdclt 9y ago
      I'd have trouble seeing how I would do as good with Unstated as with Redux, but I have lot of experience with the later and zero with the former so you might very well be right!
quxbar 9y ago
Vanilla redux isn't really useful for what most people are building. We have a simple app for a few tabbed lists of items, filtering and sorting that list, and taking basic state changes on the items. The first epiphany I had was using redux-first-router to couple URL to state, with thunks to load in data based on the parameter. That takes care of pagination and filtering on the lists. Then we use middleware to write the API calls for our state changes, and as a logging layer, since all of our navigation actions are meaningful (changing sort order, bringing up a particular item, etc). It's a very simple pattern for other developers to use, I find, and the boilerplate is minimal.
cmorgan8506 9y ago
I think redux is a great pattern for state management. With that said, I think there is still room for improvement. Like most people have mentioned, it would be nice if we could some how reduce the amount of boiler plate needed, or perhaps a pattern will emerge that will help manage it better. For me, the true benefits of redux became clear when I learned how to properly normalize the shape of the data (https://redux.js.org/recipes/structuring-reducers/normalizing-state-shape#designing-a-normalized-state https://redux.js.org/recipes/structuring-reducers/normalizin...) in the store. Unfortunately to do this efficiently it requires more boilerplate and dependencies like normalizr. At this point in the evolution of SPA architecture, it definitely feels like something is wrong because of the way we manage our data across the stack. We normalize our data to our RDS, de-normalize it in our API, then re-normalize it in our application interface. Interesting and exciting to watch the evolution take place though.
- jnmandal 9y ago
  The part about normalized data being (re)transformed across the stack is so true. I don't know what the answer is but it's really funny how we are doing that. GraphQL does seem to help but I don't think it's a silver bullet
- acemarke 9y ago
  Hah, I wrote that whole "Structuring Reducers" docs section! Glad it was beneficial :) I personally am a fan of Redux-ORM [0] as a tool for handling normalized state in the store (and I show how to use it in my "Practical Redux" tutorial series [1]), but there's quite a few other options as well. My biggest frustration with the word "boilerplate" is that it not only gets thrown around a lot, it means different things to different people. Which _specific_ aspects concern you? What pain points have you experienced? [0] https://github.com/tommikaikkonen/redux-orm https://github.com/tommikaikkonen/redux-orm [1] http://blog.isquaredsoftware.com/series/practical-redux http://blog.isquaredsoftware.com/series/practical-redux
  - cmorgan8506 9y ago
    It's well written, so thanks for that. I have a client project coming down the pipe that will likely include redux, so I'll have to check out Redux-ORM. I agree that the term boilerplate has been diluted lately. I also have to admit that I use it in this instance because it seems to have become the adopted term for what essentially means "takes a lot of code no matter the complexity". So to clarify, when working with Redux, it _feels_ like it takes a lot of code to handle data in states, no matter the complexity. More likely, redux is intended for larger projects with complex state management. So yeah, there is a lot of code to setup even basic data within a state, but the benefits probably start paying dividends as the state becomes more complex. With that said, I doubt anyone working with extremely complex states is complaining about too much "boilerplate". I was considering contributing to Redux but when I checked github it didn't seem like there was too much that needed help. Let me know if that's not the case. I love the project and would enjoy contributing. Thanks again for your hard work!
winton 9y ago
After using Redux for a while, I realized that I was creating a lot of boilerplate to essentially (1) update an immutable store and (2) pass that store's state to (a)sync callbacks that execute in serial before and after the store was updated. This lead me to the creation of DotStore (https://github.com/invrs/dot-store#readme https://github.com/invrs/dot-store#readme), along with extensions to use it with React [1] and the filesystem [2]. "Dot prop" strings have proved to be an elegant solution to detect which props changed on the store. Usually this means doing a regex match in `shouldComponentUpdate`. We almost never use React's state anymore. [1]: https://github.com/invrs/dot-store/tree/master/packages/dot-store-react#readme https://github.com/invrs/dot-store/tree/master/packages/dot-... [2]: https://github.com/invrs/dot-store/tree/master/packages/dot-store-fs#readme https://github.com/invrs/dot-store/tree/master/packages/dot-...
- senoroink 9y ago
  None of your links seem to work. Is this a private repository?
  - winton 9y ago
    Heh, very new project, thanks for the heads up. Its public now.

228 points by fagnerbrack 9y ago

In 2016, we developed several very large applications using Redux. The clarity/simplicity gains quickly evaporated as the system grew in size. The experience led me to develop an alternative [1], which I have shared here before. We used it for several production components and the productivity and testability gains were very clear. [1] https://hackernoon.com/transmission-tx-a-flux-alternative-fe0630eed2a3 https://hackernoon.com/transmission-tx-a-flux-alternative-fe...

atombender 9y ago
What you describe in that blog post is essentially classical MVC, as far as I can see, except you don't use the term "controller" and all state changes are requested via events instead of being made directly on the data model. But many MVC systems work like that -- it's not like MVC is standardized. What this doesn't really get you compared to Redux is a consistent, serially updated, immutable state tree, and every state ("engine") becomes a somewhat ad-hoc event manager. Redux does get the concepts right, in my opinion. Your system doesn't really solve anything better, as far as I can see; it just calls actions "events" and splits the state tree into "engines". Redux is too simplistic, though. It does nothing to solve some of the actual hard problems people face in an MVC system, such as async loading (which comes with a bunch of can of worms: Retries, error handling, idempotency, progress events, cancellation, etc.). I don't know of anything that does this well on top of Redux. The fact that the event model and state tree are both global and shared means Redux makes it hard to encapsulate stuff, too. Encapsulation is less of any issue if there is a single instance of everything; if you have a single user controlling the page, then it makes sense that there's just one global user, and one global state for each of the user's things. But often you have multiple instances of state, and there are no tools to help you coordinate events and actions. For example, say you have a page that wants to display several charts in different boxes, and users can add new charts to the page. Every chart component "points" to which dataset it wants to render, and each dataset is a separate node in the state tree identified by ID. The actions and events then all have to refer to this dataset ID; you effectively get a little "routing layer" for actions where each action needs to look up the state by dataset ID to get the actual thing to operate on. I've not found any reusable tools to handle this. One reason Redux doesn't scale well is just the amount of boilerplate and repetition. You can solve this with some smart meta programming, especially in TypeScript. But it's not entirely a solved problem.
- pests 9y ago
  For async, do you have issues with redux-thunk? Or the generalized concept of intercepting actions with a middleware and then responding with further actions that are handled exactly as normal? For the charts example, I would just instantiate a new redux store with its own state. The reducer can be reused between chart instances. Then just dispatch other action(s) to your main redux store if you need chart state in your main store.
  - lobster_johnson 9y ago
    I don't mean promises; thunks are fine, but don't solve the hard problems. I mean actions that start asynchronous processes such as fetching data remotely via XHR. In the end, such actions tend to be extremely similar. I tend to have groups of related actions that all such actions need. LOAD_FOO_REQUEST, LOAD_FOO_SUCCESS, LOAD_FOO_FAILURE, etc. A middleware can regex-match on the action name and count how many are in flight to render load progress. Similarly, errors can be caught that way. Idempotency is a bit harder. Often a load action has several dependencies (e.g. you want to load data based on a query and a limit) that need to be encoded in something that represents that request so that if another request is issued, it can be ignored if it's identical. This ends up being boilerplate, too. Maybe one could write a generic middleware that tracked what the in-progress request is and skipped duplicate actions. Cancelation is harder. I've never done this with Redux, as the biggest blocker is that promises can't be canceled. Last I checked, WhatWG's fetch API doesn't either. Retrying, ugh. At least this one isn't too hard to make generic, since any Redux action can, in principle, be retried. In a recent project, I rendered a notification box with a retry button if an error event embedded a retry function, which in turn just resubmitted the action. But it wasn't a very general-purpose solution.
    - acemarke 9y ago
      Legitimate question: how would you expect Redux _or_ any other state management framework to solve those problems for you? Or, to phrase it another way: how do other frameworks or libraries actually tackle this problem already, in a way that Redux doesn't? My own apps have been fairly simple in that regard, so while I've seen a bunch of libraries to handle data fetching in various capacities, it's not an area I've had to deal with myself. So, I'm not sure what kind of "other framework handles it this way" comparisons exist.

coding123 9y ago

Was on a team at a large company - and the architects had a decree that everyone must use React - good decision. Except one problem was that everyone was just using Redux like it was part of React or something. I don't know how many components that had to maintain their own state got stuck in Redux nightmare land where special keys were being used to keep each component separate - it was a complicated mess inside the react component. This component didn't map to a single concept of state, instead many "copies" and different versions of that copy could be on the screen at once - and no one really "got it" that they were feeding really deep into a major anti-pattern. I kept pointing out to members of the team that even Dan Abramov's post about maybe not needing Redux... but it fell on def ears like I didn't "GET" redux. I totally understand the enticing time-travel feature, but I think too many people jumped on the ship before it was ready for the use-cases different folks had in mind.

0xCMP 9y ago
Yea seems like people reach too much for larger "state management" via Redux/Mobx/etc. too quickly without thinking what that means instead of just using State updated via callbacks passed as props. Clearly Redux solves the times where doing that isn't really clear or gets complicated, but often times it sounds from Twitter + Conversations that everything is getting thrown in to Redux for no reason.
- ojosilva 9y ago
  I resisted for a long time, but finally switched from a callback model to Mobx and the reason was that ShouldComponentUpdate and ComponentDidUpdate started becoming unbearably hard to manage. So state management libraries are not solving a unsolvable problem, they are here so that we can write cleaner, more efficient code that potentially can become more performant. At least that's what happened in my case.
  - baddox 9y ago
    Can't you use pure components as long as you make sure that all your callbacks are called with new objects, e.g. using the JavaScript spread notation? I think the bigger reason that a global state management system becomes necessary is when the shape of your component tree doesn't closely match the shape of your state tree, because that means state (and callbacks) need to be passed down through components that don't care at all about that state simply because one of their distant descendant components does care about it.

bigtunacan 9y ago

I'm not going to make any claims that Redux is dead or dying; I'm mostly oblivious to the state of React (no pun intended). I'm coming from Knockout and Angular making the switch to Vue. This line from the article got me though. "plus all of its usage with other JS frameworks like Angular, Ember, and Vue" Are people actually using Redux with Vue? Everyone I know is using Vuex for state management for Vue.

swyx 9y ago
yes i have been wondering who uses redux without react. redux tries so hard to be a react independent library, but maybe it shouldnt. ¯\_(ツ)_/¯ the maintainers do not agree.
- acemarke 9y ago
  And why shouldn't it be independent of React? While Redux and React-Redux were developed together, the Redux core is 100% pure plain vanilla JS, and the fact that bindings exist for a whole bunch of other frameworks shows that it works fine that way. Now, Dan and Andrew have suggested that in order to have React-Redux work properly with the upcoming async React rendering, we should possibly consider reimplementing the Redux store logic to use React component state as the basis. In other words, you'd probably do something like `import {createStore} from "react-redux"`. I'm not keen on that idea myself, and am hopeful we can find an approach that will allow use of a separate standard Redux store and still get the benefits of async React rendering down the road.
  - swyx 9y ago
    maybe what im really after is what react-router-dom does, which is reexport react-router. stop making me wire up the core library itself, if you have a binding it should "just work" (TM)
- tomduncalf 9y ago
  Although anecdotally the opposite (people using React without Redux) is increasing (whether they are using component state, MobX or something else), so I don’t think from that point of view (as well as others!) it would make sense for Redux to be “part of” React

ghayes 9y ago

As an avid Elm user, I am happy to see continued usage of Redux. Redux does a great job of bringing functional reactive programming to React.

swyx 9y ago
functional, yes. Reactive? no.

tootie 9y ago

The react context API is an abomination. How is tag-nesting an API?

mephitix 9y ago
How is tag-nesting not considered an API for React? The entire point of the new context API is to get around prop-drilling. Being able to do that and express the intent in JSX is what it does well IMO...
- hestefisk 9y ago
  Context to me seems like a sophisticated way of declaring global variables. Might as well do const GLOBALS = { ... } instead of another complex API that has to be loaded.
  - eropple 9y ago
    It's not, though, any more than dependency injection is "declaring global variables".
  - crooked-v 9y ago
    The new context API effectively makes variables available globally, but you're still using a separate (explicitly declared) Consumer for each, so you don't have any of the basic issues that go with using a single set of globals. For a very simple example: import { UserIdConsumer } from '@/contexts' const ThisComponent = () => ( <div> User ID: <UserIdConsumer>{value => value}</UserIdConsumer> </div> ) export default ThisComponent
    - hestefisk 9y ago
      Not sure I follow. Where does value come from?
      - tym0 9y ago

daveidol 9y ago

Personally, I find Redux to be a joy to use and write code with. I agree that there is a lot of "boilerplate" for new developers, as Redux does not really come with a batteries-included "framework" to build CRUD apps -- that's on you to figure out and write. One you do write this framework in Redux, however, you can reuse it and the amount of unnecessary boilerplate goes to near zero in my experience. We just need a de facto open source framework built on top of Redux for people who haven't worked with it extensively to build with.

acemarke 9y ago
I know. I've seen _many_ other higher-level abstractions on top of Redux (per my comment elsewhere in the thread). A year ago, I opened up an issue [0] to discuss ways we could improve the "getting started" experience, reduce boilerplate, add better abstractions on top of the base primitives, etc. The thread got some decent comments, but nothing really concrete came out of it. A few months ago I had a little bit of free time, and threw together a tiny "starter kit" library [1] that is intended to simplify a couple of the common pain points (basic store config, and writing reducers with immutable updates). I haven't had time to push it further, but long-term it's likely to become an official Redux-branded "use this to get started" addon. I'm very open to further ideas and suggestions around this topic. [0] https://github.com/reactjs/redux/issues/2295 https://github.com/reactjs/redux/issues/2295 [1] https://github.com/markerikson/redux-starter-kit https://github.com/markerikson/redux-starter-kit
- daveidol 9y ago
  Cool! I hadn't seen that. I like the idea of a solid starter kit library, although (from quickly reading the README for your starter kit) I think it should probably include more: specifically facilities for making HTTP calls, serializing/deserializing request and response data, caching data and fetch status for the requests, etc. From working with people who haven't used Redux before - these seem to be common things people new to Redux want to do but find difficult to get started. (The boilerplate around making actions and switch statements, etc. seems a bit secondary in my opinion) However, I realize the "proper" way to do the things I listed above is inherently pretty opinionated, so I totally understand why the Redux library itself has avoided including these things (it's much more flexible as-is; and probably why it's been so stable and stood the test of time).

bnchrch 9y ago

Redux is far from dead but I do think apollo-link-state has the ability to take its crown if GraphQL continues to gain wide adoption; which I believe it will. Though it's a very new library (Dec 2017) so it has a long way to catch up in terms of tooling and support. I just happened to write an article on apollo-link-state for those who are curious about how it's used. https://hackernoon.com/setting-up-apollo-link-state-for-multiple-stores-4cf54fdb1e00 https://hackernoon.com/setting-up-apollo-link-state-for-mult...

colept 9y ago
Love Apollo - they're a great team with many of great open source offerings. Apollo link state excites me because it unites remote and local data under a single source of truth. As a long time Redux fan, it will be nice to have one less layer and dependency to debug. GraphQL as a uniform layer for accessing that source of truth is in my mind, a Redux-killer.
acemarke 9y ago
So I haven't actually used GraphQL at all, although I've sat through a bunch of talks on it and am pretty familiar with the concepts. That said, I have to say that the examples I'm seeing for setting up link-state mutations don't look like they're particularly concise. Given that "boilerplate" is a typical complaint about Redux (which can itself be handled with whatever abstractions you want to put in place), I'm not seeing the appeal here. Is it just a case of "we're already using GraphQL, so GraphQL all the things" ? (Note that the article itself doesn't use the word "boilerplate", I'm just pointing at that as a reason I've seen people throw out for wanting to move to link-state.)
- city41 9y ago
  apollo-link-state would almost certainly be considered a hack if it was made by anyone else other than the Apollo team. Just the fact you need to manually specify the __typename field feels wrong to me. But I do have hopes that Apollo will grow and improve here, and apollo-link-state will likely evolve into an elegant tool.

mephitix 9y ago

I started using Redux with container components and dumb presentational components - this worked and scaled well. Eventually though some containers started to have their own state, derived from props. Ultimately I was left with the feeling that I wasnt really getting the full benefits of redux (time traveling, centralized middleware, etc) without moving all state in my app to Redux. I think this is how teams get trapped by Redux - the pursuit of having nice dev accordances like time traveling leads them to adopt Redux everywhere and just by Redux’s nature (immutability, declarative actions) it ends up complicating things way too much. I think the article I’m most grateful for is Dan’s article on container vs presentational components. Sticking to that philosophy let me adopt Redux and try it out but still have the majority of my app in dumb, non-Redux presentational components. So now it’s easier to remove Redux if I need to.

acemarke 9y ago
We do try to emphasize that it's completely up to you how much or how little state you actually put into Redux: https://redux.js.org/faq/organizing-state#do-i-have-to-put-all-my-state-into-redux-should-i-ever-use-reacts-setstate https://redux.js.org/faq/organizing-state#do-i-have-to-put-a... . I've certainly talked to people who literally put every single value in their app into Redux (often in conjunction with _only_ using functional components). I can understand why they might choose that approach, but to me that's over-opinionated. Most of my app-type data does go into Redux, but it's absolutely fine to use React local component state for whatever doesn't need to be shared.
- FundThrowaway 9y ago
  That's one of my favourite parts of Redux is how flexible it is, use a little bit here and there where it's appropriate. The current project I'm working uses Redux to manage all of the websocket communication but that's it.
fastball 9y ago
I think you should generally start by putting everything into Component state, and only move stuff to the store if you find yourself needing to do a lot of prop-drilling. Time travel is nice, but it is not worth putting everything into your Redux store.

sailfast 9y ago

Great post and good clarifications about the future of Redux - thanks! Happy user of Redux in both a React app and an Angular app. Makes managing state in Angular (not to mention testing where ordinarily multiple controllers might be involved) so much cleaner. Thank you for your hard work, maintainers!

acemarke 9y ago

Oh hey, that's my post. So, uh... Redux co-maintainer and author of that post here. Happy to answer questions and point people at possible solutions :)

pimlottc 9y ago
Any comments on the relationship between redux and rematch?
- acemarke 9y ago
  Not sure what there is to comment about relationship-wise. From what I've seen, Rematch appears to be a higher-level abstraction library built around Redux. I've seen a lot of those (most of which I've linked in the "variations" page of my Redux addons catalog: https://github.com/markerikson/redux-ecosystem-links/blob/master/variations.md https://github.com/markerikson/redux-ecosystem-links/blob/ma... ). I haven't had time to try it myself, but it looks conceptually interesting.
daveidol 9y ago
Thanks for doing what you do. I contributed some of the initial documentation [1] for testing middleware back in the day. Wondering if there are any areas in particular you'd be looking for contributions? I use redux every day and would like to contribute back some (if it would be helpful). [1] https://github.com/reactjs/redux/pull/559 https://github.com/reactjs/redux/pull/559
- acemarke 9y ago
  Yes, absolutely! I have a _ton_ of additional docs improvements I'd like to see. Most of those are currently listed as open issues with a "docs" tag [0], and I've got some other docs ideas floating around in my head besides those (like completely revamping our docs around React-Redux). Beyond that... oh, boy. I'd love help maintaining my React/Redux links list [1]. I've been really busy the last few months and have fallen behind on adding new links, and it could also use some maintenance attention to look at the existing links and figure out which ones are outdated and not really useful any more. The "starter kit" lib I threw together [2] could use more design work and ideas to figure out what other "batteries included" type things we would want to include out of the box as an official Redux-branded library to solve some of people's common pain points. React-Redux has some open PRs related to React 16.3 [3]. It's starting to look like we need to put together a bigger v6.0 major version release with some combined changes, and it would be good to get more eyes on the situation to figure out what's needed. There's also an open PR for adding an "object shorthand" for selectors with `mapState` that's been lying around for a while waiting for someone to add some tests so that we can say we're happy with how it works and merge it. [0] https://github.com/reactjs/redux/issues?q=is%3Aissue+is%3Aopen+label%3Adocs+sort%3Aupdated-desc https://github.com/reactjs/redux/issues?q=is%3Aissue+is%3Aop... [1] https://github.com/markerikson/react-redux-links https://github.com/markerikson/react-redux-links [2] https://github.com/markerikson/redux-starter-kit https://github.com/markerikson/redux-starter-kit [3] https://github.com/reactjs/react-redux/pulls?q=is%3Apr+is%3Aopen+sort%3Aupdated-desc https://github.com/reactjs/react-redux/pulls?q=is%3Apr+is%3A...

iandanforth 9y ago

I've had a mixed history with Redux. It always felt like a ton of overhead to maintain on top of React. However I recently started using Rekit (http://rekit.js.org/ http://rekit.js.org/) which is a web-based IDE specifically for React+Redux and I'm loving it. All the patterns the IDE defaults to (and in some cases enforces/automates) are ones that I had to learn painfully (and repeatedly) in other contexts. Now when I need a new action I get the paired reducer, top level reducer tie-in, tests, all for free. It's great! Try it out on your next project!

ralusek 9y ago

I've been using mobx-state-tree for the latest couple of projects after Redux. I like them both, but I prefer mobx-state-tree for a handful of reasons. 1.) There is an immutable data store with action-driven changelog, just like Redux. 2.) The immutability of the data store is baked in and enforced. The necessity to provide changes to the data store within an action is baked in and enforced. 3.) Having actions baked in as methods rather than having to create "action creators which in turn dispatch actions" is a nice reduction in boilerplate. 4.) Being able to add action listeners AND state listeners are baked in, and can be done at any level of the state's depth. To watch state changes in redux, for global changes not related to a particular component, I had to write: https://github.com/ralusek/redux-store-watch https://github.com/ralusek/redux-store-watch 5.) Mobx's observers on react render methods makes the renders far more efficient than what could be achieved with react-redux easily, without really ensuring that the props being passed in are as granular as necessary or shouldComponentUpdate is correctly identifying state changes. In mobx, the most granular access of the lowest level state can be detected within a render method, and only when that very specific value is replaced is the component rendered. 6.) Computed values on mobx-state-tree are baked in without the need for something like reselect I like Redux, I enjoy working on projects that use it, but I think that I think I'd have to admit that I prefer mobx-state-tree.

johnwheeler 9y ago
React ecosystem noob here. To point #5, I remember reading that MST has some overhead over Mobx, does it come into play with these renders?
- tomduncalf 9y ago
  I investigated MST for a React Native project and found the the additional overhead it created for frequent state updates was too much - in a synthetic test updating state every frame, it resulted in a 30-40% increase in CPU usage on a real device vs. plain MobX which for our application probably isn’t acceptable. If you know you won’t be making really frequent state updates or CPU constraints are less important it seems like a great option!
- 9y ago

twfarland 9y ago

Redux has been great, but after a few years, I've had enough of the action creator and reducer boilerplate, and now just use Proxy objects for external state (with a listener on the handler's setter). It's mutable but hasn't been a problem in practice.

elliotlarson 9y ago

I've built a couple of applications with React. I've spent the last 6 weeks on a contract where I'm building a React based Google maps widget. I'm getting to the point where I'd like to break up a large "smart" component into smaller, more maintainable smart components. So, I'm looking for a state management library to help. I've walked through some training courses at Udemy on Redux and I've built a small personal project with it. I don't want to beat a dead horse, but the boilerplate is really off putting. I feel like I'm being exposed to the internals of a framework that's missing some higher level API abstraction that makes state management less onerous. I think the Rematch library presents a nicer surface API: https://github.com/rematch/rematch https://github.com/rematch/rematch. But, I'm hesitant to use it over Redux for client work because I want to make sure I develop something that's easy to hand off, and Redux is sort of king right now. I just spent some time with the apollo-link-state docs. I know it's young, but this does not look like an improvement over the Redux state management API. Hopefully if this is to be the Redux successor, the API will improve with maturity. I kind of wish Ember Data was usable as a standalone library. It looks like such a nice, easy to use wrapper around state and data management.

spicyj 9y ago
Curious what things make you reach for a state management library vs staying with React’s built-in state when splitting up components.
- elliotlarson 9y ago
  My main smart component is several hundred lines long at this point. The methods in the component are largely event handlers used to manipulate the component's state object. The methods are passed down into the hierarchy of "dumb" components via props, and are called when actions occur in those components (e.g. onClick some element). The methods are conceptually group-able into 4 distinct areas of data manipulation. However, the catch is that many of the event handler methods need to modify other pieces of the state object too. So, for example, I have a number of methods related to polygon state management. I'd like to move these into a <Polygons /> smart component, but when updating a polygon, I also, in some cases, need to update data for another potentially extractable smart component <Toolbar />. A state management library would allow me to move/group data management logic into smart components that would also still have access to other parts of the state tree.

sktrdie 9y ago

One major problem we had with Redux, especially in a large organization where reusability is very important, is that we found it hard to reuse most of the redux logic (reducers/thunks/selectors). The pure components were easily shared across different teams, but most of the other stuff was too much redux or app-specific that we couldn't really reuse it. We experimented with simply using large stateful react components instead of redux for certain areas of the app, and our reusability improved dramatically. Any thoughts on how this is tackled by some hardcore redux users?

ff_ 9y ago
It is a general problem (that is, not only Redux has it, but basically any React-based thing), and the pattern that works best for reusability (in my esperience) is the "pure component sandwich": you have a pure component which takes a bunch of functions as parameters (and is reusable, no framework-specific stuff) and wrap it in the app-specific component which implements these functions for the current app.
- daveidol 9y ago
  Definitely agree, but I think the parent commenter was asking how to reuse redux-specific code, such as reducers, actions, etc.
daveidol 9y ago
Reducer, middleware, and "action creator" factories that take config will allow for a pretty high level of reusability. We have several internal redux libraries of generic reducers, middleware, etc. and they all export factories that return these things instead of naked reducers, middleware, etc. The factories can take config for which action types to handle, etc.
- bshimmin 9y ago
  This is great progress; given a little more time, I hope we will be able to recreate the fabled AbstractSingletonProxyFactoryBean!

chvid 9y ago

To be honest I always thought Redux to be hard-to-understand, obscure in its terminology and terrible over-hyped essentially doing something that could be much better described/modelled as a straight out application of the command design pattern.

cooervo 9y ago
Yes, the documentation loves to use complicated concepts and is very hard to understand. also its a ton of boilerplate code. I think redux just became hyped because of its "time travel debugging" which is just pure functions returning some stored values.
- citrons 9y ago
  I also had a bit trouble learning redux (adopted quite early), but now there is video series by Dan Abramv that goes trough entire redux features is is easy to understand. But the conectps in redux IMO are worth learning, made me think about my own code different. More pure functions, less sideeffects...

Yaggo 9y ago

I hadn't considered Redux dead, but after that title from "them", I am now.

rejschaap 9y ago
Or at least that it is dying, since it is "Not Dead Yet"

songzme 9y ago

For those who don't know redux, here's a quick 5 min video from vimgirl. Personally, I like her short, straight to the point approach. https://youtu.be/SV_reBvGKPE https://youtu.be/SV_reBvGKPE It shows you redux as it is using plain javascript, without involving react, which gave me a clear idea of what redux actually is.

mcintyre1994 9y ago
The plain JS example is nice too: https://github.com/reactjs/redux/blob/master/examples/counter-vanilla/index.html https://github.com/reactjs/redux/blob/master/examples/counte...

baronseng 9y ago

Did anyone use dvajs https://github.com/dvajs/dva https://github.com/dvajs/dva and any comments?

jopsen 9y ago

This is why projects/libraries/services should list the pros/cons of using them. So people know when something is a fit, and that it's not always a fit. This pattern of some _thing_ becomes popular; everybody says to use _thing_; people use _thing_ where it's a bad fit; tsunami of people says _thing_ is broken. _thing_ keeps living. Examples: redux, react, S3, EC2, AWS lambda, heroku, docker, angular, ruby-on-rail, rust, golang, well every _thing_ :)

k__ 9y ago

Redux and MobX are overkill. What most people want is an easy way to pass down state to nested components, but the context API is a bit verbose and otherwise you end up with the props-drilling problem, passing and passing and passing. Problem is, Redux and MobX solve far more than this problem and in the end you are stuck with all the complexity they add, even if you don't need the other benefits they bring. In 80% of all apps you don't need much state. They don't have deeply nested components so you can simply store the state in your root components (Screen/Page) via setState and pass everything down via props. If you end up with deeply nested probs, use "unstated", it adds a bit better usability to the context API and lets you avoid the props-drilling problem. You basically get something like the "connect" from Redux, without the rest Redux would require. If you somehow end up with an app that fits in the 1% who need fully predictable control over their global state, go for Redux. React is the simplest framework I've ever seen, sadly Redux and co made it much more complex than needed to be, which drove many people away from it.

lilbobbytables 9y ago
I've used it primarily for manaing logged in user info. It's one of the few bits that is useful globally.
williamdclt 9y ago
What I like in redux is not redux, it's everything built on it. Redux-form, redux-saga, react-redux-router, redux-persist...
- k__ 9y ago
  Sure thing. That's what I hear from every Redux proponent. And I guess if you put in the time and became a Redux pro, there is no reason to switch. But if you're starting out or have to work with non-pros, you're probably better served with unstated.
  - williamdclt 9y ago
    I'd have trouble seeing how I would do as good with Unstated as with Redux, but I have lot of experience with the later and zero with the former so you might very well be right!

quxbar 9y ago

Vanilla redux isn't really useful for what most people are building. We have a simple app for a few tabbed lists of items, filtering and sorting that list, and taking basic state changes on the items. The first epiphany I had was using redux-first-router to couple URL to state, with thunks to load in data based on the parameter. That takes care of pagination and filtering on the lists. Then we use middleware to write the API calls for our state changes, and as a logging layer, since all of our navigation actions are meaningful (changing sort order, bringing up a particular item, etc). It's a very simple pattern for other developers to use, I find, and the boilerplate is minimal.

cmorgan8506 9y ago

I think redux is a great pattern for state management. With that said, I think there is still room for improvement. Like most people have mentioned, it would be nice if we could some how reduce the amount of boiler plate needed, or perhaps a pattern will emerge that will help manage it better. For me, the true benefits of redux became clear when I learned how to properly normalize the shape of the data (https://redux.js.org/recipes/structuring-reducers/normalizing-state-shape#designing-a-normalized-state https://redux.js.org/recipes/structuring-reducers/normalizin...) in the store. Unfortunately to do this efficiently it requires more boilerplate and dependencies like normalizr. At this point in the evolution of SPA architecture, it definitely feels like something is wrong because of the way we manage our data across the stack. We normalize our data to our RDS, de-normalize it in our API, then re-normalize it in our application interface. Interesting and exciting to watch the evolution take place though.

jnmandal 9y ago
The part about normalized data being (re)transformed across the stack is so true. I don't know what the answer is but it's really funny how we are doing that. GraphQL does seem to help but I don't think it's a silver bullet
acemarke 9y ago
Hah, I wrote that whole "Structuring Reducers" docs section! Glad it was beneficial :) I personally am a fan of Redux-ORM [0] as a tool for handling normalized state in the store (and I show how to use it in my "Practical Redux" tutorial series [1]), but there's quite a few other options as well. My biggest frustration with the word "boilerplate" is that it not only gets thrown around a lot, it means different things to different people. Which _specific_ aspects concern you? What pain points have you experienced? [0] https://github.com/tommikaikkonen/redux-orm https://github.com/tommikaikkonen/redux-orm [1] http://blog.isquaredsoftware.com/series/practical-redux http://blog.isquaredsoftware.com/series/practical-redux
- cmorgan8506 9y ago
  It's well written, so thanks for that. I have a client project coming down the pipe that will likely include redux, so I'll have to check out Redux-ORM. I agree that the term boilerplate has been diluted lately. I also have to admit that I use it in this instance because it seems to have become the adopted term for what essentially means "takes a lot of code no matter the complexity". So to clarify, when working with Redux, it _feels_ like it takes a lot of code to handle data in states, no matter the complexity. More likely, redux is intended for larger projects with complex state management. So yeah, there is a lot of code to setup even basic data within a state, but the benefits probably start paying dividends as the state becomes more complex. With that said, I doubt anyone working with extremely complex states is complaining about too much "boilerplate". I was considering contributing to Redux but when I checked github it didn't seem like there was too much that needed help. Let me know if that's not the case. I love the project and would enjoy contributing. Thanks again for your hard work!

winton 9y ago

After using Redux for a while, I realized that I was creating a lot of boilerplate to essentially (1) update an immutable store and (2) pass that store's state to (a)sync callbacks that execute in serial before and after the store was updated. This lead me to the creation of DotStore (https://github.com/invrs/dot-store#readme https://github.com/invrs/dot-store#readme), along with extensions to use it with React [1] and the filesystem [2]. "Dot prop" strings have proved to be an elegant solution to detect which props changed on the store. Usually this means doing a regex match in `shouldComponentUpdate`. We almost never use React's state anymore. [1]: https://github.com/invrs/dot-store/tree/master/packages/dot-store-react#readme https://github.com/invrs/dot-store/tree/master/packages/dot-... [2]: https://github.com/invrs/dot-store/tree/master/packages/dot-store-fs#readme https://github.com/invrs/dot-store/tree/master/packages/dot-...

senoroink 9y ago
None of your links seem to work. Is this a private repository?
- winton 9y ago
  Heh, very new project, thanks for the heads up. Its public now.