4 ms·

Redux adds more complexity and is simply unnecessarily. You just don't need it. If your back-end is something like a wire protocol over ws where you've already

Redux adds more complexity and is simply unnecessarily. You just don't need it. If your back-end is something like a wire protocol over ws where you've already structured everything as "actions" or "messages" it's a decent fit, but even then React hooks are a better choice (e.g. reducer hook). For everything else there's just no reason to use it. I would go so far as to say that use of redux is an anti-pattern. Of course, if your app is already built on redux, that doesn't mean refactoring away from it should be a business priority, but new projects should avoid it.

ng12 7y ago
> You just don't need it I have a lots data that needs to be globally available between multiple pages and is largely interdependent (i.e. one update might affect multiple slices of the data). The data needs to be updated optimistically (i.e. we show updates to the user before the fetch succeeds and unwind if it fails) and the updates are triggered through a mix of web socket polling and user actions. You're right that I don't need Redux for this project, but oh boy I really like using it.
- root_axis 7y ago
  > lots data that needs to be globally available between multiple pages and is largely interdependent This is the ideal use case for react context. It's not as if redux is doing something magical to achieve that result, it uses context under the hood anyway, but it adds on the complex and usually unnecessary action/reducer abstractions. I have mentored about two dozen developers on react and redux projects over the past three or so years, I've learned this lesson the hard way. > the data needs to be updated optimistically (i.e. we show updates to the user before the fetch succeeds and unwind if it fails) and the updates are triggered through a mix of web socket polling and user actions. Redux doesn't address these problems specifically, but I'd be curious to understand why you think redux is of particular value for them. > You're right that I don't need Redux for this project, but oh boy I really like using it. Well that's fine, I'm not arguing that you shouldn't use what you like.
  - ng12 7y ago
    > This is the ideal use case for react context. Not really. React.Context solves the global availability bit but it does not scale with the size and complexity of your data. You'll end up building a custom Redux store inside your Context anyways, except now with an uglier API and no devtools. Alternatively, you could just use a bunch of independent React Contexts, but that becomes unmanageable quickly especially if the Contexts are interdependent. > Redux doesn't address these problems specifically, but I'd be curious to understand why you think redux is of particular value for them. The action/reducer model is a very natural way of modeling it. The business logic and data fetching layer is completely disjoint from the actual data store. We can simply describe what happened -- hey, we tried to post this data, this request succeeded, but this one failed and here's the error message -- and then let the reducers decide how that updates their state, if at all. It makes it much easier to refactor code and add new features, especially when they can just hook into existing actions. Even if I didn't use Redux -- and to be honest I don't love the API sometimes -- I would follow the Redux patterns. When done well it's a really seamless way of managing data that would otherwise be a lot of ugly business logic spaghetti. > have mentored about two dozen developers on react and redux projects over the past three or so years, I've learned this lesson the hard way. If you're mentoring novice developers I don't doubt the apps they were working on didn't necessitate Redux. It's a powerful tool but it comes as a price, which is why as much as I like it I avoid recommending it to people (especially junior developers) unless they have a really good case for it.
kansface 7y ago
React hooks do not solve the same problem as Redux. Hooks solve the problem: how do I share functionality (logic) between stateless, functional components. Redux is for sharing data. Besides sharing data, (React-)Redux is (or at least was) way more efficient because it can preemptively avoid rendering altogether. > If your back-end is something like a wire protocol over ws where you've already structured everything as "actions" or "messages" it's a decent fit Redux has been fine for every API I've every used. Maybe you've only seen crazy codebases where people write a unique action generator/action_type/reducer for every single endpoint, but that isn't exactly a problem with Redux.

ng12 7y ago

> You just don't need it I have a lots data that needs to be globally available between multiple pages and is largely interdependent (i.e. one update might affect multiple slices of the data). The data needs to be updated optimistically (i.e. we show updates to the user before the fetch succeeds and unwind if it fails) and the updates are triggered through a mix of web socket polling and user actions. You're right that I don't need Redux for this project, but oh boy I really like using it.

root_axis 7y ago
> lots data that needs to be globally available between multiple pages and is largely interdependent This is the ideal use case for react context. It's not as if redux is doing something magical to achieve that result, it uses context under the hood anyway, but it adds on the complex and usually unnecessary action/reducer abstractions. I have mentored about two dozen developers on react and redux projects over the past three or so years, I've learned this lesson the hard way. > the data needs to be updated optimistically (i.e. we show updates to the user before the fetch succeeds and unwind if it fails) and the updates are triggered through a mix of web socket polling and user actions. Redux doesn't address these problems specifically, but I'd be curious to understand why you think redux is of particular value for them. > You're right that I don't need Redux for this project, but oh boy I really like using it. Well that's fine, I'm not arguing that you shouldn't use what you like.
- ng12 7y ago
  > This is the ideal use case for react context. Not really. React.Context solves the global availability bit but it does not scale with the size and complexity of your data. You'll end up building a custom Redux store inside your Context anyways, except now with an uglier API and no devtools. Alternatively, you could just use a bunch of independent React Contexts, but that becomes unmanageable quickly especially if the Contexts are interdependent. > Redux doesn't address these problems specifically, but I'd be curious to understand why you think redux is of particular value for them. The action/reducer model is a very natural way of modeling it. The business logic and data fetching layer is completely disjoint from the actual data store. We can simply describe what happened -- hey, we tried to post this data, this request succeeded, but this one failed and here's the error message -- and then let the reducers decide how that updates their state, if at all. It makes it much easier to refactor code and add new features, especially when they can just hook into existing actions. Even if I didn't use Redux -- and to be honest I don't love the API sometimes -- I would follow the Redux patterns. When done well it's a really seamless way of managing data that would otherwise be a lot of ugly business logic spaghetti. > have mentored about two dozen developers on react and redux projects over the past three or so years, I've learned this lesson the hard way. If you're mentoring novice developers I don't doubt the apps they were working on didn't necessitate Redux. It's a powerful tool but it comes as a price, which is why as much as I like it I avoid recommending it to people (especially junior developers) unless they have a really good case for it.

kansface 7y ago

React hooks do not solve the same problem as Redux. Hooks solve the problem: how do I share functionality (logic) between stateless, functional components. Redux is for sharing data. Besides sharing data, (React-)Redux is (or at least was) way more efficient because it can preemptively avoid rendering altogether. > If your back-end is something like a wire protocol over ws where you've already structured everything as "actions" or "messages" it's a decent fit Redux has been fine for every API I've every used. Maybe you've only seen crazy codebases where people write a unique action generator/action_type/reducer for every single endpoint, but that isn't exactly a problem with Redux.