6 ms·

As a Redux maintainer, I'd be really interested to know what approaches they used, and what sorts of difficulties they had. (I'll throw out my obligatory comme

As a Redux maintainer, I'd be really interested to know what approaches they used, and what sorts of difficulties they had. (I'll throw out my obligatory comment that you are always welcome to use as much or as little abstraction as you want on top of Redux, and there's plenty of options available to trim down "boilerplate" depending on your situation.)

deleted 8y ago
[deleted]
msoad 8y ago
Those libs add some "magic" which is going against the point of Redux (knowing exactly what's going on). Instead of those abstraction libs I like to use the observable pattern with Rx or MobX
- acemarke 8y ago
  Depends on what your definition of "magic" is. For example, we specifically have a "Reducing Boilerplate" docs page [0] that talks about writing reusable logic for reducers and action creators, like "higher order reducers" or a `createReducer()` util that accepts a lookup table of action types to handler functions. There's many existing libs that implement this kind of pattern [1]. Beyond that, there's other libraries that provide a higher level of abstraction, like automatically generating logic to handle common use cases (normalizing data, updating certain fields, etc) [2]. Updating data immutably can become complex [3], so there's a lot of immutable update utility libraries out there [4]. I recommend Immer [5], which lets you write normal mutative code but then applies the updates immutably. Finally, there's frameworks built on top of Redux, like Kea and Rematch [6]. So, plenty of options available, depending on what you're comfortable with. [0] https://redux.js.org/recipes/reducing-boilerplate https://redux.js.org/recipes/reducing-boilerplate [1] https://github.com/markerikson/redux-ecosystem-links/blob/master/action-reducer-generators.md https://github.com/markerikson/redux-ecosystem-links/blob/ma... [2] https://github.com/TheComfyChair/redux-scc https://github.com/TheComfyChair/redux-scc , https://github.com/Bloomca/redux-tiles https://github.com/Bloomca/redux-tiles [3] https://redux.js.org/recipes/structuring-reducers/immutable-update-patterns https://redux.js.org/recipes/structuring-reducers/immutable-... [4] https://github.com/markerikson/redux-ecosystem-links/blob/master/immutable-data.md#immutable-update-utilities https://github.com/markerikson/redux-ecosystem-links/blob/ma... [5] https://github.com/mweststrate/immer https://github.com/mweststrate/immer [6] https://github.com/keajs/kea https://github.com/keajs/kea , https://github.com/rematch/rematch https://github.com/rematch/rematch
andrewstuart 8y ago
"Requires boilerplate" will forever be a criticism of Redux unless redux itself takes the (radical) decision to get rid of the boilerplate. Just saying "well you don't need to use it" means that Redux maintains all that crust and cruft of boilerplate which remains a huge cognitive impact not only on beginners but also possibly experienced Redux users. Redux is magnificent, but it should take a lesson from create-react-app which did the job of getting rid of all the crap that webpack and babel disastrously imposed on all JavaScript developers with their "maximum config" approach as opposed to zero config. The message to JavaScript library and tools developers is "get rid of your config or some other tool will come along and do it for you". Redux's boilerplate is just config. If you apply every brain cell you have to the task of getting rid of boilerplate, what would Redux be left with? That's what it should be. I think the success of VueJS can be laid squarely at the feet of the complexity of the ReactJS ecosystem - not even necessarily React itself. Every part of the larger React ecosystem needs to reduce the cognitive load it imposes and the primary task there is getting rid of configuration/boilerplate. My theory is that "all software that CAN BE more simple is replaced by some other good enough solution that IS more simple". Thus VueJS, which whilst I wouldn't use it, is certainly simpler for beginners to grasp.
- acemarke 8y ago
  Part of the issue is that _everyone_ has a different definition of what "boilerplate" means. So, legit question: what do _you_ mean by that term? Use of actions? Action creators? `connect()`? Immutable update logic in a reducer? Store setup? I honestly get frustrated that people keep throwing around that term, but few people seem to point to a specific _thing_ that can be improved. (People also don't seem to understand the context that Redux came from and the intent behind its original design, something that I tried to capture in an extended blog post a while back [0]). Early last year, I filed an issue asking for discussion of ways we can improve the learning / getting started experience, and resolve some of these "boilerplate" complaints [1]. There were a bunch of comments and some decent ideas, but I already have a lot on my plate, and no one from the community really stepped up to help push any of the ideas forward. I do have a small "redux-starter-kit" lib [2] prototype that I've put together as a tool that can help simplify the store setup process and reducer logic. Again, though, I haven't had time to do much more with it myself since I first threw it together. I am _always_ open to legit suggestions on ways we can improve the docs or find ways to make using Redux easier. Unfortunately, it seems like very few people are interested in actually getting in touch with us and offering assistance in doing so. [0] https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao-of-redux-part-1/ https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-ta... [1] https://github.com/reactjs/redux/issues/2295 https://github.com/reactjs/redux/issues/2295 [2] https://github.com/markerikson/redux-starter-kit https://github.com/markerikson/redux-starter-kit

deleted 8y ago

[deleted]

msoad 8y ago

Those libs add some "magic" which is going against the point of Redux (knowing exactly what's going on). Instead of those abstraction libs I like to use the observable pattern with Rx or MobX

acemarke 8y ago
Depends on what your definition of "magic" is. For example, we specifically have a "Reducing Boilerplate" docs page [0] that talks about writing reusable logic for reducers and action creators, like "higher order reducers" or a `createReducer()` util that accepts a lookup table of action types to handler functions. There's many existing libs that implement this kind of pattern [1]. Beyond that, there's other libraries that provide a higher level of abstraction, like automatically generating logic to handle common use cases (normalizing data, updating certain fields, etc) [2]. Updating data immutably can become complex [3], so there's a lot of immutable update utility libraries out there [4]. I recommend Immer [5], which lets you write normal mutative code but then applies the updates immutably. Finally, there's frameworks built on top of Redux, like Kea and Rematch [6]. So, plenty of options available, depending on what you're comfortable with. [0] https://redux.js.org/recipes/reducing-boilerplate https://redux.js.org/recipes/reducing-boilerplate [1] https://github.com/markerikson/redux-ecosystem-links/blob/master/action-reducer-generators.md https://github.com/markerikson/redux-ecosystem-links/blob/ma... [2] https://github.com/TheComfyChair/redux-scc https://github.com/TheComfyChair/redux-scc , https://github.com/Bloomca/redux-tiles https://github.com/Bloomca/redux-tiles [3] https://redux.js.org/recipes/structuring-reducers/immutable-update-patterns https://redux.js.org/recipes/structuring-reducers/immutable-... [4] https://github.com/markerikson/redux-ecosystem-links/blob/master/immutable-data.md#immutable-update-utilities https://github.com/markerikson/redux-ecosystem-links/blob/ma... [5] https://github.com/mweststrate/immer https://github.com/mweststrate/immer [6] https://github.com/keajs/kea https://github.com/keajs/kea , https://github.com/rematch/rematch https://github.com/rematch/rematch

andrewstuart 8y ago

"Requires boilerplate" will forever be a criticism of Redux unless redux itself takes the (radical) decision to get rid of the boilerplate. Just saying "well you don't need to use it" means that Redux maintains all that crust and cruft of boilerplate which remains a huge cognitive impact not only on beginners but also possibly experienced Redux users. Redux is magnificent, but it should take a lesson from create-react-app which did the job of getting rid of all the crap that webpack and babel disastrously imposed on all JavaScript developers with their "maximum config" approach as opposed to zero config. The message to JavaScript library and tools developers is "get rid of your config or some other tool will come along and do it for you". Redux's boilerplate is just config. If you apply every brain cell you have to the task of getting rid of boilerplate, what would Redux be left with? That's what it should be. I think the success of VueJS can be laid squarely at the feet of the complexity of the ReactJS ecosystem - not even necessarily React itself. Every part of the larger React ecosystem needs to reduce the cognitive load it imposes and the primary task there is getting rid of configuration/boilerplate. My theory is that "all software that CAN BE more simple is replaced by some other good enough solution that IS more simple". Thus VueJS, which whilst I wouldn't use it, is certainly simpler for beginners to grasp.

acemarke 8y ago
Part of the issue is that _everyone_ has a different definition of what "boilerplate" means. So, legit question: what do _you_ mean by that term? Use of actions? Action creators? `connect()`? Immutable update logic in a reducer? Store setup? I honestly get frustrated that people keep throwing around that term, but few people seem to point to a specific _thing_ that can be improved. (People also don't seem to understand the context that Redux came from and the intent behind its original design, something that I tried to capture in an extended blog post a while back [0]). Early last year, I filed an issue asking for discussion of ways we can improve the learning / getting started experience, and resolve some of these "boilerplate" complaints [1]. There were a bunch of comments and some decent ideas, but I already have a lot on my plate, and no one from the community really stepped up to help push any of the ideas forward. I do have a small "redux-starter-kit" lib [2] prototype that I've put together as a tool that can help simplify the store setup process and reducer logic. Again, though, I haven't had time to do much more with it myself since I first threw it together. I am _always_ open to legit suggestions on ways we can improve the docs or find ways to make using Redux easier. Unfortunately, it seems like very few people are interested in actually getting in touch with us and offering assistance in doing so. [0] https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao-of-redux-part-1/ https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-ta... [1] https://github.com/reactjs/redux/issues/2295 https://github.com/reactjs/redux/issues/2295 [2] https://github.com/markerikson/redux-starter-kit https://github.com/markerikson/redux-starter-kit