[acemarke]

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.)

[andrewstuart]

"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]

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-ta...

[1] https://github.com/reactjs/redux/issues/2295

[2] https://github.com/markerikson/redux-starter-kit

[andrewstuart]

For me it is specifically this.

Here is a class:

  import React from 'react'
  
  export default class class ChooseFontLevel1 extends React.Component {
  
    constructor(props) {
      super(props)
    }
  
    render = () => <span>foo</span>
  }

And here is the (almost) same class, with the boilerplate required to use Redux:

  import React from 'react'
  import {connect} from 'react-redux'
  
  class ChooseFontLevel1 extends React.Component {
  
    constructor(props) {
      super(props)
    }
  
    render = () => <span>foo</span>
  }
  
  
  function mapStateToProps(store, ownProps) {
  
    return {
      fontPreviewsCache: get(store, `fontPreviewsCache`),
    }
  }
  
  function mapDispatchToProps(dispatch) {
    return {
      onTodoClick: id => {
        dispatch(toggleTodo(id))
      }
    }
  }
  
  export default connect(mapStateToProps, mapDispatchToProps)(ChooseFontLevel1)

To use Redux I need to entirely restructure my code.

And if the comment is "You don't need all that stuff", then why is it an option at all?

Also mapStateToProps is poorly named and confusing because it isn't talking about anything to do with ReactJS component state, although it's a reasonable assumption, it's talking about the Redux state... there's a bag of confusion for you and enough to make a beginners head spin because their head was already spinning about what ReactJS state is.

I'd also suggest that Redux has made a rod for its own back by calling "the thing that gets data out" as "reducers", instead of something like "getters". "Reducers".... argh we're now in computer science land and not the land of the practical programmer. A reducer, what is that? Beginners certainly don't know and you have to learn and become experienced with Redux to come to understand that in fact a Reducer is

Equally, cognitive load would have been reduced if actions were named "setters" or something familiar and similar to the actual functionality.

Redux itself isn't that hard once you understand it, but it's put up big cognitive barriers around itself so that you need to be an expert to eventually discover that you don;t need to be an expert.

[acemarke]

Well, the `mapDispatch` example can certainly be simplified. `connect` supports an "object shorthand" - just pass an object full of action creators as the second argument, and they'll all be bound up and passed in as props. So, your `mapDispatch` example can just be:

    const actions = {onTodoClick : toggleTodo};

    export default connect(mapState, actions)(ChooseFontLevel1);

Other than that... there's 1 import line for `connect`, 1 function call to `connect`, and the `mapState` function.

Is that truly too much to write? Also, how does that qualify as "entirely restructuring your code"? Your component is still the same - it's getting data as props. It's just now getting them from a component that was generated by `connect`.

The alternative is to write the store subscription code yourself, by hand, in every component that needs to access the store. I've got some slides at https://blog.isquaredsoftware.com/presentations/workshops/re... that show what that would look like, and THAT would truly become tedious and painful.

The point of `connect` is to abstract out the process of subscribing to the store, extracting the data your component needs, and only re-rendering your real component when that data changes.

As for the naming of `mapState`: the word "state", in general, means "data that represents what's going on in my application". So, there's the generic aspect of "state", there's "state that is being stored in my React component", and there's "state that is being kept inside my Redux store". Those are all valid uses of the word "state" (and especially given that the Redux core is entirely independent of React).

The term "action" comes from its original design as an implementation of the Flux architecture (which is part of my point of people not being familiar with where it came from). "Reducers" comes from the `someArray.reduce()` method.

(Also, note that in both of your examples, the constructor isn't actually needed because you're not doing anything meaningful in there, and your `mapState` example isn't making use of the `ownProps` argument and therefore shouldn't declare it for performance reasons.)

[andrewstuart]

Easy for you (and me to some extent) to read what you say and see hey yes it could be more simple....

What is simple for any Redux-experienced person is a gigantic cognitive cliff for people who are not experts. I can still remember trying to learn ReactJS and Redux and bailing out on Redux while I tried to make sense of mapping dispatch to props. Redux should not be losing users at that point.

Your earlier post expressed frustration at not being able to get people to be specific about what boilerplate is.... well this is it (or my definition anyway).

IMO, ideally Redux would be nothing more than an object that I instantiate and then call methods and properties on - including defining my reducers and actions. A single object for Redux leaves the question of how to ensure that changes to the Redux store result in a props refresh being pushed down through the component hierarchy, but surely the big brains on the ReactJS project can come up with some other way to handle that behind the scenes rather than me needing to change my code structure.

And may I say I love your work and I'm a big fan of Redux!

Although if I found something that operated like I say - a single object to be instantiated and driven via methods and properties with total immutability, with changes resulting in a props refresh on update, then I'd switch.

[acemarke]

Unfortunately, the library you describe wouldn't be Redux at all. Part of the core point of Redux is to separate out the act of describing some event or update that needs to occur, from the process of applying that update. That's what makes time-travel debugging possible, and it allows middleware to modify the actions that are passing through the store. In all honesty, if you want objects with methods, MobX is what you're looking for.

Not quite sure what that "single object" sentence is trying to say, but that also sorta sounds like MobX's wrapping up of components with `observe()` (which ultimately does the same kind of thing `connect` is doing, just in a rather different way).

(Also, fwiw, Redux is completely separate from the React team. Dan Abramov and Andrew Clark, the creators of Redux, _do_ work on React at Facebook now, but Redux is not a Facebook project, and Dan and Andrew are no longer active maintainers. We talk with them a lot, and they obviously have a vested interest in Redux, but it's separate.)

And thanks, appreciate the compliment.

[ascorbic]

> Redux is magnificent, but it should take a lesson from create-react-app

...which is ironic, considering the fact that Dan Abramov (co-)created them both.

[msoad]

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]

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

[1] https://github.com/markerikson/redux-ecosystem-links/blob/ma...

[2] https://github.com/TheComfyChair/redux-scc , https://github.com/Bloomca/redux-tiles

[3] https://redux.js.org/recipes/structuring-reducers/immutable-...

[4] https://github.com/markerikson/redux-ecosystem-links/blob/ma...

[5] https://github.com/mweststrate/immer

[6] https://github.com/keajs/kea , https://github.com/rematch/rematch