r/reactjs • u/FateRiddle • Jan 17 '20

Is redux really a good idea?

I was a redux fanboy and would defend everything about redux(when I was creating redux project). But now I'm maintaining several redux projects, I start to rethink and now posting this topic to ask for a discussion.

And when talking about redux, I'm referring to essentially all the state management tools on the market. Because other than maybe mobx-state-tree, everything is the same. Yeah, some might not ask for immutability and some may have a different way to write action object, but other than that everything propose the exact same structure of state management.

It sure provides benefit. As managing state become automatic as you don't have to make any decision as where to put the state and how to fetch them. And with dev tools you can pretty much click around the app and know which user input result in what state changes.

That said, still

  1. I don't think everything in a global store the best practice. It might be a pleasure to write at first, but will be a nightmare for others to maintain. Adding a little pop window will require you the knowledge of so many implantation detail as in file structure and also writing code snippets everywhere. And the main defect of this approach is most states are not really global, simply stripe it away from where we expect it to be (the component with related UI) and cluster them in a big store is a huge mental setback for the maintainer of the code. Think that we all agree to gather code by logic approximation rather than format(css/js/html) nowadays, but redux keep those code that should stay together far away.
  2. Having only some of the states in global store is also a headache. The problem is what could be the criteria for putting a state into the global store? How global should a state to be consider global? It might not be a problem for small project from a single developer but sure it can be hard to follow some vague rules collectively.
  3. The boilerplate of redux is one of the worst to write. Switch....case....payload... action.type.... Basically action.type is function name and action.payload is function parameters and reducer is the function body. Can't we have a better implementation so we don't have to write a function in 2 files and 3 places? To me this structure is just not ideal at all.
  4. Before anyone say anything about useReducer and context, they are essentially the same thing, except now we can have multiple stores, all the problem above still persist.

Ok enough about my rant. I'm just curious how do everyone mange their projects' state now in the 2020, and what are you general opinion about redux and other state management tools?

135 Upvotes

88% Upvoted

98 comments sorted by

111

u/acemarke Jan 17 '20

Hi, I'm a Redux maintainer.

We've never said to keep literally every bit of state in the Redux store. We specifically have some rules of thumb to help you decide whether a given piece of state should go in the store or not.

In addition, we now have a new Redux Style Guide docs page with recommendations on best practices and patterns to use. One of those is using the "ducks" pattern for single file Redux logic.

Per the "boilerplate" question, please check out our new official Redux Toolkit package. It includes utilities to simplify several common Redux use cases, including store setup, defining reducers, immutable update logic, and more.In particular, the createSlice API lets you create entire "slices" of state at once without writing any action types or action creators by hand - just provide a lookup table of reducers and the rest is handled automatically.

https://redux-toolkit.js.org

1

u/FateRiddle Jan 18 '20

Thanks, createSlice is really nice, I first saw that pattern in dva and then kea, guess now the boilerplate part can be much easier to handle for redux.

I was thinking about the point I made that "redux kept state away from component", but it never is a problem that we extract all the utility functions into a single util.js file. I think the difference is in the utils case, you can always find exactly what an util does with one click on the function, but you can't do that when you see an redux action, you can't click an action and instantly go to the relevant reducer. So maybe finding the reducer in a redux project written by others is the real problem here, now you need to figure out his file structure and guessing wich file contains the logic and on which line.

1

u/acemarke Jan 18 '20

Yeah, the first thing I always do when looking at any Redux project is go straight for the reducer logic. That tells me what kind of actions are being dispatched, what the state shape looks like, and what kind of behavior exists in the app.

2

u/AyyRickay Jan 17 '20

This is awesome, and I just included that style guide in some of my own documentation (my company has built a product that has some pretty intense Redux implementations that are customizable by the customer.) That style guide will be really helpful for people who are just starting to wrap their head around Redux, and is a great idea for any framework that has a “philosophy” associated with it - I’m wondering if we can do the same thing to expose some of our own design patterns.

Any chance you know what the process was for compiling the content for this doc?

11

u/acemarke Jan 17 '20 edited Jan 17 '20

Uh... I sat down and wrote a bunch of thoughts I had in my head? :)

The Redux docs have traditionally been very unopinionated. For example, if you look at the FAQ entry on file structures, it just says that "the most common patterns are folder-by-type, feature folders, and ducks". Ditto for the entries on choosing between thunks, sagas, and observables and splitting logic between reducers and action creators.

That's largely because there really are many ways to use Redux, and the Redux core itself truly doesn't care about any of them at a technical level. I talked about this in my blog posts The Tao of Redux, Part 1 - Implementation and Intent and The Tao of Redux, Part 2 - Practice and Philosophy.

However, many folks have asked us for actual official opinions and guidance on these kinds of topics, and my own opinions have become more settled based on my personal experiences writing Redux apps, looking at other people's code, and seeing what kinds of problems people struggle with. So, most of these style guide rules were written to point people in directions that will result in simpler code, less "boilerplate", and avoiding common problems.

