6 ms·

The rush to use Redux for every React project is one of the most annoying parts of the React community; using a tool just to use it, before understanding if you

The rush to use Redux for every React project is one of the most annoying parts of the React community; using a tool just to use it, before understanding if you need it or not. This article summarizes a lot of good points.

nfriedly 9y ago
Agreed. Until recently, my team was responsible for most of the official IBM Watson service demos, and we standardized on React for those and built up a nice library of react components[1]. None of them used Redux, though, because in general it just wasn't needed. When we handed off responsibility of these demos to the individual service teams, we wrote up guidelines that specifically recommended React but not Redux - with the logic that if the demo is getting to a point where Redux is providing value, then it's probably too complex for a demo. Our new project is a more involved web app that includes lots of state, shared across many different components, and we're making great use of Redux there. [1]: https://watson-developer-cloud.github.io/react-components/ https://watson-developer-cloud.github.io/react-components/
- matsemann 9y ago
  One of the things I find hardest with redux is to make reusable components (across projects), as they have to be added to the state tree somewhere, and then connected. With nested components you may get implicit dependencies on where in the tree it should be. All this makes it very cumbersome. So even though most of our apps use Redux, the reusable parts use setState as they then can be completely independent.
  - acemarke 9y ago
    Yeah, that is a tradeoff - globalized state makes a lot of scenarios easier, but does make complete encapsulation and reusability harder. Most of the third-party "Redux-connected component" libs I've seen provide a reducer that they expect to be added to the root of the state tree under a specific key name. Works, but it's not ideal. I've seen a few that let you provide a selector or key name when you initialize the library, so that the library is more flexible in how it's connected. There's been a lot of discussion of various approaches for implementing fully encapsulated/reusable Redux-based React components in Sebastian Lorber's "Scalable Frontend with Elm or Redux" repo [0], and my links list has a section of additional articles on the topic of encapsulation with Redux [1]. My Redux addons catalog also has a large section for libraries that implement some form of per-component state or component encapsulation in Redux as well [2]. So, it's not impossible, but it does take work and there are tradeoffs either way. [0] https://github.com/slorber/scalable-frontend-with-elm-or-redux https://github.com/slorber/scalable-frontend-with-elm-or-red... [1] https://github.com/markerikson/react-redux-links/blob/master/redux-architecture.md#encapsulation-and-reusability https://github.com/markerikson/react-redux-links/blob/master... [2] https://github.com/markerikson/redux-ecosystem-links/blob/master/component-state.md https://github.com/markerikson/redux-ecosystem-links/blob/ma...
  - nfriedly 9y ago
    Yea, our new project has a lot of 'container components' where there is a parent component that connects to redux (and react-i18next) gets all of the data & translated text, and then passes it to a child component that is just a regular stateless component that could be easily re-used (and tested!)
- FLGMwt 9y ago
  These look great! Thanks for sharing. Also, I like the idea of loosely enforcing against a state management library to cap demo sizes.
_greim_ 9y ago
> annoying I like React's ethos of avoiding complexity until you need it, but these smug attitudes are starting to get really tiresome.
- scaryclam 9y ago
  I'm not sure I'd characterise the attitude of avoiding additional dependancies until you know you really need them as smug...
  - always_good 9y ago
    The smugness is when you classify a bunch of other people as annoying as if they are incapable of making their own technical trade-offs. "Wake up, sheeple!" I use Redux on just about every React project because none of my projects are toy projects. And I'm not just doing it to annoy OP.
cookiecaper 9y ago
This summarizes everything about the JavaScript ecosystem, so it shouldn't really surprise React users that there is no logic behind the community's behavior. People have finally succeeded in making JavaScript an important development platform by sheer force of will, insisting that JavaScript must become important in order to justify their adoption of the fad. Before this critical mass was attained, there was no real reason to use JS whenever the option was available, and virtually everyone who adopted Node.js and friends was doing it "just to [do] it", in service to the fad kicked off by Google's promotion of Chrome/V8. Consider that prior to V8, JavaScript was so disliked that the only way to get someone to read a book about it was to name it "JavaScript: The Good Parts". The coder would be surprised to hear that anyone thought JavaScript had any good parts, and would want to figure out what they were, so that his/her days spent in client-side hell would go just a little smoother. Then Google released Chrome with V8, some people thought this meant JavaScript was cool now, and it's snowballed from there.
- asherwebb 9y ago
  Javascript is important because it runs on billions of devices - more devices can process javascript than any other language. Being the most used programming language in the world makes it an important development platform by default.
  - cookiecaper 9y ago
    While it may be true that JavaScript has had a large installed base for many years, that installed environment was only capable of operating within the context of a single page load, as long as the browser was open and active, and really was only useful for manipulating the DOM (and JavaScript was a sorry platform even within that ultra-narrow scope). Node.js changed things by making the platform available on the backend, allowing programs to live longer, but the notion that JS was "important" as a general development solution is incorrect. It certainly was not the "native" or obvious solution for anything beyond manipulating page UI, and this remains the case for the overwhelming majority of the "billions" of devices with JS execution environments. It is still harder to configure Node.js for use on a server than something like PHP. When I say an "important development platform", I mean that from the perspective of practical use of the technologist, in the sense that the platform is can be expected to host projects that are recognized as clear leaders within a generally applicable space, strongly motivating adoption of the underlying development platform if not already adopted.

