When refactoring from connect(mapState, mapDispatch) to useSelector / useDispatch, should you probably always React.memo() the resulting "connected" component?

[romellem]

As it says in the title, if you are refactoring old(er) code that uses connect from:

function mapStateToProps(state) {
  return {
    someState: getSomeState(state),
  };
}

const mapDispatchToProps = {
  someDispatch,
};

export default connect(mapStateToProps, mapDispatchToProps)(MyComponent);

To use the hooks API like:

export default function ConnectedMyComponent() {
  const someState = useSelector(getSomeState);
  const dispatch = useDispatch();
  const doSomething = () => dispatch(someActionCreation());

  // ...
}

Is it recommended to (in general) always wrap this resulting ConnectedMyComponent in React.memo() since that is one of the optimizations that connect was doing before in the original code?

react-redux/src/components/connect.tsx

Line 787 in 70ecef8

const _Connect = React.memo(ConnectFunction)

function ConnectedMyComponent() {
  const someState = useSelector(getSomeState);
  const dispatch = useDispatch();
  const doSomething = () => dispatch(someActionCreation());

  // ...
}

// ❓ Should this be a default recommendation?
export default React.memo(ConnectedMyComponent);

If so, is this something that'd make sense being added to the style guide, maybe under Priority B Rules: Strongly Recommended?

[phryneas]

No, since wrapping any React component in React.memo by default is just a bad practice at this point and might be more costly than just having it execute. The memo check is not free.

Use your best judgement on what makes sense at which point in your applications, no fixed rules of always or never doing something.

[romellem]

But I am not talking about "wrapping any React component," it is specifically when replacing old connect()'d components.

If it is bad practice, then why is connect() always doing that? It wasn't always this way, the change was made here. Is there another reason why the pure option was removed to always memo the resulting component in the HOC?

My reasoning was, if connect is (now) always doing this by default, then when "rolling your own" connect (in a way) by using the hooks, it probably makes sense to also do what connect was doing which is also using a React.memo call.

no fixed rules of always or never doing something.

I am asking something more subtle than "always or never." In this specific case, when replacing a connect'd component with a functional-hooks equivalent, then should you also probably memo that component since connect previously was doing that? This answer doesn't address the current status quo with connect, and that is what I'm struggling to understand.

[markerikson]

Memoizing everything is a thing you can do, and yes connect did that behavior by default.

Then again, the React ecosystem has changed over time in general (createClass > extends React.Component > function components), etc. So in that sense, just because there was existing behavior doesn't mean it always makes sense to continue doing the exact same thing.

In general, we advise first measuring and profiling your app to get a sense of the actual render update patterns, and then specifically memoizing certain components that are bottlenecks or re-rendering unnecessarily.

[romellem]

Sure, ecosystem changes definitely are an important piece of context. For example, React 19 + React Compiler also might change this advice.

So yeah, I get "don't prematurely optimize, measure the impacts" as a piece of advice, but obviously that requires more work. I think that given that connect() adheres to "memoize everything," if I was looking to create a style guide for my team as we convert old code to newer code, it doesn't seem totally wrong to say "probably always do this."

Additionally context for me specifically: the connect()'d components I'm referring to are "heavy." That is, we'd have a large ConnectedThing component that pulled in lots of state and bound dispatch actions (think like 20+ props) that'd then be prop drilled down to other components (this was a typically pattern years ago). We aren't necessarily looking to refactor the entire component tree, so as a first step, we are replacing those heavy "connected" with a functional equivalent so it can make use of other hooks that we want to start using.

If I was adding this to the docs, this seems like something that'd live in Priority C. There is a lot of nuance here, and ecosystem changes also may moot this advice, but for those that are on earlier version of React, it isn't necessarily a bad idea to heavily consider using memo() on "heavy" components that call useSelector and other react-redux hooks.

If that seems totally wrong, let me know, but again, given that connect() currently does this, this doesn't feel like terrible advice.

(Also, thanks for the replies on this. I appreciate the discussion! ❤️)

[markerikson]

Honestly there's nothing Redux-specific about this entire discussion :)

The question of "should we memoize everything?" has been debated in the React ecosystem for years. I've seen people argue both sides.

We don't give absolute rules here, because there aren't absolute rules here. It's your app, it's your team, and it's your codebase. We're not going to tell you to memoize everything, in the same way we don't try to tell you how to configure your Prettier formatting settings :)

[JuanGilArizon]

I saw many complaints about Redux hooks . In my opinion, there is only one reason I would not use useSelector: it makes the Redux logic more tightly coupled to the component.

[phryneas]

You can totally write the patterns that people wrote with connect:

function MyComponent(props) {}

export function MyConnectedComponent(props) {
  const x = useSelector(mySelector(props));
  return <MyComponent {...props} x={x} />;
}

// or even shorter
export const MyConnectedComponent = (props) => (
  <MyComponent {...props} x={useSelector(mySelector(props))} />
);

// would have been equal to
export const MyConnectedComponent = connect((props) => {
  x: mySelector(props);
})(MyComponent);

Nothing stops you from doing this pattern. Most people don't though, because they never liked it a lot from the start - it was just the best we had back then.

As for "tight coupling": All your Redux logic should be in your reducer and your selectors, both of which are defined outside your componen. That's really what makes tight coupling. It didn't matter if people write business logic that would belong into a reducer in useEffect or componentDidMount - it's the wrong place in both cases and has nothing to do with "hooks or no hooks".

[markerikson]

Also, there's nothing unique about React-Redux and useSelector in terms of "coupling".

There was a major React ecosystem shift from HOCs to hooks a few years ago, and that did change how developers are expected to write components today. All major data-fetching libraries provide hooks that you use directly in your component. This is a standard practice.

[JuanGilArizon]

I liked the HOCs but I see your points. @phryneas and @markerikson Thanks for your explanations.