Concurrent Mode

[futursolo]

What is concurrent mode?

Concurrent mode means that multiple copies of a component state can exist concurrently.

One copy of the component state is the current state that is displayed on the page (referred to as Current State below).
Zero, One or multiple other state copies can exist in the background (referred to as Background State below) if there are updates that can be applied non-urgently.

The renderer can create copies at anytime, discard any background state if it has conflicted with the current state and retry non-urgent updates.

Why do we need concurrent mode?

Concurrent mode solves a series of issues in a generalised approach and improves browser responsiveness during large state updates.

Some issues concurrent mode solves:

Suspend a component without showing fallback (suspension can happen in the background)

Currently, it's possible to show a loading unified fallback screen while any number of the child components is fetching data.
This allows the loading screen to be abstracted away from each request and the developer will only need to implement as many loading fallback as they see fit.

login-pre-concurrent.mov

navigate-pre-concurrent.mov

However, a better user experience would be to not show a fallback but an indicator:

login-post-concurrent.mov

navigate-post-concurrent.mov

This is challenging as once a component becomes suspended, it will stop producing any VNode layout and hence is unable to respond to any user input / updates. If we want to keep a component shown, it needs to be able to respond to user input.

Solution

Whilst we cannot suspend it here, we can suspend it in a parallel universe (suspend a background state).

Automatically throttle expensive computation (state / props updates can happen in the background)

If the developer implements a user action that involves expensive computation tasks, this may cause the page to become sluggish.

prime-pre-concurrent.mov

Solution

There's an important difference between:

• Doing less work but it has to complete on the spot
• Doing more work but it can happen in the background and the browser stays responsive.

It is important to optimise the performance of rendering functions, however, sometimes it is unavoidable to have expensive computation in the rendering function (especially during initial rendering). By classifying an update as a non-urgent update, the renderer will delay the rendering of components until a time that the browser is not busy and reveals when the rendering completes.

With concurrent mode, we can do this automatically by classifying the update as non-urgent. So it happens in the background with an old state still shown. If the value updates again before an update completes, we can simply discard any old work and start over again.

prime-post-concurrent.mov

Consistent Suspense Behaviour

The suspense currently have a couple inconsistent / unintentional behaviour.

These are not impossible to fix without concurrent mode but require manual fixing / patching for all of them one by one while it can be fixed by classifying suspense revealing as a non-urgent update in concurrent mode.

1. When a component itself is not suspended but still is hidden due to a sibling component is suspended and they are under the same Suspense. Its effects will still run. When a Suspense is currently fallback, none of its child components should run any effects until the suspense becomes revealed.
2. During hydration, context, props and state updates can cause the component to return a different VNode and hence fail the hydration process.
3. If the a suspension is making a suspense to show fallback and it reveals very quickly. This can cause the suspense fallback to “flash”. This is not good for user experience.

How it works

While each of the issues mentioned above looks vastly different, they can be solved together with concurrent mode.

With concurrent mode, the renderer classifies updates into 2 categories:

1. Urgent Updates
   Updates users expect to see immediately
   e.g.: When one enters some text into a text field, they would expect to see it immediately.
2. Non-urgent Update
   Updates users do not expect to see immediately.
   e.g.: Load a new page. It’s common to assume that there is some network latency between server and client.

Urgent Updates

When applying an urgent update, we need to update the page in blocking mode.
The browser will not be able to respond to any user input until a state update finishes.

Every pre-concurrent mode update is urgent.

Non-urgent Updates

When applying a non-urgent update, we apply this in a background copy of the component at a time the browser is not busy (e.g.: requestIdleCallback).
If there are multiple updates requested to be applied at the same time, we can apply them in small chunks so the browser stays responsive.



If in the meanwhile an urgent update happens, it will "rollback" instead of "commit".

The following steps are applied in the background:

• Non-urgent State Updates
• Non-urgent Props Updates
• Render (produce VNode)

The following steps are not performed until it becomes current:

• Render (reconcile with BNode)
• Effects

Limitations & Caveats

Function Components

Concurrent Mode is expected to work with most (all?) function components automatically.
As all function component states are Rc'ed as long as interior mutability is not used.

With concurrent mode, Interior Mutability should only be accessed at effects stage as effects are guaranteed to run on a current copy.

Struct Components

For struct components, concurrent mode will not work out of the box.
We can still force all struct component updates to be committed urgently so they work as if concurrent mode does not exist and add a way to manually "fork" and "merge" component states.

Interior Mutability

This is likely a permanent tradeoff. Interior Mutability is not directly usable as there's no good / straight forward way to produce a copy for interior mutable states.

Users can either:

1. Commit urgently.
2. Produce a Copy to be synced into Yew's state management.

External State Management

This is mostly related to Yewdux or Bounce where Yew cannot produce a copy for them automatically.

The situation is kind of complicated here as the state management libraries itself can have side effects (e.g.: persistent).
We need a way to notify state management libraries which copy is current and which states stored inside of it are mutated during a transition in order for side effects to be committed properly.

This can also be solved by committing urgently in the short term.

Footnote