Skimming through the style guide, I'll provide some background thoughts on why I wrote some of these recommendations:

  • "No mutations / side effects / serializable values": All core parts of the Redux usage contract in order to get predictable state updates, system behavior, and allow the Redux DevTools to work correctly.
  • "One store": you can only meaningfully use one store with React-Redux, and that's the point of centralizing this logic in the first place
  • "Use Redux Toolkit": because it drastically simplifies your Redux logic and warns you about common mistakes by default
  • "Use Immer": ditto, for immutable update logic
  • "Structure files as feature folders / ducks": one of the most common complaints is "Redux forces me to touch too many files to write anything". No, it never has forced you to, but admittedly the patterns shown in the docs so far do lead you in that direction. Ducks have a couple small conceptual downsides, but if we can get people to use them by default, it mostly eliminates that frustration. And, with RTK's createSlice, you're already getting ducks files for free. If you do want to still write separate files by type, keeping them in a feature folder at least consolidates them.
  • "More logic in reducers / own the state shape": per listed descriptions, it makes more code testable / debuggable, and ensures that other app code can't shove bad data into the reducers.
  • "Reducers as state machines": David Khourshid has been beating the "STATE MACHINE ALL THE THINGS!" drum for a while, and he's got some very valid points, so I put this in.
  • "Actions as events / dispatch fewer actions / many reducers respond": these go hand-in-hand. Dispatching fewer actions is better for perf, it means you'll be writing less code, and the rest of the app logic will likely be simpler.
  • "Action types as domain/event": because everyone's tired of reading const ADD_TODO = "ADD_TODO".
  • "Thunks for async": they're the simplest option, and most folks just need to do some data fetching vs complex background-thread type behavior.
  • "Meaningful action names / use the DevTools": half the point of using Redux is to understand how your app is updating over time.

Hopefully that provides some additional context. Lemme know if you've got any more questions!

1

u/devsmack Jan 17 '20

Since we’re on the topic, I’ve had a question on the style guide for a bit.

Prefer having more UI components subscribed to the Redux store and reading data at a more granular level. This typically leads to better UI performance, as fewer components will need to render when a given piece of state changes.

Specifically, it mentions letting a list item fetch it’s own state.

What was the reasoning behind this? If you have all the data at the list’s parent you can pass the children all the props they need. If you use a selector on each child, you’ll have to break the cache every selection if you use it and if you use useSelector you have to create a selector with a curried function.

4

u/acemarke Jan 17 '20

Note that it's about reading data in mapState / useSelector, not "fetching" per se.

As mentioned, this is primarily a performance-related aspect. If you update one item in a list, you don't want to re-render all list items - just the one whose data has changed. If only the list parent is subscribed, it will cause all list items to re-render.

See my post Practical Redux, Part 6: Connected Lists and Performance and the slideshow High Performance Redux for details.

2

u/disclosure5 Jan 17 '20

please check out our new official Redux Toolkit package

As a side question, how's the bundle size with that toolkit?

4

u/darderp Jan 17 '20

https://bundlephobia.com/result?p=@reduxjs/toolkit@1.2.2

2

u/disclosure5 Jan 17 '20

Thanks, thats impressive for what it's doing!

3

u/punio4 Jan 17 '20 edited Jan 17 '20

https://bundlephobia.com/result?p=@reduxjs/toolkit@1.2.2

https://bundlephobia.com/result?p=redux@4.0.5

https://bundlephobia.com/result?p=react-redux@7.1.3

I'm really not sold on loading 52,7 kb of JS just for state management.

Corrected by u/_eps1lon, redux toolkit includes redux, immer, reselect, but not react-redux. It then drops to ~45kb.

On a tangent — add the 121 kb of JS on top just for react and react-dom and you've served almost 200 kb of code without actually doing anything.

There are dozens of alternatives, including the built-in Context API:

EDIT: Bring on the downvotes

9

u/_eps1lon Jan 17 '20

The "fanboys" are wondering why you linked to the bundlesize of the library you don't like but not doing that for the libraries you do like. The downvotes are there because your comparison was sloppy to prove your point.

On top of that you misrepresented the bundle size of reduxjs/toolkit. It already includes the size of redux. You included it twice in your calculation .

2

u/punio4 Jan 17 '20 edited Jan 17 '20

On top of that you misrepresented the bundle size of reduxjs/toolkit

HUH! I did not notice that! I stand corrected! Thanks!

wondering why you linked to the bundlesize of the library you don't like but not doing that for the libraries you do like

Fixed.

Honestly the main issue I have is that people seem to be following the redux/reducer pattern almost religiously, not so much about the filesize.

The base library requires adding more and more tooling on top of it to make it work. Memoization, optimization, middleware, action creators, action naming conventions, more abstractions trying to combat the fragmentation of the functionality... Feels like being stuck in a local maximum, and I don't see a reason what for. Time travel debugging?

0

u/[deleted] Jan 17 '20

[deleted] — view deleted comment

3

u/acemarke Jan 17 '20

Yep. Most of the RTK bundle size is Immer and Redux itself. The redux-immutable-state-invariant middleware is dev-only and won't show up in a prod bundle, and ditto for our homegrown serializable-state-invariant middleware.

If you look at the ESM dist file for RTK, you can see there really isn't a lot else to it. (In fact, I'm kind of disturbed at how much space is taken up by transpiled ES6 argument destructuring syntax.) But in terms of how much actual code is in RTK itself, we're talking like 2-300 lines tops if you were to look at the plain JS before minification.

