Discussion on: The not so secret life of Provider in Redux

[Mark Erikson]

Kudos on digging into the source code! I think more people should do that - it's a great way to learn about what libraries and tools are doing.

Looking at your post, I do think the connect example is over-simplified, and the ...this.store part especially is misleading. Dan Abramov wrote a miniature version of connect here. Here's the equivalent part from that example:

    return class extends React.Component {
      render() {
        return (
          // that renders your component
          <WrappedComponent
            {/* with its props  */}
            {...this.props}
            {/* and additional props calculated from Redux store */}
            {...mapStateToProps(store.getState(), this.props)}
            {...mapDispatchToProps(store.dispatch, this.props)}
          />
        )
}

Also, it's very possible that in an upcoming version of React-Redux, the Provider component will be very different. I'm currently researching how to use the new React context API inside of React-Redux, and have an open pull request with an early proof of concept. That PR actually switches from having individual connected components subscribe to the store, to having Provider subscribe instead. I'm hoping to do more experimentation with this in the near future.

[Sadick]

Thanks for pointing that out. The thing i see missing is the call to getState. I was only trying to show how the store is accessed.

[Mark Erikson]

Yeah, that was my point - there's a big difference between passing ...store as props, and passing ...mapState(store.getState()) as props :)

Although, now that I re-read that last example carefully, you've got: this.store = context.store.getState(), which is kinda mis-named in a different way than I thought.

Anyway, if you enjoyed that look inside, you might be interested in reading some of these other articles explaining how Redux and React-Redux work .

[Sadick]

Thanks I now see your point.