Decision to remove the @provide decorator? about react-redux HOT 2 CLOSED

It's not really about “keep decorators” or “keep components”.
It's about “which does a better job in which case”.

connect()

connect() makes more sense as higher order component because:

1. You never need to change the selecting function mid-flight. We couldn't do some perf optimizations with <Connector> because it had to correctly handle changing select prop although there was no valid use for this.
2. Function-as-a-child default case has performance downsides because people often write it as a lambda so they're allocating functions every time render is called.
3. We have no way to restrict shouldComponentUpdate outside Connector but that would be really useful to make connected components faster.
4. <Connector> forced you to write “semi-smart” components that knew about Redux but couldn't, for example, handle its state changes in componentWillReceiveProps because they just used <Connector> inside without access to its state.
5. Even if you didn't want an intermediate component you had to write it anyway. Now you can connect() your dumb component and get the smart component right away, without writing another class in between.

It was a poor choice of abstraction and added unnecessary layers and clumsiness. We got rid of it.

<Provider>

<Provider> makes more sense as a normal component.

1. Unlike with connect(), it actually does make sense to change the parameters (store in this case) at runtime. For server rendering, we want to pass a new store for every request. Offering it to specify as a singleton at the top makes server rendering non-obvious. Making it a prop points you to the right direction.
2. It was a shortcut for shortcut's sake, it didn't bring any valuable opportunities.
3. It didn't work well with React Router.
4. It didn't work with Redux DevTools.
5. It made stubbing store for tests more complicated.
6. In React 0.14, we'll be able to further simplify <Provider>{() => <App />}</Provider> to <Provider><App /></Provider>. At this point it's hard to justify @provider even as a shortcut.

Good riddance.

from react-redux.

Spectacular answer. As usual, thanks for being so thorough.

from react-redux.