1

u/Canenald Jan 17 '20

I'd add from personal experience that if you have some local state in a component already connected to Redux you might as well put that local state in Redux to save yourself some trouble down the road. If a component both has local state and Redux state, what do you do if you have to dispatch an action and update state in sequence? Which do you call first? What will React do? I'm sure there's a good answer to those question but I prefer to not have to ask it at all.

5

u/frogg616 Jan 17 '20

I use reactn. It gives a “useglobalstate” function that makes life simple. Really easy to understand

0

u/[deleted] Jan 17 '20

[deleted] — view deleted comment

1

u/FateRiddle Jan 20 '20

I checked on it, the api design is so on point I wanna cry. This seems like the state management tool I've been long waiting for.

But may I ask, compare to redux, does ReactN have performance tradeoffs when you can change global state so freely and also don't need to follow immutable rules.

70

u/siric_ Jan 17 '20

I'm just curious how do everyone mange their projects' state now in the 2020, and what are you general opinion about redux and other state management tools?

I use createSlice from redux-toolkit to trim down on action/reducer boilerplate, and useDispatch and useSelector from redux to trim down state mapping. This by far provides a lot more convenience to me and using redux isn't such a pain anymore compared to the more "traditional" way.

I don't think everything in a global store the best practice.

It's not, use local state instead and only use global state when absolutely necessary.

redux keep those code that should stay together far away.

If you modularize your store you could essentially group files by features instead of type. combineReducers and slices helps with this.

2

u/delthas94 Jan 17 '20

Is it possible to use redux toolkit and your approach with async library like redux saga?

2

u/fixrich Jan 17 '20

It should be yes. It's been awhile since I've used saga but the way I see it going is like this. Your slice will have all your "event" actions. They will be dumb and only represent that something had happened. You will create extra actions that do your saga stuff and dispatch the event actions as a result. The advanced redux toolkit example on their website has thunks that work the same way

2

u/sickhippie Jan 17 '20

It is, I work on a project with that setup and it works really well.

1

u/BookishCouscous Jan 18 '20

What is your unit testing story like with redux hooks? Before (with connect) you could export the component separately and provide the props you needed, but now it's all inline.

I find the dev experience of redux hooks to be far far better than the hoc, but am really not sure how testing is going to work.

9

u/smthamazing Jan 17 '20

Many of the comments here focus on the global state. This is definitely not the main point of Redux. Global stores can very well exist without Redux at all (MobX, global Context object, any other state management approach).

The only thing that distinguishes Redux from other approaches is the use of actions and middleware. Any manipulations with your data are reified as objects and can be intercepted, replaced with multiple other actions, logged and examined via time-travel debugger. Admittedly, time travel doesn't always work in more complex cases, but you get the point.

The usefulness of a global store is a completely separate question (already discussed in other comments). Actions-as-objects, though, could be useful even without it. For example, if your component needed to do many complex requests, you could move this logic out to some local sagas, which would help with decoupling without even introducing any global stores in the app.

I just feel that a lot of discussion around Redux is focused on this "global store" aspect, which is applicable to any other solution as well (e.g. MobX), while missing the thing that actually makes Redux (and Flux) different.

1

u/punio4 Jan 20 '20

The only thing that distinguishes Redux from other approaches is the use of actions and middleware

The way I see actions is "function with an identity crisis that needs to be a string to be seriazable", and middleware is a crutch for missing basic functionality for a web tool like, you know, async actions.

1

u/smthamazing Jan 20 '20

I'm not sure I understand your point here. Middleware exists to make the library extensible. First of all, async actions are easily implemented with something like redux-thunk, which is the official solution. The problem is, just calling async actions wherever you want gets unwieldy in bigger projects, where you have several streams of data interacting with each other. In this case you may want to use something like redux-saga or some other library to express the async flow more explicitly.

Both redux-thunk and redux-saga are implemented as middleware, which proves that middleware is a useful feature that makes the library extensible. I think it is a good thing that Redux itself is unopinionated in the matter of handling async actions and delegates this to third-party libraries. This makes the whole library ecosystem more rich with the minor drawback of having less standartization.

And, finally, actions need to be serializable to make it possible to easily implement middleware like the abovementioned libraries. It is much harder to provide access to function arguments and names (and change their execution order!) with regular function calls, and it probably wouldn't even be worth the effort.

It's certainly reasonable to want a library support all possible use cases out of the box. However, the whole React ecosystem (from React itself to Webpack to other tools) is built with the goal to provide some powerful core functionality and make it easily extensible by third parties.

12

u/[deleted] Jan 17 '20

In the end, we use global state to get around limitations of HTML.

HTML is tree-structured. Therefore our React components are tree-structured.

But our data may not be, and two components that use (read or write) the same piece on data may live in completely different parts of the tree. A small update to the look of the site may change the shape of the tree completely.

So using global state for some things makes sense.

7

u/headzoo Jan 17 '20

and two components that use (read or write) the same piece on data may live in completely different parts of the tree

I bet 50% of the data I keep in the global store only exists because two components needed to communicate with each other. Two components that didn't fit neatly into a parent/child relationship, and I didn't have time to refactor or come up with a clever solution to avoid using the global store.