nfriedly 9y ago

Agreed. Until recently, my team was responsible for most of the official IBM Watson service demos, and we standardized on React for those and built up a nice library of react components[1]. None of them used Redux, though, because in general it just wasn't needed. When we handed off responsibility of these demos to the individual service teams, we wrote up guidelines that specifically recommended React but not Redux - with the logic that if the demo is getting to a point where Redux is providing value, then it's probably too complex for a demo. Our new project is a more involved web app that includes lots of state, shared across many different components, and we're making great use of Redux there. [1]: https://watson-developer-cloud.github.io/react-components/ https://watson-developer-cloud.github.io/react-components/

matsemann 9y ago
One of the things I find hardest with redux is to make reusable components (across projects), as they have to be added to the state tree somewhere, and then connected. With nested components you may get implicit dependencies on where in the tree it should be. All this makes it very cumbersome. So even though most of our apps use Redux, the reusable parts use setState as they then can be completely independent.
- acemarke 9y ago
  Yeah, that is a tradeoff - globalized state makes a lot of scenarios easier, but does make complete encapsulation and reusability harder. Most of the third-party "Redux-connected component" libs I've seen provide a reducer that they expect to be added to the root of the state tree under a specific key name. Works, but it's not ideal. I've seen a few that let you provide a selector or key name when you initialize the library, so that the library is more flexible in how it's connected. There's been a lot of discussion of various approaches for implementing fully encapsulated/reusable Redux-based React components in Sebastian Lorber's "Scalable Frontend with Elm or Redux" repo [0], and my links list has a section of additional articles on the topic of encapsulation with Redux [1]. My Redux addons catalog also has a large section for libraries that implement some form of per-component state or component encapsulation in Redux as well [2]. So, it's not impossible, but it does take work and there are tradeoffs either way. [0] https://github.com/slorber/scalable-frontend-with-elm-or-redux https://github.com/slorber/scalable-frontend-with-elm-or-red... [1] https://github.com/markerikson/react-redux-links/blob/master/redux-architecture.md#encapsulation-and-reusability https://github.com/markerikson/react-redux-links/blob/master... [2] https://github.com/markerikson/redux-ecosystem-links/blob/master/component-state.md https://github.com/markerikson/redux-ecosystem-links/blob/ma...
- nfriedly 9y ago
  Yea, our new project has a lot of 'container components' where there is a parent component that connects to redux (and react-i18next) gets all of the data & translated text, and then passes it to a child component that is just a regular stateless component that could be easily re-used (and tested!)
FLGMwt 9y ago
These look great! Thanks for sharing. Also, I like the idea of loosely enforcing against a state management library to cap demo sizes.

_greim_ 9y ago

> annoying I like React's ethos of avoiding complexity until you need it, but these smug attitudes are starting to get really tiresome.

scaryclam 9y ago
I'm not sure I'd characterise the attitude of avoiding additional dependancies until you know you really need them as smug...
- always_good 9y ago
  The smugness is when you classify a bunch of other people as annoying as if they are incapable of making their own technical trade-offs. "Wake up, sheeple!" I use Redux on just about every React project because none of my projects are toy projects. And I'm not just doing it to annoy OP.

cookiecaper 9y ago

This summarizes everything about the JavaScript ecosystem, so it shouldn't really surprise React users that there is no logic behind the community's behavior. People have finally succeeded in making JavaScript an important development platform by sheer force of will, insisting that JavaScript must become important in order to justify their adoption of the fad. Before this critical mass was attained, there was no real reason to use JS whenever the option was available, and virtually everyone who adopted Node.js and friends was doing it "just to [do] it", in service to the fad kicked off by Google's promotion of Chrome/V8. Consider that prior to V8, JavaScript was so disliked that the only way to get someone to read a book about it was to name it "JavaScript: The Good Parts". The coder would be surprised to hear that anyone thought JavaScript had any good parts, and would want to figure out what they were, so that his/her days spent in client-side hell would go just a little smoother. Then Google released Chrome with V8, some people thought this meant JavaScript was cool now, and it's snowballed from there.

asherwebb 9y ago
Javascript is important because it runs on billions of devices - more devices can process javascript than any other language. Being the most used programming language in the world makes it an important development platform by default.
- cookiecaper 9y ago
  While it may be true that JavaScript has had a large installed base for many years, that installed environment was only capable of operating within the context of a single page load, as long as the browser was open and active, and really was only useful for manipulating the DOM (and JavaScript was a sorry platform even within that ultra-narrow scope). Node.js changed things by making the platform available on the backend, allowing programs to live longer, but the notion that JS was "important" as a general development solution is incorrect. It certainly was not the "native" or obvious solution for anything beyond manipulating page UI, and this remains the case for the overwhelming majority of the "billions" of devices with JS execution environments. It is still harder to configure Node.js for use on a server than something like PHP. When I say an "important development platform", I mean that from the perspective of practical use of the technologist, in the sense that the platform is can be expected to host projects that are recognized as clear leaders within a generally applicable space, strongly motivating adoption of the underlying development platform if not already adopted.