5 ms·

I still don't quite understand the reasons for the amount of shit Redux gets these days–I find the code (especially when using Redux Starter Kit w/ Typescript)

I still don't quite understand the reasons for the amount of shit Redux gets these days–I find the code (especially when using Redux Starter Kit w/ Typescript) to be easy to debug, easy to read, and easy to maintain. To me, the boilerplate is evidence of a degree of abstraction that may not always be appropriate for every SPA, but in my experience, is still often a really useful and practical choice.

ng12 7y ago
I feel like Redux is a foot-cannon. Too many people use it for simple apps where they take on all the pain but see none of the benefits. I always advise people to avoid it until you're sure you need it.
acemarke 7y ago
When you get a chance, please check out our new Redux Starter Kit package. It includes utilities to simplify several common Redux use cases, including store setup, defining reducers, immutable update logic, and even creating entire "slices" of state at once: https://redux-starter-kit.js.org https://redux-starter-kit.js.org It's also written in TypeScript itself, so it works well for TS usage. It doesn't do as much strict magical inference as something like `typesafe-actions`, but it should be very usable. I recently wrote a small example "Github issues" app that's written in TS and uses Redux Starter Kit and our new React-Redux hooks API, if you'd like to see how the code looks: https://github.com/markerikson/rsk-github-issues-experiment https://github.com/markerikson/rsk-github-issues-experiment In particular, here's an example of RSK's `createSlice()` API in action, with TS and some thunks: https://github.com/markerikson/rsk-github-issues-experiment/blob/67691649ce5815158e7f86eefac40df221fd1817/src/features/IssuesList/issues.ts https://github.com/markerikson/rsk-github-issues-experiment/...
- ht85 7y ago
  Small nitpick: loading state should be a counter incremented / decremented on each request / response, not a boolean. This looks very nice though, avoids almost all the repetitions you usually have to write when setting up reducers and actions!
root_axis 7y ago
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.
    - 7y ago
Octoth0rpe 7y ago
I think a good bit of is it the fact that the example code on the redux website is _extremely_ verbose, and that most people who stick with redux for the long haul end up using a variety of shortcuts that make their code significantly terser yet still readable. I'm in the middle of writing a short presentation for my local jsx meetup on a set of simple rules for writing good redux code. As part of the presentation, I'm providing two repos for a webapp, one with the store written using the exact code style used by the redux website, and a second one using my suggested rules and IMO the result is pretty dramatic. Until I got to writing the 'official' style version of the app, I had forgotten just how verbose redux can be. I would NOT want to use redux if I was sticking to the 'official' example style.
- acemarke 7y ago
  I'd like to see that presentation. Got a link to the slides? And yes, as part of our planned docs revamp, we're going to write example code that is much shorter, including use of Redux Starter Kit by default and use of the "ducks" pattern and/or "feature folders" by default. Could you leave a comment at https://github.com/reduxjs/redux/issues/3313 https://github.com/reduxjs/redux/issues/3313 with some notes on how the current docs examples are too verbose?
  - Octoth0rpe 7y ago
    > I'd like to see that presentation. Got a link to the slides? If you're willing to wait a week, I could share. I'm really not ready to share it as is (still working on the code). > Could you leave a comment at https://github.com/reduxjs/redux/issues/3313 https://github.com/reduxjs/redux/issues/3313 with some notes on how the current docs examples are too verbose? Yes, I could do that, but again I'll need at least a couple of days. It's a crazy week for me. If you want a _quick_ example, here's one from the 'actions' section of the basic tutorial: ------ function addTodo(text) { return { type: ADD_TODO, text } } ------ I would advocate writing this as: const addTodo = (payload) => ({ type: ADD_TODO, payload, }); ------- 4 lines instead of 6, just as readable to me. And frankly, I'd consider doing that as a 1-liner since there's only two attributes in the action anyway. Where I work, we have a semi-official rule of 'newlines for attributes if there are more than 3, or if the line length > 80', so our policy would write this action creator as a single line. export const addTodo = payload => ({ type: ADD_TODO, payload });
draw_down 7y ago
It spreads the responsibility for some change in state across a number of files, and generally feels really incoherent. That's what I don't like about it anyway.
ehutch79 7y ago
My guess is that tutorials and whatnot don't include, upfront or at all, a section on when to actually use redux. It's really easy to get the feeling EVERYTHING needs to go into global state management, from variables used once in one component on one page, down to loop counters. The simplistic contrived examples exacerbate this. A list of todos doesn't really need to be in global state. An auth system would though. However, all the examples only show things like list views or a detail view, that don't need to be globally available.