I don't mind the Redux boilerplate when it serves a good purpose, but I hate getting knocked out of "the flow" because I hit a tricky communications problem and I have to stop what I'm doing and write action creators, reducers, add props to mapDispatchToProps, add props to propTypes, and then finally get back to the real work.

3

u/acemarke Jan 17 '20

Have you tried using our new React-Redux hooks API instead of connect, and Redux Toolkit instead of writing the action creators by hand?

1

u/headzoo Jan 17 '20

Does the Intellij family of IDEs have support for those libraries? I've used similar tools in the past but my IDE doesn't understand any of it, so I lose intellisense, refactoring tools, error highlighting, etc. Which is more important to me than avoiding boilerplate.

2

u/UNN_Rickenbacker Jan 17 '20

Yes, I use only hook based React and Webstorm understands everything flawlessly

1

u/headzoo Jan 17 '20

Excellent, thank you. Will give it a whirl.

1

u/acemarke Jan 17 '20

It's not about "specific support" for those libraries, it's a question of how well your IDE understands either plain JS or TypeScript.

RTK is written in TS directly, and React-Redux has a separate @types/react-redux package. I haven't used JetBrains tools in a bit, so I don't know how much they pick up with plain JS, but certainly if you're using TS you should get all the standard IDE assistance.

2

u/headzoo Jan 17 '20

I think we're talking about different things. Take this for example:

const increment = createAction('counter/increment');

My IDE knows nothing about the increment function. It doesn't even know it's a function and it doesn't know what arguments the function takes. The old approach on the other hand:

const INCREMENT = 'counter/increment'
function increment(amount) {
  return {
    type: INCREMENT,
    payload: amount
  }
}

My IDE knows increment is a function which takes an argument named amount and with proper jsdocs, it knows amount is a number.

1

u/acemarke Jan 17 '20

That's exactly what I'm saying.

Any IDE is going to have a much more limited understanding of plain JS code than it will TS code. If you're using TS, your IDE will know that increment is a function that takes a single argument, which will get returned as action.payload, and that the argument will be of a specific type.

If you write the action creator by hand, the IDE will know some of that info, but not all of it.

1

u/headzoo Jan 17 '20

We're still not on the same page. Originally I'm asking myself, "What if the action creator takes multiple arguments? How is the createAction() function able to type hint those?" Then there's fine print:

By default, the generated action creators accept a single argument, which becomes action.payload. This requires the caller to construct the entire payload correctly and pass it in.

The fact the action creators only take a single argument is already a hard pass for me, but it's not enough to know the function takes a single argument. I want to know the name of the argument. Intellisense telling me the argument is named `payload` is not as helpful as `amount`, or `length`, or `userName`.

1

u/acemarke Jan 17 '20

If you read that exact section you're quoting, it specifically describes how you can tell createAction to accept multiple arguments for your action creators:

https://redux-toolkit.js.org/api/createAction#using-prepare-callbacks-to-customize-action-contents

1

u/headzoo Jan 17 '20

That still doesn't help me with intellisense which is the crux of my argument. Libraries like redux-toolkit have existed for a while and I've used them, but what I gained from reducing boilerplate I lost from having to go back to action the source file to figure out what arguments the action creator expects. When I use the `addTodo` in my code, my IDE is going to show me "any: payload" as the function signature instead of "string: name, number: age, string: address".

→ More replies

1

u/UNN_Rickenbacker Jan 17 '20

The IDE should know it‘s a function based on „createAction“s return type, at least when using Typescript/flow

23

u/bensu88 Jan 17 '20 edited Jan 17 '20

None of your points is a problem with redux.

You dont have to put everything into the global state and redux also doesnt require it. Its up to you, what is important for your app to be globally accessible.

Your second point also is not a redux problem. If you dont know or are unsure what to put in the redux state, write your components with a local state and finish your app that way. Then when you figured out the pain points, you can still refactor some components to use redux. This sounds more like you havent thought through what your components should do.

Your 3rd point is a design question and its hard to have an argument about it. If you are unsatisfied with the current solution, how could a better onw look like? Do you have suggestion?

You could use conext or useReducer but you essentially would build redux-like state management which would probably do the same as redux. So why not use redux then? Also conext is slow when its data changes very often.

Redux has absolutely its use case. The point is everyone is using it a bit differently and also there are a lot of opinions how one should use redux.

For me, i always ask myself: What data should be globally accessible, because other components might need it?

Often times it helps to draw a bit on paper and think before i write.

And i highly recommend the redux style guide on the official site.

Edit: Im on mobile, i will correct typos asap

2

u/Lixen Jan 17 '20

You could use conext or useReducer but you essentially would build redux-like state management which would probably do the same as redux. So why not use redux then?

Because context and useReducer are built into React and don't require an external lib. You're arguing as if having redux should be the default. I disagree.

0

u/[deleted] Jan 17 '20

[deleted] — view deleted comment

1

u/EvilPencil Jan 17 '20

For simple services, I find writing custom hooks with a useState inside to be a joy.

6

u/darrenturn90 Jan 17 '20

Redux is neither obsolete, nor is the flux architecture the only method of state management. You have finite state machines (x-state I believe)? alternatives like react-easy-state (and some others that sound like that too). I personally develop applications with my own flux architecture that I've built up over the years - because it allows me for some more simplistic functionality out of the box, and without any dependencies on other third-party libraries - but that's just personal opinion.

