Be able to return null from mapStateToProps

[gentlee]

I have isFocused prop (from react-navigation) that indicates if my component is currently visible.

When my component is not focused, I want to disable connection to redux. For example I have tab-bar and when I switch tabs I don't want to unmount component but I also don't want to run mapStateProps and to re-render component. Same for when I push component to stack navigation.

Currently:

The only way I guess is to pass option areMergedPropsEqual and return true if isFocused is false. But this still required calculation mapStateToProps and merging props, and just more complex and annoying to implement.

How it should be:

function mapStateToProps(state, ownProps) {
    if (!ownProps.isFocused) return null

    return {
        ....
    }
}

If mapStateToProps receives null it should stop updating component props and re-rendering.

Similar approach is used for React.Component.getDerivedStateFromProps.

[markerikson]

That doesn't sound like something we'd implement directly.

I think your best options here are either:

• Create your mapState using memoized selector functions, and consistently return the same memoized result object. mapState will still run, but it'll be fast and almost a no-op, and ensure there are no re-renders.
• Possibly using the "factory function" form of mapState, caching the last real return object, and conditionally returning it.

I was going to suggest using the areStatesEqual option for connect, but I don't think that has access to ownProps. We've had requests for that before (#781), but we've never chosen to implement that.

[gentlee]

@markerikson mapState will be cached but ownProps anyway are changed so the component will re-render, your approach won't work.

But even if it did, it is much simpler to return just null same as in getDerivedStateFromProps. Are there any good reasons why you don't want to implement it?

[gentlee]

@markerikson temporary disconnection from redux by specific prop looks like a really needed thing. With re-mapping state on re-connection.

Same as subscribing/unsubscribing or binding/unbinding in other observable approaches.

[markerikson]

This is the first I can ever remember anyone asking for "temporary disconnection".

Is your concern just a question of whether or not mapState runs and the component re-renders, as far as performance? Is there some other issue you're worried about here?

[gentlee]

In most web apps components are just unmounted when you leave the screen, so there is no problem.

Problem is mostly for react-native apps. They should be very fast - tab navigaiton screens and pushed to stack navigation screens shouldn't be unmounted. And actually everyone tries to fix that by some hacks because there is no good way to do it.

For example in react-navigation there is withNavigationFocus HOC that gives you isFocused and people use it like:

function shouldComponentUpdate() {
    return this.props.isFocused
}

But this doesn't remove connection to redux, and mapStateToProps keeps evaluating, and memoized selectors from mapStateToPropsCreator keep re-evaluating its values.

People try to find some hacks to disable it, but just don't understand that it is actually a responsibility of react-redux connect. You should be able to disconnect, very easily, without unmounting. And don't evaluate anything until you re-connect.

And when you reconnect, state again should be mapped and compared to last mapped state.

react-redux connect handles connection to redux and optimization of re-rendering, so it should handle this case too.

[timdorr]

That sounds like the same problem space as <TransitionGroup>. That's not something we need to handle explicitly. The container that's keep a connected component around an extra amount of time can just keep a reference to the leaving instance. Works just fine with any component, connected or otherwise.

[markerikson]

Been thinking about this a bit more.

As I already stated, this is a very rare use case. The number of times you would have a component still be mounted, and yet want to avoid even re-running mapState / re-rendering based on specific values, is not going to be very large.

What is your specific concern here? I assume it's performance-related. Are you seeing actual issues in production of some kind when this component is still mounted and updating in the background?

It's certainly potentially possible to implement behavior like this, but the question is whether there's enough benefit in doing so.

Adding a shouldComponentUpdate along these lines would be a potential option:

shouldComponentUpdate() {
    return this.props.isFocused;
}

That wouldn't prevent mapState from re-running, but it would keep the actual component from re-rendering when the props from connect do change.

[timdorr]

Also, note that unless the mSTP function depends on ownProps, it won't be called if just the props change. This side-stepping of mSTP is already built-in in that case.

[gentlee]

@markerikson Actually it is not a rare case for react-native apps at all, all of them use something like react-navigation and screens are not unmounted in tab bar or when you push new to the stack navigator. So all tabs, and their inner stacks are always mounted, connected to redux and js performance suffers a lot - js animations lag,lists are not rendered during fast scroll, button handlers work with delay, and the more screens mounted, the more js lags.

@timdorr It could be implemented for example with new option isConnected: (ownProps: OwnProps) => boolean, that is called when ownProps change. When false - connect unsubscribes from store, when changes to true it subscribes and re-evaluates mSTP etc.

Probably it would be also nice to have option like isDisabled: (ownProps: OwnProps) => boolean, that acts same as first one, but also stops all re-renderings.

Naming is discussable.

EDIT: or may be isConnected: (state, ownProps) => boolean