Code used in examples: https://github.com/futursolo/concurrent-demos/

[hamza1311]

Thanks for the write-up. I like the idea of it. The examples you mentioned can be implemented with what we have right now. What improvements does concurrent mode bring over how the implementation of such examples would look like? From the react code of your login example, it seems it's this just abstracts over the tracking of busy status.
I'm not saying that is a bad/negligible thing, I'm just wondering if there's any other benefits it has to offer?

Also, WASM threads support is available in all major browsers (source: see "Threads and atomics" under the roadmap table). Can we leverage that in the implementation of concurrent mode? There are async runtimes for concurrency (such as smol) that we may be able to use.

[futursolo]

The examples you mentioned can be implemented with what we have right now.

Concurrent mode is not alchemy. Everything it does still is subject to the limitation of the Web API.
Just like all web applications can be implemented without using a framework, all concurrent mode features can also be implemented without actually implementing concurrent mode.

The difference lies in how much effort it would require to implement these patterns.

What improvements does concurrent mode bring over how the implementation of such examples would look like?
it seems it's this just abstracts over the tracking of busy status.
I'm just wondering if there's any other benefits it has to offer?

The login example is provided as a preface to help understanding concurrent mode patterns.
It demonstrates how to use a Suspense-like pattern to execute mutation-like requests.

Other examples are more connected with the unique ability of concurrent mode.

Let's breakdown what these examples do:

Page Navigation

https://github.com/futursolo/concurrent-demos/blob/master/src/examples/PageNavi.tsx#L171

Implemented with 6 extra lines of code.

Before Suspense, there are 2 ways to fetch data: Fetch-on-Render and Fetch-then-Render.

Fetch-on-Render refers to have data fetching triggered in a use_effect hook while a loading screen is shown.
You don't need any knowledge of what the next page is going to show as data fetching happens after the next is rendered.

Fetch-then-render is a pattern where the data fetching happens first and the page navigates when data is fetched.
Fetch-then-render usually leads to a better user experience as the current page stays active until the data of the next page is ready.
However, this pattern can be hard to manage, as data is fetched in a separate location than where it is used.
Next.js's getServerSideProps does a great job by (supposedly, whether user follows it is a different question) centralising all data fetching of a page into one location but it still requires declaring what the next page is going to show and can only work on page level. getServerSideProps is also opinionated where it requires the code to be structured in a certain way for it to work.

Suspense enables a third pattern named "Render-as-you-Fetch".
The data fetching process happens alongside the rendering process and the renderer can pause and fetch more data if it needs to. Before concurrent mode, this simulates the behaviour of Fetch-on-Render where a loading screen is shown.
Render-as-you-Fetch also does not require knowledge of what data to fetch for the next navigation.

If developers do not have time to carefully track what data to fetch for the next page navigation, they will have to sacrifice user experience and implement their application with Fetch-on-Render.

Concurrent mode enables an ability to implement the Fetch-then-Render behaviour with Render-as-you-Fetch pattern, where knowledge of what data to fetch for the next navigation is not needed for a navigation and can work at non-page level.
The renderer will try to update the state in a background copy, attempt render and resolve any suspension with the current page still shown. Once it is finished, the renderer will then reveal the next page.
If we warp it within yew-router, this will become completely transparent to users.

When the next page is rendering on the background, if the user clicks on another link, the renderer can detect a newer page navigation has been pushed and will abort the previous one. This is a very important ability and we will get back to this in the next example.

Find Prime

https://github.com/futursolo/concurrent-demos/blob/master/src/examples/FindPrime.tsx#L144

Implemented with 2 extra lines of code.

In this example, when the slider is mutated, it triggers (re-)rendering of thousands of components and it would take time longer than 1 browser frame which result the page to become unresponsive. The solution is usually to throttle the value change or dispatch the job into a different thread (Web Worker).

This is "possible" to implement it without concurrent mode.
However, doing so usually require more code to be written and does not achieve the same level of experience that useDeferredValue provides.

A couple ways of doing it:

1. Not updating until the value no longer changes after a certain period of time (like 0.3s).
2. Dispatch the work into a Web Worker.

Not updating until the value no longer changes after a certain period of time (like 0.3s).

If this strategy is selected, it will wait 0.3s before it actually starts updating, which will make the page to be more responsive as the value update will be blocked while the slider is sliding. However, once the value is updated, it will render until the end (thousands of components) and it is not interruptible. If the user tries to slide the slider while the render is happening, it will still become stuck until the render finishes.
This also takes a longer time until the result is reflected as it needs to wait 0.3s.

Dispatch the work into a Web Worker.

This actually executes the task in a different thread. However, as it is synchronous implementing cancellation of the task would be difficult. If no cancellation is implemented and the value changes again before the calculation completes, the user will end up with thousands of unneeded computation tasks running on their machine.

How useDeferredValue is different?

useDeferredValue is a way to throttle value change automatically. When the value is updated, the output value of the current copy will stay the same and the value is updated in the background. The updated copy will become current until the render finishes. This process is also interruptible if a new value is supplied, it will discard any pending work and retry with the new value.