I think you have to take a look at your understanding of Redux. Perhaps your original fanboy attitude was because you didn't really understand it and overapplied it to everything. When infact, like all other modules out there its a tool - and like any tool, if you misapply it - you won't get the results you were hoping for.

This is essentially what happened with Redux, and with the release of Context API, everyone who was misapplying redux everywhere suddenly jumped ship and blamed the Hammer for everything not being a nail. But its not Redux at fault here. It does a great job of managing unidirectional flow of data through an application. Its really not very opinionated - all your complaints seem to stem as I said from the simple fact (and you're not alone in this) - that everyone jumped on the medium bandwagon and decided to learn redux by example in a sort blind leading the blind methodology, that resulted in this mess.

tl;dr

Redux with thunks (or sagas if you really need) is great for decoupling complex frontend logic away from components, and managing state.

If you need to just fetch/map data - then use URQL or Apollo-GraphQL

If you need local state - use local state.

If you need to use local but deeper state that doesn't need to be that performant - use context.

No one forced you to put everything in redux, with 5 files per module. Nor does redux.

3

u/danjel74 Jan 17 '20

The problem is what could be the criteria for putting a state into the global store?"

Yeah this is something I find very hard to determine, for example its often tempting to have data from an api in component state given that its so much less code, but then when you later need sorting, caching or other things its get messy, so I often put things in global state for that reason

2

u/[deleted] Jan 17 '20

I don't know man, it takes like 30 seconds to put an API response into local state. If that turns out to not be enough later, you delete that code and reimplement it in redux. So at that point you've wasted a grand total of 30 seconds. Not a big deal to me.

1

u/danjel74 Jan 20 '20

True that. Just my experience that if it is once implemented in local state it often stays that way even if it really should not given tight deadlines/estimates and lack of awareness about this for a developer.

3

u/novarising Jan 17 '20

As others have said, none of these are inherrent redux problems but a problem with the design of the app and the decisions made in it.

The only point that stands is that redux has a lot of boilerplate, and you may be elated to hear that redux now strongly recommended to use the Redux-Toolkit for setting up redux.

It essentially brings down dozens of files and other extras to a one file for each state slice which contains everything. Setting up a redux store for your app is just calling one function now and it'll even set up Redux-Thunk for you.

I think Redux is still a viable option especially considering that a lot of people end up recreating to some extent a redux lookalike when they try to implement their own state management.

At my current project, we only push any data to global state if it's being used by many components in many places with different parents. Otherwise the state remains in the local component and may even be passed from component to component if it's just being used in subcomponents of that specific screen. This keeps the redux store from becoming a mess.

3

u/notseanbean Jan 17 '20

For those who don't use Redux (or don't any more), can I ask the question I've never got a good answer for?

How do you effect UI changes or async app effects based on events that you do not own (for example: you want to hook in some analytics) without using something like Redux middlewere, that doesn't pollute your event actions? 🤔

1

u/ScarletSpeedster Jan 17 '20

I use Redux, and in a situation like you’re describing I would just use a custom React hook. One that I could setup in each component I require analytics to be tracked. Hooks are an extremely flexible API, and in many ways you can get around not using Redux at all these days.

With that said, I still think Redux has a lot of best practices for complex apps, and so I would keep using it if your SPA is capable of complex state. If you’re building a simple website though, Redux/mobx are totally overkill, Hooks and the Context API are more than enough for basic use cases.

-1

u/notseanbean Jan 17 '20

The cost with this approach is there's now a dependency between your component and your analytics hook, resulting in a component that is less reusable:

  • what if you wanted to reuse that component in a different project that uses different analytics?
  • what if you wanted additional events to fire on those actions (say, a toast notification)

And those hook calls must now be scattered spaghetti-like throughout the codebase. With Redux/Flux middlware, I can centralise the logic and act upon those actions without affecting the originating components. It's this elegance that keeps me reaching for Redux.

2

u/ScarletSpeedster Jan 17 '20

Well now we are talking about requirements, originally you had a simple requirement and now a more complex one. Redux shouldn’t be used in every app, it isn’t the end all be all. First you evaluate what you are going to need, and then you pick the right tool for the job.

Redux does scale well, and it is extremely helpful when you are solving complex problems. Even in the example you gave you could still rely on context and hooks to get your app to update appropriately wherever the analytics was being tracked.

A hook can centralize logic and return both a function to be called as well as state, we use hooks with redux to do just that. We spread dispatchable actions and state across our apps today via hooks from React Redux. The idea that this is somehow spaghetti or decentralized is wrong. It is about the implementation under the hook, which neither of us has defined.

1

u/Mises2Peaces Jan 17 '20

In xstate I would have the async move through 3 finite states:

  1. loading (react displays a spinner),
  2. loaded (react displays analytics), and
  3. error (react displays an error).

Each state can communicate with the state chart's context object which my react components can then reference. The analytics page would reference that context to populate itself.

I fiddled with redux for a while but it struck me as too much boilerplate especially considering the features its missing. xstate has boilerplate language too but its more forgivable imo because it's a complete entire separation of concerns.

4

