React Native at Airbnb

Have you tried Flutter? That's looking promising.

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 = () => foo
  }

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 = () => foo
  }
  
  
  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.

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

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.

It's not just a baby step. For lots of people who are doing more involved work than a thin, straightforward frontend for a server, there are things that are just worse or practically impossible to implement with React Native/JS alone, meaning you'll have to keep falling back on native code. A 100% RN app is simply not feasible for a lot of teams.