ng12 7y ago

I feel like Redux is a foot-cannon. Too many people use it for simple apps where they take on all the pain but see none of the benefits. I always advise people to avoid it until you're sure you need it.

acemarke 7y ago

When you get a chance, please check out our new Redux Starter Kit package. It includes utilities to simplify several common Redux use cases, including store setup, defining reducers, immutable update logic, and even creating entire "slices" of state at once: https://redux-starter-kit.js.org https://redux-starter-kit.js.org It's also written in TypeScript itself, so it works well for TS usage. It doesn't do as much strict magical inference as something like `typesafe-actions`, but it should be very usable. I recently wrote a small example "Github issues" app that's written in TS and uses Redux Starter Kit and our new React-Redux hooks API, if you'd like to see how the code looks: https://github.com/markerikson/rsk-github-issues-experiment https://github.com/markerikson/rsk-github-issues-experiment In particular, here's an example of RSK's `createSlice()` API in action, with TS and some thunks: https://github.com/markerikson/rsk-github-issues-experiment/blob/67691649ce5815158e7f86eefac40df221fd1817/src/features/IssuesList/issues.ts https://github.com/markerikson/rsk-github-issues-experiment/...

ht85 7y ago
Small nitpick: loading state should be a counter incremented / decremented on each request / response, not a boolean. This looks very nice though, avoids almost all the repetitions you usually have to write when setting up reducers and actions!

root_axis 7y ago

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

Octoth0rpe 7y ago

I think a good bit of is it the fact that the example code on the redux website is _extremely_ verbose, and that most people who stick with redux for the long haul end up using a variety of shortcuts that make their code significantly terser yet still readable. I'm in the middle of writing a short presentation for my local jsx meetup on a set of simple rules for writing good redux code. As part of the presentation, I'm providing two repos for a webapp, one with the store written using the exact code style used by the redux website, and a second one using my suggested rules and IMO the result is pretty dramatic. Until I got to writing the 'official' style version of the app, I had forgotten just how verbose redux can be. I would NOT want to use redux if I was sticking to the 'official' example style.

acemarke 7y ago
I'd like to see that presentation. Got a link to the slides? And yes, as part of our planned docs revamp, we're going to write example code that is much shorter, including use of Redux Starter Kit by default and use of the "ducks" pattern and/or "feature folders" by default. Could you leave a comment at https://github.com/reduxjs/redux/issues/3313 https://github.com/reduxjs/redux/issues/3313 with some notes on how the current docs examples are too verbose?
- Octoth0rpe 7y ago
  > I'd like to see that presentation. Got a link to the slides? If you're willing to wait a week, I could share. I'm really not ready to share it as is (still working on the code). > Could you leave a comment at https://github.com/reduxjs/redux/issues/3313 https://github.com/reduxjs/redux/issues/3313 with some notes on how the current docs examples are too verbose? Yes, I could do that, but again I'll need at least a couple of days. It's a crazy week for me. If you want a _quick_ example, here's one from the 'actions' section of the basic tutorial: ------ function addTodo(text) { return { type: ADD_TODO, text } } ------ I would advocate writing this as: const addTodo = (payload) => ({ type: ADD_TODO, payload, }); ------- 4 lines instead of 6, just as readable to me. And frankly, I'd consider doing that as a 1-liner since there's only two attributes in the action anyway. Where I work, we have a semi-official rule of 'newlines for attributes if there are more than 3, or if the line length > 80', so our policy would write this action creator as a single line. export const addTodo = payload => ({ type: ADD_TODO, payload });

draw_down 7y ago

It spreads the responsibility for some change in state across a number of files, and generally feels really incoherent. That's what I don't like about it anyway.

ehutch79 7y ago

My guess is that tutorials and whatnot don't include, upfront or at all, a section on when to actually use redux. It's really easy to get the feeling EVERYTHING needs to go into global state management, from variables used once in one component on one page, down to loop counters. The simplistic contrived examples exacerbate this. A list of todos doesn't really need to be in global state. An auth system would though. However, all the examples only show things like list views or a detail view, that don't need to be globally available.