Discussion: React-Redux and React async rendering

[markerikson]

I'll open this up as a general forum for discussing anything related to how React-Redux is going to interact with React's new "Suspense" async rendering capability and time-slicing behavior.

At the moment, we don't really have a good idea of what that means for React-Redux. We're going to need a better understanding of how React's async rendering behavior works, how this suggested "caching" concept fits into things, and what the final React APIs are going to look like.

[lmatteis]

The general React API will change for suspense, but the main concept I believe is that this.deferSetState({ foo: 'bar' }) will try to render as much as the tree as possible, but only flush the actual changes when all the thrown promises in the tree have completed (movieFetcher.read() throws a promise). The actual update could occur after several seconds if the promises are HTTP requests.

If you call deferSetState again, the old tree is discarded to avoid race-conditions.

There are other bells and whistles, like Placeholder and Loading which allow to have finer-grained access to this process, but this is the overall idea I believe.

In the demo the fetchers seem to use a cache. Throwing an HTTP promise in the render is akin to "start this HTTP operation and re-render me when there's a response", so the cache seems to exist for the render to understand when the response arrived -- when to throw and when to render.

It's unclear how this can be used with Redux, and we should probably keep an eye on this PR #856

From a high-level, the cache that render's use to understand whether they need to start an async operation could very well be a redux store.

I imagine redux should be notified about when such async operations occur:

function MovieDetailPage({ movieId }) {
  const movie = movieDetailFetcher.read(movieId) // throws a promise
  ...

Instead, the connect HOC could pass to the component the actual fetcher so it knows about the promise:

function MovieDetailPage({ movieId, movieDetailFetcher }) {
  const movie = movieDetailFetcher.read(movieId) // throws a promise, and let's redux know about it
  ...

Just my two cents.

[timdorr]

You can throw a Promise both from render and from getDerivedStateFromProps. The latter looks like it has potential. But it would require us handling side effects explicitly. That's normally done in the middleware, so it's just a matter of this library providing its own "middleware" of sorts and expecting a particular return from middleware (this would be new).

Here's what I'm thinking: We would wrap the store.dispatch in a function that checks for a Promise return. If it gets one, we store it, fire a setState to trigger an update, and during the render we would throw that promise to React. When it resolves, we would get a re-render from React and should pass through with the resolved state.

The fun part is the specific timing of things with the React render cycle and the store subscription cycle. I think we just need to try it and see what happens.

It would also require middleware spit out that Promise, so we'd need ecosystem coordination. But I think that's do-able and we can provide some helpers for the common cases (wrap function returns from thunks, some sort of saga coordinator, etc).

[markerikson]

One potential issue there is that I know a lot of people are depending on being able to do this.props.someThunkReturningAPromise().then( () => {} ) inside a connected component.

Another big aspect that's not clear yet is this whole "cache" thing. How are components expecting to access a cache? What does the caching API look like? How could this potentially map to data in a Redux store?

[markerikson]

There's a bunch of relevant WIP info from Brian Vaughn about async rendering and subscriptions:

• React docs PR #596: An update on async rendering
  • Blog post preview
  • Gist: Advanced example for eagerly prefetching data in a component
  • Gist : Example for loading new external data in response to updated props
  • Gist: Advanced example for manually updating subscriptions in response to props changes in an async-safe way
• React PR #12325: WIP create-component-with-subscriptions
  • Gist: create-subscriber-component proof of concept

Also relevant:

• React PR #12279: WIP - Suspense
  • react-reconciler/tests/ReactSuspense-test.js

[timdorr]

That would pass through the dispatch wrapper. And in async mode, they'll be able to throw that promise too:

render() {
  if (!this.props.users) {
    throw this.props.loadUsers().then(this.handleLoadedUsers)
  }

  return this.renderUsers(this.props.users)
}

Of course, what are you seeing people do within that .then? If it's a loading state, that's handled entirely different by Suspense. So, there's some refactoring needed on the user side too.

[markerikson]

Don't have specific examples to point to atm, but it's usually triggering more fetches, dispatching actions, or setting component state.

[aweary]

You can throw a Promise both from render and from getDerivedStateFromProps

You can also throw a Promise inside state updater functions!

[timdorr]

You can also throw a Promise inside state updater functions!

Oh, that's a good one too!

[gaearon]

I want to warn against coming up with something complicated. Our goal is to make React Redux work roughly the way it was conceived three years ago. Not put another super complicated system like we have now on top.

[markerikson]

Dan, I know that's what you and Andrew have said you want. I'm not sure that's what Tim, Jim, and I want. We don't yet have a full enough understanding of the situation to say that's the right approach.

One point of concern: React-Redux is currently usable with React alternatives like preact-compat and inferno-compat. What happens if we rewrite all of React-Redux's internals in terms of React 16.x-only behavior?

[gaearon]

My tentative understanding is we want to move state handling in React and use setState updater form + context for it. Some follow up questions that I don’t know answers to:

Who Owns the State?

If React owns the state (which is what we need for time slicing and suspense) then createStore doesn’t make sense. Which might be fine. I imagine top-level Provider could give you an imperative store-like object with a compatible API (just like a ref).

For example, instead of this:

let store = createStore(reducer);
ReactDOM.render(
  <Provider store={store}>
    <App />
  </Provider>,
  node
);

store.dispatch(stuff());

you might have:

let storeRef = React.createRef();
ReactDOM.render(
  <Provider storeRef={storeRef}>
    <App />
  </Provider>,
  node,
  () => {
    let store = storeRef.value;
    store.dispatch(stuff());
  }
);

From user’s point of view it doesn’t matter where store is coming from since it has the same API.

How Are Priorities Handled?

Redux store has getState() (and middleware calls it). It’s not clear to me how this should work with deferred updates that haven’t finished yet. I haven’t really thought about this yet.

[gaearon]

One point of concern: React-Redux is currently usable with React alternatives like preact-compat and inferno-compat. What happens if we rewrite all of React-Redux's internals in terms of React 16.x-only behavior?

I understand if that’s important to you, but supporting this was never the goal of these bindings when we were creating them. I don’t think it makes a lot of sense to support the common denominator forever because:

• These packages have already chosen to fork the ecosystem (inferno, preact)
• This doesn’t let React move forward.

React Redux has a peer dependency on React, not Preact or Inferno. That expresses its contract. Of course we should avoid breaking people who rely on this in minors, but I don’t see supporting them forever as a viable strategy for this package.

[markerikson]

One problem with "the store lives purely inside of a <Provider>" is that people are doing lots of stuff with the store outside of the React component tree. Store setup, passing the store to persistence utilities, running tests, etc.

This doesn’t let React move forward.

Yes, but as maintainers of a package that is used by more than just React users, we've got to take the ecosystem as a whole into consideration.

It may be that the final approach is to maintain 5.x as the designated "backwards compatible" line, and 6.x onwards is the "React future-only" line. That's something we can discuss. But, my goal would be to find a way to minimize total API churn and compatibility issues for all of our users, even if that means that we have to do some complex bookkeeping internal to the library.

[gaearon]

One problem with "the store lives purely inside of a " is that people are doing lots of stuff with the store outside of the React component tree. Store setup, passing the store to persistence utilities, running tests, etc.

I agree, and we need to find a solution for these use cases. I’m sure one exists. For cases where you only need the store after rendering, my ref API above should work just fine. For other cases, we can come up with something similar.

I think the mistake here would be to spend a lot of energy on not addressing this, and instead jumping to our regular “let’s completely work around React” way of thinking.

[lmatteis]

My concern is also: can we get the same predictability with suspense? Will dispatching N actions always bring you to the same state?