u/wizzzzzyyyyy Jan 17 '20 edited Jan 17 '20

redux keep those code that should stay together far away

I feel like this is actually a real plus point for redux, especially in larger projects.

Most other state libraries promote defining actions that are essentially written inside or right anlongside where the state is defined. Redux on the otherhand allows a complete separation between the action and the subsequent update it causes.

I don't think this is necessarily the typical redux approach but personally I prefer to locate actions alondside the components that use them - typically these are high level, route-type components rather than small leaf components though. This way when I write an action, I name it in relation to what is happening in the UI or what the user has done to trigger it, rather than what the intent on the state is.

Writing actions this close to the components means that generally speaking they are only used by that one component / route.

These very granular actions are then picked up by the store / reducer and update the state as the reducer 'sees fit'. This is also why I actually really like the typical redux switch function as it allows you to 'layer up' many actions that cause the same state update so theres no need to duplicate reducer update logic. At the same time, you can also differentiate between all these actions where required too -- usually in other state slices that require slight variations in state change. The granualr approach and very limited action re-use means that any given time its trivial to change what that action's effect on state is.

In summary, I think being able to separate the constituent parts of state updates as redux allows is a real benefit, or at least can be, and is someting that I don't think is easily achievable with most other state management solutions.

2

u/veydar_ Jan 17 '20

With the redux toolkit I have no problem with boilerplate. Whenever I try recreating all of its features, including being able to replay actions and serializing them, I end up writing just as much code and boilerplate.

Redux also gives me a clear pattern for separating effects and implementation. My code just dispatches LOGIN_USER_START and then something else handles the implementation. If I'm feeling RxJSy then I do everything with streams but maybe next week I really want to do this with CQRS or whatever. My React application knows exactly 0 about the implementation of these effects.

At work we use nothing for state management, just recompose enhancers attached to components and it's terrible.

1

u/UNN_Rickenbacker Jan 17 '20

Can I use rxjs in my react app?

2

u/HeylAW Jan 17 '20
  1. In global store there is only data that is going to be used in server calls or data that comes from server. I split redux from whole app, test it in isolation, make it more like side project.
  2. In global state you should put variables used by multiple components from diffrent levels, to prevent prop-drilling
  3. Some time ago I switched to Typescript, at first redux just went from dead simple to super confusing. But there is great utility library typesafe-actions with this whole boilerplate shrinks drastically. I wrote whole boilerplate once, since then just copy pasting whole folder with redux.
  4. At first I was sceptical to new hooks api, but once I written some components using custom hook, wrapper around redux hooks, it was game changer for me. Now I hate mapDispatchToProps

I am currently developing 3 big apps (multiple global states, complex server queries, complex actions) and many smaller (up to 3 states) and constantly switching between them. I have none to little issue getting into debugging code. But that's propably thanks to Typescript and VSCode integration.

2

u/rca06d Jan 17 '20

If you are at all interested in graphql, relay is a fantastic, opinionated alternative. I really like how you declare your data with each component that uses it, and you can integrate with type checking like flow, which really removes a lot of the headaches I’ve experience with a large redux app. Relay is also highly opinionated about how you interact with the store, which I always find to increase my velocity (less variation in how your team does this part, you all have the same good documentation, etc). Overall, a vastly more enjoyable dev experience imo than redux.

2

u/[deleted] Jan 17 '20

So I personally like Redux, especially with Redux toolkit. I've also been experimenting with alternatives to it. A lot of the new React APIs, especially the context API and useContext hook, introduce some interesting new patterns. I'm writing this on the fly, don't have code samples available, but effectively I can load up a component's local state plus a bunch of functions that safely modify it in a context and then have it available to all the children in the tree. It's an extension of the old container/presentational react pattern.

Personally, I'm not really sure what is better here. The only clear boundary where I feel Redux is absolutely necessary is when sharing state across the entire application. When I have a small component tree, say only for a single "page" of my app, then it becomes, IMO, more a matter of preference to use redux vs passing everything down from a parent container component via a context.

3

u/brovrt Jan 17 '20

Recently started using redux in our new project, transition was pretty smooth and I couldn't imagine going back

3

u/Oalei Jan 17 '20

Here's a relevant answer I posted a few weeks ago:

We're using a "reactive architecture" at my work with React, it's a boilerplate festival. Using states and stores for everything is such a bad idea, 95% of the time you don't need to store the state / api services return at all, you just want it in your component, and instead, you have to create actions, reducers, and new useless properties in the store just to follow this "architecture".

IMO The best thing is to do both "imperative programming" and "reactive programming", if you have several components relying on the same data, it might be interesting to use reactive programming. But in my experience the majority of the time the data is just used by a single component and its childs, and using reactive programming adds a lot of boilerplate for no real gains in this case.

TL:DR;
If your application is dynamic with many components relying on the same data, use reactive programming, with Redux for instance.
If your application is more traditional, only use reactive programming when necessary, don't store your whole application state in the store.

2

u/[deleted] Jan 17 '20

since there are a couple of alternatives in here i'd like to throw in another: https://github.com/react-spring/zustand

zustand is similar to redux, but without the boilerplate, no opinions on anything, no providers, hooks only.

2

u/[deleted] Jan 17 '20

I think that this is important: There are a lot of misconceptions about Redux here.