It is also aware of whether the renderer is busy. When the rendering happens in the background, it happens in small chunks until it reaches a consistent state. If during this time an urgent render happens, it can also yield to urgent updates and comes back to it after the urgent update has finished.

Compare to other methods, useDeferredValue has the following advantage:

• updates can be committed as fast as possible as long as the renderer is not busy (no need to blindly delay for a certain time period).
• can cancel the task at anytime, automatically.
• does not block the rendering thread.

Can we leverage that in the implementation of concurrent mode?

Unlikely, at least not in the short term.
web-sys types are not-Send nor are they available in the web worker (which is the current purposed backend of wasm threads under browser). Concurrent mode runs the rendering function in the background as well and doing so will prevent components from accessing any web-sys type in the render function.

Concurrent mode is not about how fast it can render components but an ability of delaying render of component to a later time so the browser stays responsive.

Concurrent mode improvements is not very straightforward without using it (just like Suspense).
It is highly recommended to try out these examples and see how it would be applied in actual applications.

[WorldSEnder]

I find it hard to write down all my thoughts connected to this, so for now, just the questions I'm trying to answer and some sentences. Don't take it as my opinion on the feature itself:

Who decides which updates are "urgent", and how can a user control it?

It seems the answer is that yew decides which updates are urgent, which would just be asking for trouble, imo. Most convenient to implement, but also incredibly hard to use correctly for a user that wants precise control.

What's the central mechanism that makes it work?

My sketch of an answer revolves around a dom bundle that isn't mounted yet, and a way to get notified when that part of the dom is ready (finished first render). I do not yet believe that concurrent mode fixes the current quirks of suspense, rather I think a better low-level building block encoding what suspense is could do that and be reused to emulate concurrent mode in components that need it (all your examples).

Enabling CM for struct components is currently hard because, as far as I can tell, you have to clone the component and its connected state. That just screams inconsistent state to me. Rather, I'd only want to have a duplicate the dom tree and replace it when a new one is ready. Suspense alone is not powerful enough for that, but CM tries to be too high-level without explaining details.

[futursolo]

It seems the answer is that yew decides which updates are urgent, which would just be asking for trouble, imo.

Concurrent mode has already been tested for years before it is released in React 18.
This concept has significantly matured over the years and will continue to be polished in the future.
I do not think it's objective / wise to describe concurrent mode in such fashion especially without actually understanding what it does / how it works.

The renderer has a very specified set of actions that is designated as non-urgent by default (such as: Suspense revealing, Hydration of content within Suspense).

Most of time, users will designate what is non-urgent with useTransition and useDeferredValue.

I do not yet believe that concurrent mode fixes the current quirks of suspense, rather I think a better low-level building block encoding what suspense is could do that.

Like I mentioned above, it's not impossible to fix these Suspense behaviours without concurrent mode.
However, with concurrent mode, all it needs to do is to reuse abilities of other concurrent mode features.

• By marking the component state switched into background as non-current which prevents the effects from executing.
• By automatically executing the component in hydration against the initial state and delay any prop / state / context update until hydration completes.
• By marking Suspense revealing as non-urgent to minimise flickering.

be reused to emulate concurrent mode in components that need it (all your examples).

All of the examples require the component state to be cloned.
While the update happens in the background, the current copy component state still need to respond to user interactions until the background state has completely rendered.

That just screams inconsistent state to me.

This is not true.
The concurrent mode uses a similar strategy that databases use to execute transactions to commit state updates that happened in the background.

[WorldSEnder]

The renderer has a very specified set of actions that is designated

I did not find a complete list of this apparently rigidly fixed set, do you have a reference of events that are urgent?

Apparently state changes cause by a click handler are "urgent". But how far does that dependency carry? What if the click handler spawns an async action that causes a state change when it comes back? Is that change update still urgent and if yes, how would yew trace the dependency and if no, what if the user wants it to be?

[WorldSEnder]

I wonder if it were possible to give a similar API to struct components:

impl Context<COMP> {
    /// Start rendering `next`, which might suspend or otherwise take a long time to complete.
    /// When `next` is done rendering, replace the component associated to this context with `next`.
    /// Dropping the returned `Transition` cancels the transition if it is still pending.
    fn start_transition(&self, next: COMP) -> Transition;
}

Could be used like so and requires no implicit Clone bound:

struct PrimeList {
    max: usize,
    pending_next: Option<Transition>,
}
impl Component for PrimeList {
    // ...
    fn update(&self, ctx: &Context<Self>, msg: Self::Message) {
        match msg {
            Self::Message::ChangeMax(new_max) => self.pending_next = Some(
                ctx.start_transition(Self { max: new_max, pending_next: None })
            ),
        }
    }
}

[futursolo]

    fn start_transition(&self, next: COMP) -> Transition;

This method only allows to generate a copy of a single component but not other components.

When a transition starts, the transition function are free to do state.set and send messages to any component during a transition.
The renderer needs to generate a clone for all components that the transition function issues updates to / send messages to as the update function runs and can effectively commit / rollback all component updates during a transition.