Feature Request: Global didUpdate()

[ccorcos]

Currently, its not easy to write global logic that executes after React has re-rendered. The componentDidUpdate lifecycle method works great when your logic is isolated to a component, but I've found myself more and more recently wanting a global didUpdate hook baked into React.

A simple example where this is useful is if you want an isolated function (perhaps a keyboard shortcut) that creates an element on the screen and then focuses it.

const createNewTodo = async () => {
  const id = createTodo()
  await React.didUpdate()
  focusTodoItem(id)
}

At Notion, we've written custom logic for doing this, but it makes upgrading with React more difficult and unstable. I think this would be useful for others too, particularly those who use Redux and are building complicated UI interactions.

[aweary]

@ccorcos there is work being done on a top-level API for managing the render and commit phases. Check out this demo and explanation by @acdlite to get an idea of where things might be headed.

[gaearon]

Notion is pretty cool btw. Say hi to Surganov. :-)

[acdlite]

Interesting use case. Suggests that Redux is missing this feature, too. Something like dispatch(action, callback). Or a didUpdate argument to createStore.

[acdlite]

I think the thing the only reason you would need a global didUpdate is if focusTodoItem triggers many separate updates on many components, because you don't know which component to schedule the callback on. This happens to be how Redux works today; it calls setState on every connected component. But that's mostly an implementation detail. Conceptually, a dispatch is a single, atomic update, as if you were to call setState on the Provider, and the rest of the changes were propagated via context. (The only reason we don't do that is because context, uh, kinda sucks as-is :D). In this model, the didUpdate hook you're asking for would just be a setState callback on the Provider. Redux could expose it like dispatch(action, callback).

The reason you want the callback to scheduled per action is that, in the future, once we move to async, different actions may be scheduled with different priorities. So callbacks may fire at different times depending on the priority.

[acdlite]

Slight tangent: I have this idealized, possible-future version of React Redux in my head where there is no "store" and all state is stored as component state inside the Provider. Something like this:

class Provider extends React.Component {
  state = { storeState: null };
  dispatch = (action, callback) => {
    this.setState(state => {
      const nextStoreState = reducer(state.storeState, action);
      return {storeState: nextStoreState};
    }, callback);
  });
  //  ...
}

This would allow React's scheduler to abort, reorder, and rebase Redux actions according to their priority, which isn't possible today.

Though of course we'd have to figure out what this means for middleware and enhancers. And maybe fix context (though that's not necessarily a blocker, as this would still work with pub sub like we do today eh maybe not, would be hard to do pub sub in an async-friendly way).

[markerikson]

Of course, then you don't really have "React-Redux" any more, you have "Redux in React" - which is not the same thing :)

[acdlite]

Don't you Redux-splain and React-splain at me, acemarke :)

[ccorcos]

Thanks guys!

@acdlite you touched on a few things there. The createNewTodo example I gave is the simplest possible example, but there are many more complicated examples that require this feature. Just looking through my application, we use it in 56 different places to do stuff like scroll things into view after they render, changing the user's selection after a user manipulation, focusing elements after they're dragged and dropped onscreen, clicking on elements after they're created, etc.

If I understand you correctly, what you were getting at is that the user's focus could be a state in redux and managed by the component itself. If you're living in Redux world, I can buy into that. But there are more complicated examples like clicking DOM elements and scrolling to elements after they appear that would be challenging to handle via state. These actions are one-off events and should probably live in the redux action.

Async renderering and reprioritizing is an interesting dilemma. There could be an API like didUpdate() which is called after the next render, and afterFlush() which is called when the render queue is empty.

[acdlite]

what you were getting at is that the user's focus could be a state in redux and managed by the component itself

No, that's not what I meant to suggest. The point of the callback is to fire right after the action has been flushed to the DOM, which is what the second parameter to setState provides: setState(update, callback). It's kind of like componentDidUpdate, but it only fires once that specific update has been rendered. Not on every render. This is important in a world where different updates have different priorities, because the next render might not include the update you just scheduled. By using the setState callback, you have a guarantee that the effect of the dispatched action has already been flushed to the DOM.

A future version of Redux could potentially expose this by adding a second argument to dispatch: dispatch(action, callback). Whether or not the focus state is stored in Redux isn't important.

[ccorcos]

Ahhh. I see what you mean. Right now, I'm just waiting for all the this.forceUpdate callbacks to complete (I'm using something similar to reactive-magic for state management). This means that the application might not be as responsive as it could but at least it works.

As far as implementing a granular callback with setState inside Redux, especially in a pure way, that sounds challenging because you don't know which components need to update until they begin to re-render...

I suppose that means the only way we can do this at a granular level is to implement our own render queues within the state management layer. But that doesn't mean we couldnt implement a global React.didUpdate that waits for all rendering to flush.

[acdlite]

you don't know which components need to update until they begin to re-render...

When you call dispatch, every component that needs to update in response should update in the same render pass. That isn’t always the case today, but that’s how it should work. And how we’ll need to make it work in the future so that Redux works with React’s async rendering.

A global didUpdate is pretty unlikely because it doesn’t scale. And besides, a setState callback on a root/Provider-type component, as described here, provides effectively the same thing.

[acdlite]

Want to make sure this part is clear: the only reason Redux triggers many setState calls for a single dispatch is to workaround the issue where context changes don’t propagate through a component whose shouldComponentUpdate returns false. That’s why each connected Redux component has its own subscriber to the store. But ideally, we’d only call setState on the Provider, and the connected components would update via context or some context-like mechanism. Regardless of how we implement it, you never want to have a situation where a single dispatch causes components to re-render at different times. That’s how you get “tearing,” or a momentarily inconsistent UI. It’s mostly not a big deal in today’s world because setState is synchronous (or part of a synchronous batch). So the tears aren’t noticeable. But in an async world, tearing is more of a problem, because it might be hundreds of milliseconds before an update is flushed, depending on what’s in the queue.

[markerikson]

Y'know, that's an excellent point - I hadn't connected those dots yet.

Tagging @jimbolla and @timdorr as an FYI.

[timdorr]

@acdlite Has any research been done into coordinating setStates via explicit batches, especially in an async React render cycle? You would get that implicitly with priorities, where the grouping occurs along the priority values. But I think that would be particularly helpful with coordinating sections of a UI to avoid the inconsistencies of async actions.

More concretely, I'm thinking something like this:

handleChange = event => this.batchedSetState(BATCH_ID, { foo: event.target.value })

That would group up units of work and only reconcile with the DOM after the VDOM has been fully-rendered for those components.

That would be a way to ensure sync-like behavior when connect() updates a component.

BTW, I saw some library recently that does what you describe as a future react-redux. I forget the name, but it's basically that. I'll try to find it again...

[markerikson]

Now I'm curious - if you've seen a lib, there's a good chance I've seen it, but nothing is immediately coming to mind.