connect could be used with a custom store.subscribe method provided as option

[slorber]

Context

Today there was some discussions about the new redux tree view example and this SO question:
http://stackoverflow.com/questions/34981924/performance-issues-with-a-tree-structure-and-shouldcomponentupdate-in-react-re

As I pointed out the solution of Redux examples is fine enough for most usecases but does not scale it the number of nodes is very big. We agree that it's not a good idea in the first place to render a huge list or a huge tree, but it seems the author of the question is still interested in a solution. I don't know if the usecase is valid or an antipattern but I guess it's worth giving the opportunity to render a huge number of items in an efficient way

Solution

As described in my answer if the number of connected items grows too big, then every state change triggers all connected HOC's subscriptions so it does not scale well.

If we want to make it scale better, the HOC subscriptions should only be called when necessary.

If the state slice of node with id=1 is updated, it produces overhead to actually trigger the subscription of the HOC that connects data to node with id=2, because obviously the connected component is not interested at all in this change.

Redux store has a store.subscribe(listener) method, and it is called inside connect

One can easily create a store enhancer that exposes a method like store.subscribeNode(nodeId,listener), which is only triggered when that node, with the provided, id is called. There are multiple ways of triggering this listener efficiently.

The problem is that once we have built this custom optimized subscription system, there's no way to reuse connect to listen to it because the call to store.subscribe is hardcoded here:

    trySubscribe() {
        if (shouldSubscribe && !this.unsubscribe) {
          this.unsubscribe = this.store.subscribe(::this.handleChange)
          this.handleChange()
        }
      }

A flexible solution would be to let the user control hw to subscribe to the store himself, by using connect options for example:

const mapStateToProps = (state,props) => {node: selectNodeById(state,props.nodeId)}

const connectOptions = {
   doSubscribe: (store,props) => store.subscribeNode(props.nodeId)
}

connect(mapStateToProps, undefined,connectOptions)(ComponentToConnect)

The default doSubscribe implementation would be: doSubscribe: (store,props) => store.subscribe() which keeps the current behavior unchanged.

There's one corner case I don't know yet how to solve is when the nodeId props changes over time. It would mean the HOC should then unsubscribe and then resubscribe for the new nodeId. In practice this seems farfetched to do so and I'm not sure it's really worth trying to solve this but if anyone has an idea...

I can make a PR for that, just tell me if it would be accepted or if it seems to much indirection and is not an usecase you want to support in redux.

[slorber]

Let's also consider redux-batched-subscribe of @tappleby

It exposes 2 methods:

• store.subscribe is batched (because it's wrapped)
• store.subscribeImmediate is not batched

If you use this store enhancer in your project, then all your connect HOC's become batched by default. This proposal would permit the user to connect components in both batched and immediate mode. I don't really have a real usecase for this but maybe it could permit to give some control over the priority the components should render themselves.

[gaearon]

If props was an argument we'd have to resubscribe on every componentWillReceiveProps for consistency which would give bad perf.

[slorber]

That's right but I guess it's a very specific corner case as most of us would probably never want to update the subscription without unmounting/remounting.

There's still a solution to this problem:

const mapStateToProps = (state,props) => {node: selectNodeById(state,props.nodeId)}

const connectOptions = {
   doSubscribePropsSelector: props => props.nodeId,
   doSubscribe: (store,nodeId) => store.subscribeNode(nodeId)
}

connect(mapStateToProps, undefined,connectOptions)(ComponentToConnect)

If we use a selector to pick the data we need for the subscription, it gives the opportunity to componentWillReceiveProps to unsubscribe/resubscribe with the new nodeId only when it changes.

However the API becomes harder to use...

[gaearon]

There are some other extension points people desire:

• Add optional handleChange param get data from listeners for profiling #194
• Return a promise from handleChange #208

I wonder if there is a way to address these together without complicating the API. This might mean extracting the “core” of connect into an independent low-level function but I'm not sure about the API.

[gaearon]

Basically, what if we separated the component in connect from the caching and invalidation logic.

[slorber]

@gaearon a usecase for #208 would be to build a React.Perf middleware so that we can take measures for every dispatched action.

If subscription returned a promise resolved on setState callback, then the redux Middleware could be able to know when rendering has ended and measure wasted time that is relative to a given action.
See also this issue that can make it more complicated to build: facebook/react#3611

There's already a not-really advanced middleware that does not take account that renderings can happen in an async way: https://github.com/AvraamMavridis/redux-perf-middleware

---

Also for my initial custom connect proposal I think another usecase is when we want to bind dom inputs to redux state. It might work well with events on a small app but I guess once the app becomes big, on a mobile device typing in an input triggering hundreds of HOC may be a problem?

---

@gaearon yes that would be great to provide full flexibility so that we can compose code in the way we want to use it without rewritting/forking the lib.

Also it can be nice to have an experimental API so that you can eventually change your mind later.

I don't have an API in mind I'll have to digg deeper in the implementation details of connect :)

[mhodgson]

@gaearon @slorber I have a PR that attempts to address this here: #285. Would be interested in your thoughts. Not ready to merge, but want to know if it is directionally interesting.

[slorber]

@gaearon also it seems there is a community need to run multiple redux stores (reduxjs/redux#1385)

It could be nice if we could also pass to the provider a map of stores and if the connect method was flexible enough to permit to select the appropriate store from context