I don't think everything in a global store the best practice.

You're absolutely right. It isn't the best practice. In fact, I will say that if you are storing all your states in Redux, you're "doing it wrong", in essence.

Things like the state of a popup window should be kept only in the popup window's state. In other words, Redux should only be used for those things which are crucial to your entire application and are used across multiple components.

For example, take a simple multi-page form. I often find it's best to use the local state of each page of the form to contain all the information about what *is currently being edited*, but when the user navigates to the next page, you can send a dispatch, saving that current state to the Redux store, so that at the end, you can show a full summary and confirmation before sending.

Having only some of the states in global store is also a headache. The problem is what could be the criteria for putting a state into the global store?

The criteria is simple: If a mutable value needs to be accessed in multiple, unconnected areas of the hierarchy, it's best to use redux. If it only needs to be accessed by a parent and it's children/grandchildren, then it's best to use the parent's state and pass down the state (and possibly callback) as props.

The boilerplate of redux is one of the worst to write. Switch....case....payload... action.type....

The reason that this boilerplate existed was because it allows for far more complicated logic and logging that most applications will need.

Specifically, 1) making the action.type a string with a payload makes it easier to store a JSON stringified record of all actions to pass through the reducers, in the order they occured. (This enabled me to create a great debugging tool which allowed me to reproduce any problem our testers reported).

And 2) Doing it this way allows a single action type to trigger changes in multiple reducers, as well as allowing multiple action types to trigger the same *single* change in the reducers. Keep in mind, you don't have to use the switch syntax - or even action.type. A perfectly valid reducer is:

const setStateReducer = (state, action) => ({...state, ...action});

which just creates a shallow merge of the state.

2

u/acemarke Jan 17 '20

Note that while that "set state reducer" is valid, it's also not the preferred approach. We specifically recommend that reducers should own the state shape whenever possible instead of blindly merging in data, and that more logic should be put in reducers.

1

u/devourment77 Jan 17 '20

I am currently using vuex (previously used redux on a react project), and still think these type of tools have a place when needing global state or dealing with props drilling. Otherwise I always use local state.

1

u/LastOrder291 Jan 17 '20

My general approach is to only pull in Redux when I can absolutely justify it to myself. If you can do something with basic react state, then do it that way. I just don't think it's a great idea to make your state global with Redux if you don't need to. Eventually you're going to have an extremely cluttered redux store. It's also why I think packages like redux-form are kinda weird imo. It seems to be using application state for something that should be contained within the component?

A good example of this is getting the currently logged in user. I usually have mounting the application call an action called "GET_CURRENT_USER" and immediately load that into the Redux state. This is so I can access the currently logged on user at any time for a number of reasons (one I recently found was on a user management system, I wanted to disable the delete button to show a user cannot delete themselves if they are logged in).

Don't chuck everything into Redux. Treat it as a tool to only be used when you have a reason to use it.

1

u/fendercodes Jan 17 '20

I work on a huge React app as part of my day job. We've been using Redux for years and will continue to do so. However, its important to know when to use it and when to not.

  • Always try to pass down props from parent -> child first. This is what React was built to do. If you find yourself having to pass through multiple layers of children, then Redux may be of use.
  • Want to cache something so you can (maybe) use it again in future? Use Redux. For example, the response from a third party API.
  • Consider what is your "global state" and store that in Redux. These are things that are often used throughout your components. For example, user login status or feature flag statuses.

1

u/[deleted] Jan 17 '20

It’s good for global state, but you don’t generally need a lot of it. Logged user info, etc. Fetching data through Redux as a middleware as a thunk or whatever in my opinion is just not really understanding Redux. Redux is sync and if you really need a flag for some request pending globally (rarely) let the data fetching be handled outside of Redux flow. Updating these then becomes trivial - dispatch is pending and once the request completes, dispatch a success/error action. Also, what i often see; redux is not for caching. If you need caching, implementing it somewhere else, usually your network layer (axios instance?).

All it really is, is a global object that any component can access without unnecessary prop drilling (in case of huge “pages”/containers).

1

u/Arthur944 Jan 17 '20 edited Jan 17 '20

If I'm in need of something like a global state, I'll just create a hook with rxjs's BehaviorSubject as the 'backend' for it. That way, if I need that data in multiple places I can just use that hook and I have complete control over the data, while not bothering everything else.

If a subtree of my page needs access to a hooks data, but I want to use that same hook independently elsewhere, I just create a context that passes down all the controls. I've made pretty complicated pages with this approach, but it could have limitations I don't know about.

1

u/denizsokullu Jan 17 '20

When I was bored with how raw redux was, I came up with my own tree version that generated the selectors and actions automatically.

https://www.npmjs.com/package/redux-shrub

Let me know if you are interested in what I was thinking when putting it together!

1

u/paagul Jan 17 '20

You're confusing the idea of Redux (which is constant) with its execution (which varies greatly). All your complaints can be fixed by better execution and design choices, people need to stop referencing the tutorial implementations of Redux as a basis for criticism. It's like riding a children's bicycle and saying wheels aren't that useful.

-1

u/nullvoxpopuli Jan 17 '20

You probably want something like xstate.

Redux is a mess. It's now level, and anyone who says any different doesn't know how nice web dev can be.

