Software Developer who works mostly on Web stuff. I like JS, but I also like other things. I also do photography, and look at sneakers online that I will never be able to buy.
Usually, I would say that if you don't need Redux, you have no reason to learn it. However, if you are curious or believe that it would be useful, Dan Abramov has a good series of videos about Redux on Egghead.io. I am currently getting thru them and they are 👌
Also, relevant for the future, remember that you might not need redux <-- Good article about when to use Redux
Edit: I also want to add this great introduction to Redux on Code Cartoons. Lin Clark is a fantastic developer, teacher, and speaker that also has great cartoon articles about Web Assembly, Javascript engines, React Fiber.
I agree with this. You can also learn the principles of what makes Redux interesting without having to learn the nuts and bolts. This will make it easiest once you get to using it.
This is also the canonical inflection point which makes React tough to navigate. I have the feeling that the core React API is here to stay but some of the glue that holds it all together still hasn't gotten there yet. It's powerful but sometimes at the expense of human comprehensibility.
Software Developer who works mostly on Web stuff. I like JS, but I also like other things. I also do photography, and look at sneakers online that I will never be able to buy.
I believe that. I almost dropped out of learning React when I heard about Flux and Redux and so on. It is still a pain point for me sometimes to add Redux to a project, I always end up going back to older projects where I could reason out a "boilerplate" for Redux.
I'm curious, what did you mean with "glue that holds it all together still hasn't gotten there yet"?
I mean that the further you zoom out, the less I feel like React has really nailed it. I think Redux is wonderful in principle, but fails to be intuitive enough to be great. I spend a lot of time in Ruby land where problems aren't really solved until the developer ergonomics are really natural.
This is more how I feel that what I know. I feel like ecosystems settle down when things become really intuitive. Seems like the React ecosystem settled down at the component level more than it's been able to settle down from a big picture perspective.
It seems like Angular had the reverse problem where it tried to make the big picture easier to deal with but the localized data flow and interfaces were brutal to deal with.
Software Developer who works mostly on Web stuff. I like JS, but I also like other things. I also do photography, and look at sneakers online that I will never be able to buy.
Do you think the main issue with Redux being good but not great has to do with developer ergonomics? That is, with how annoying Redux can be to set up and reason about? compared to how easy React is to reason and understand at the component level.
On a big picture setting, I think other projects have been trying to fill the void on that. Projects like Next.js seem to be aimed more at using React with a full project in mind, instead of thinking of React like a component library.
Hi, I'm a Redux maintainer. Per your comment, earlier this year I opened up an issue to discuss ways we can improve the Redux learning experience and build better abstractions on top of Redux : github.com/reactjs/redux/issues/2295 .
If you or anyone else has suggestions or thoughts, please comment in that thread, or ping me on Twitter or Reactiflux to discuss.
Thanks for the comment Mark. Your response has me pretty motivated to think a lot harder about why I feel the way I do. I'll read through that discussion and definitely ping you about it at some point.
I will freely tell people that Redux isn't for everyone, and it isn't for all situations. However, I do think that a lot of people misunderstand the reasons why Redux works the way it does.
For anyone interested in that topic, I suggest reading these articles:
Dan Abramov's post You Might Not Need Redux, which discusses the tradeoffs Redux asks you to make and the benefits you get in return
Justin Falcone's post What's So Great About Redux?, which has some deep thoughts about how Redux relates to OOP and things like "setter" functions, and complexity vs simplicity
The biggest omission in Redux is a declarative way to represent external side effects like API calls. It was such a felt absence that a lot of libraries have sprung up to handle this. And each middleware has its own set of tradeoffs to weigh.
If Redux reducers could return declarative side effects along with the store changes, and if the side effects could trigger messages back into Redux to report the outcome, that would complete the external feedback loop. And a lot of middleware confusion would be avoided. The same kind of pattern can be used for local side effects as well (e.g. FileReader API). That's the model used by Elm, although the pattern is older than that.
Redux was deliberately designed to leave side effects as an external consideration so that users could choose their preferred syntax. See the slides from my recent presentation on the Redux ecosystem for some quotes from Dan and Andrew on that topic.
One of the slides in that presentation shows stats on the most popular Redux side effects libraries. redux-thunk and redux-saga are by far the most popular, indicating that Redux users prefer to deal with plain functions and generator functions. redux-observable has interest, but is less popular.
But no, I wouldn't call this situation an "omission". It was a deliberate decision to let the community decide what side effects approaches they want to use with Redux.
I don't really buy that it was a deliberate decision, based on this issue for one. I think it's more probable that the reason was just not knowing how to implement it robustly. (And I would not have known either! Not judging!) But I do take your point.
In any case, I was just expressing my feedback. Side effects (especially API calls) are table stakes for almost everything I develop. So this absence and instead adding 5 more things (side effect libraries) to my list of things to evaluate before starting my first Redux project was a hindrance. So much so that I never did. But I would love to see Redux usage and FP grow further among React users. I think it benefits us all. So I offered my feedback, such as it is. Thanks for your time and best wishes!
Note that there's a distinct difference between "not being sure how to go about implementing reducer-based side effects", and "deliberately deciding to not have side effect management as part of the Redux core". Two specific quotes from Dan and Andrew's AMA on Hashnode show that it was a deliberate decision:
Andrew: "The reason the middleware API exists in the first place is because we explicitly did not want to prescribe a particular solution for async. With Redux, we knew that the community would come up with a multitude of better async solutions that whatever we could have built in ourselves."
Dan: "We didn’t want to prescribe something like this in Redux itself because we know a lot of people are not comfortable with learning Rx operators to do basic async stuff. It’s beneficial when your async logic is complex, but we didn’t really want to force every Redux user to learn Rx, so we intentionally kept middleware more flexible."
So, having side effects approaches not be built into the core was clearly a deliberate design decision.
There's obviously a lot of different ways to manage async behavior in JS. Callbacks, promises, async/await, observables, and much more. You're right that choosing a side effects approach is something Redux users need to do. This is both a strength and a bit of a pain point.
My React/Redux links list has a large section of articles on Redux side effects approaches, including many articles comparing different libraries. My own personal advice is to start with thunks, and if you need a more powerful async approach, using sagas or observables based on your preference for syntax. From your comments, it sounds like redux-loop is more what you're looking for.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
There is a cool video on Egghead on some the React component lifecycle methods.
I feel the official React documentation on lifecycle methods is also super useful.
Usually, I would say that if you don't need Redux, you have no reason to learn it. However, if you are curious or believe that it would be useful, Dan Abramov has a good series of videos about Redux on Egghead.io. I am currently getting thru them and they are 👌
Also, relevant for the future, remember that you might not need redux <-- Good article about when to use Redux
Edit: I also want to add this great introduction to Redux on Code Cartoons. Lin Clark is a fantastic developer, teacher, and speaker that also has great cartoon articles about Web Assembly, Javascript engines, React Fiber.
Thank you so much Sammy, I'll check'em out
I agree with this. You can also learn the principles of what makes Redux interesting without having to learn the nuts and bolts. This will make it easiest once you get to using it.
This is also the canonical inflection point which makes React tough to navigate. I have the feeling that the core React API is here to stay but some of the glue that holds it all together still hasn't gotten there yet. It's powerful but sometimes at the expense of human comprehensibility.
I believe that. I almost dropped out of learning React when I heard about Flux and Redux and so on. It is still a pain point for me sometimes to add Redux to a project, I always end up going back to older projects where I could reason out a "boilerplate" for Redux.
I'm curious, what did you mean with "glue that holds it all together still hasn't gotten there yet"?
I mean that the further you zoom out, the less I feel like React has really nailed it. I think Redux is wonderful in principle, but fails to be intuitive enough to be great. I spend a lot of time in Ruby land where problems aren't really solved until the developer ergonomics are really natural.
This is more how I feel that what I know. I feel like ecosystems settle down when things become really intuitive. Seems like the React ecosystem settled down at the component level more than it's been able to settle down from a big picture perspective.
It seems like Angular had the reverse problem where it tried to make the big picture easier to deal with but the localized data flow and interfaces were brutal to deal with.
Ok I see what you mean now, I think.
Do you think the main issue with Redux being good but not great has to do with developer ergonomics? That is, with how annoying Redux can be to set up and reason about? compared to how easy React is to reason and understand at the component level.
On a big picture setting, I think other projects have been trying to fill the void on that. Projects like Next.js seem to be aimed more at using React with a full project in mind, instead of thinking of React like a component library.
Yeah I'd bet Next.js will be a good project for a long time. I think it has good vision/leadership behind it from what I've seen.
Ben Halpern:
Hi, I'm a Redux maintainer. Per your comment, earlier this year I opened up an issue to discuss ways we can improve the Redux learning experience and build better abstractions on top of Redux : github.com/reactjs/redux/issues/2295 .
If you or anyone else has suggestions or thoughts, please comment in that thread, or ping me on Twitter or Reactiflux to discuss.
Thanks for the comment Mark. Your response has me pretty motivated to think a lot harder about why I feel the way I do. I'll read through that discussion and definitely ping you about it at some point.
Great, looking forward to hearing your feedback!
I will freely tell people that Redux isn't for everyone, and it isn't for all situations. However, I do think that a lot of people misunderstand the reasons why Redux works the way it does.
For anyone interested in that topic, I suggest reading these articles:
The biggest omission in Redux is a declarative way to represent external side effects like API calls. It was such a felt absence that a lot of libraries have sprung up to handle this. And each middleware has its own set of tradeoffs to weigh.
If Redux reducers could return declarative side effects along with the store changes, and if the side effects could trigger messages back into Redux to report the outcome, that would complete the external feedback loop. And a lot of middleware confusion would be avoided. The same kind of pattern can be used for local side effects as well (e.g. FileReader API). That's the model used by Elm, although the pattern is older than that.
Redux was deliberately designed to leave side effects as an external consideration so that users could choose their preferred syntax. See the slides from my recent presentation on the Redux ecosystem for some quotes from Dan and Andrew on that topic.
One of the slides in that presentation shows stats on the most popular Redux side effects libraries.
redux-thunkandredux-sagaare by far the most popular, indicating that Redux users prefer to deal with plain functions and generator functions.redux-observablehas interest, but is less popular.If you do want declarative side effects returned from reducers, then the
redux-looplibrary is for you. There's also several other libraries for reducer-based side effects as well.But no, I wouldn't call this situation an "omission". It was a deliberate decision to let the community decide what side effects approaches they want to use with Redux.
I don't really buy that it was a deliberate decision, based on this issue for one. I think it's more probable that the reason was just not knowing how to implement it robustly. (And I would not have known either! Not judging!) But I do take your point.
In any case, I was just expressing my feedback. Side effects (especially API calls) are table stakes for almost everything I develop. So this absence and instead adding 5 more things (side effect libraries) to my list of things to evaluate before starting my first Redux project was a hindrance. So much so that I never did. But I would love to see Redux usage and FP grow further among React users. I think it benefits us all. So I offered my feedback, such as it is. Thanks for your time and best wishes!
Note that there's a distinct difference between "not being sure how to go about implementing reducer-based side effects", and "deliberately deciding to not have side effect management as part of the Redux core". Two specific quotes from Dan and Andrew's AMA on Hashnode show that it was a deliberate decision:
So, having side effects approaches not be built into the core was clearly a deliberate design decision.
There's obviously a lot of different ways to manage async behavior in JS. Callbacks, promises,
async/await, observables, and much more. You're right that choosing a side effects approach is something Redux users need to do. This is both a strength and a bit of a pain point.My React/Redux links list has a large section of articles on Redux side effects approaches, including many articles comparing different libraries. My own personal advice is to start with thunks, and if you need a more powerful async approach, using sagas or observables based on your preference for syntax. From your comments, it sounds like
redux-loopis more what you're looking for.