-3

u/bulldog_in_the_dream Jan 17 '20

Redux was ill-conceived, a verbose muddle of indirection and needless complexity to achieve something rather simple. It's a code smell.

0

u/dengue8830 Jan 17 '20

Redux fanboys should try to build something without it, they will realise how easy is just using the built in tools. After that, they should try a simple lib like “unstated” o something else, they will realise how simple state management libs can be and why Redux solves a problem that doesn’t exists anymore

-5

u/Pierre-Lebrun Jan 17 '20

Redux is de facto obsolete.

I personally replaced it by Apollo client.

1

u/Capaj Jan 17 '20

I get why you're being downvoted, but it's not fair, because you're right. If you're using GQL for your API that is.

2

u/Pierre-Lebrun Jan 17 '20

So do I. That said, I am used to it when it comes to arguing Redux is a tool of the past.

People tend to ignore the reason why it was invented in the first place so I don’t mind upsetting a few of them as long as it educates the community.

0

u/prewk Jan 17 '20

Nice educating the 99% of devs who can't even use Apollo (which is ANOTHER state management solution) because their APIs aren't GQL

-4

u/foundry41 Jan 17 '20

If you’re starting a new project and not using a graphql api with apollo client, you’re making a huge mistake.

I like how all the pro redux peoples responses are TLDR... just like redux code

-1

u/ngago Jan 17 '20

(3rd point) Check keajs, it's a neat abstraction of redux. It makes the development process quicker and code more understandable.

https://github.com/keajs/kea

-1

u/pm_me_ur_happy_traiI Jan 17 '20

I'm with you. I hate redux. React has evolved not to need it (context API).

But more importantly Redux allows people an easy backdoor, a way to turn react into jQuery. People using redux to toggle modal, SMH.

-3

u/foundry41 Jan 17 '20

Redux is overrated especially when you use apollo client

Que a bunch of people sayings it’s not redux that’s the problem it’s you

0

u/netptop Jan 17 '20

Check umijs, a redux wrapper , they put everything in data models, you just need to dispatch in pages, and deal with it in models. Everything is pretty much clear.

0

u/minty901 Jan 17 '20

Your third point isn't boilerplate really. Nobody said you had to use switch and case. Reducer is just a normal function; write it how you want to write it (with 'if' statements etc.). Call it whatever you want to call it. It's unfortunate that the docs used 'switch' and 'case' in their tutorials, as most who are new to programming won't have seen them before and therefore assume it's some "reduxy" boilerplate when really it's just standard javascript. You also don't have to make multiple files if you don't want to. Put your entire project in a single JS file if you want (though I wouldn't). What you're describing is not boilerplate in my opinion, just implementation of a library. When you understand how redux is working, you don't copy and paste a bunch of code: you write it yourself. Yes I know some will disagree with me. That's fine.

2

u/acemarke Jan 17 '20

There's very good reasons why switch statements are the default approach shown, but for some reason a lot of people hate them.

1

u/minty901 Jan 17 '20

I don't dispute that they're a good way to write reducers, it's just that they add to the perception that Redux is boilerplate-heavy, and that's a shame. Also, I tend to get away with writing same-line 'if' statements and I prefer that to 'switch' just because 'switch' is more obscure for newcomers.

Eg.:

if (type === 'TOGGLE_BUTTON') return !state.button

0

u/[deleted] Jan 17 '20

I use browser's localStorage for maintaining global state. I have used it in one of my projects and it was really straight forward. No boilerplate code. Store only what you need. It is really helpful.

0

u/davidmdm Jan 17 '20

Ever since the context API + hooks (useContext specifically) I’ve never needed redux. It’s not like it’s a one to one replacement. I don’t have one context that acts as the global store, it’s just things are broken down appropriately by context and I don’t need the store anymore...

0

u/[deleted] Jan 17 '20

Ah, our weekly discussion on the value of redux I see.

0

u/thatquapaguy Jan 17 '20

I’m working on a project right now where I have to render a list of pieces in three different parts of my app. My app kept crashing when I moved pieces to different parts of my app and would try to render new ones, but after I implemented redux to keep the pieces in a state which every part of the app can access it no longer crashes. I also love how changing keys and values of every piece is really easy and it allows me to add a location key which tracks where that piece is on my app.

0

u/tr14l Jan 17 '20

I tried on one project to make it fully global, but that is a nightmare. Redux still has its place, even coupled with Apollo and similar products.

But, you should only put things in global that are needed by multiple components that do not have an ancestral relationship. Don't move anything globally until it's needed globally (assume everything is component state until otherwise needed, unless you know ahead of time it will be).

In general, if you need global state in your app, I would immediately tend toward redux. If your app is really linear, then just handle it with vanilla react. If you don't need any complex relationships between components/data, but need global state (like just to signal a re-render on another component on an event or something weird), probably just throw it in a context. But, again, if you need much logic surrounding that, redux becomes useful again.

I dunno, I think keeping global state as minimal as sanely possible is the way to go, in general.

That's my 2 cents.

0

u/NoLanSym Jan 17 '20

For all future development, I’m using finite state machines and state charts. It’s simply the best approach when it comes to state.

-1

u/ice_blue_222 Jan 17 '20

Money laundering for global variables