Feature: Prioritized Transitions

[lxsmnsyc]

Currently, we only have batch and startTransition for performing sync and async update flush for SolidJS. In theory this is great however there are some times that we need to prioritize which updates should be flushed first.

This feature request is highly inspired by React's prioritized scheduler (and many other stuff) although I would like to tackle this in a simpler way.

Currently, Solid's scheduler has no priorities, but there's a deadline which can be useful in the following.

According to the RAIL model, there's 4 different kinds of processes that needs to be done within a certain amount of time: responses/events (<50ms), animation (<10ms), idle (probably infinite), load (<5s). In React, it's almost a bit similar (No, Immediate, User Blocking, Normal, Low and Idle) and with varying deadlines (Immediate = -1, User Blocking = 250, Normal = 500, Low = 10000, Idle = infinity). They use things like runWithPriority (an API that isn't publicly exposed) and other stuffs.

Internally (or in theory), React uses this to prioritize update flushes across boundaries, in which case they are abstracted from the user and just works with it internally. For example, React's useEffect may be, in theory, runs with Low priority while DOM events are wrapped in User Blocking priority (or may be even different based on the event type)

How does it helps Solid?
For starters, we can prioritize updates implicitly for the users. We can do this by wrapping Solid's APIs with priotizied transitions (e.g. createEffect may be Low or Idle, etc.). Prioritizing updates helps us flush updates that are actually needed in a given time frame while we can defer the rest of the updates that aren't really immediately needed. DOM events that require user input may benefit to this feature too.

[mindplay-dk]

One reason React might need this more than Solid, is because it's not as fast or as simple as Solid.

One thing that draws me to Solid is you don't need to plan or think about performance too much - whereas in React, I've seen lots of projects slowly slip into horrible performance, and developers wasting time and adding more complexity to fix performance problems with various optimizations.

I haven't used Solid on anything big yet, but my impression (also from knowing it's history and understanding some of the internals) is that Solid has much fewer problems of this type by design - it's quite possible there is much less of a need for performance tweaking for most users and projects.

This is not to say such as feature would be useless - if you can describe or demonstrate a use-case where this kind of performance tuning is necessary, I'd be very receptive. But my immediate impression is this sounds a bit like an imagined problem - and I wouldn't want to endorse an idea that gives developers more reason than necessary to get distracted by debating micro performance details for no practical reason.

Did you actually run into performance problems where this feature would help?

[lxsmnsyc]

This isn't about performance, this is about rolling out updates in a prioritized and controlled way. There has been some multiple discussions regarding this in the discord channel, but some of the ideas includes:

• batching updates in DOM events.
• scheduling updates in createEffect.
• Correct implementation for createDeferred.

and many other use cases that have been laid out in the RAIL model. This isn't about React btw, this is more of incorporating the RAIL model such that the users don't have to think of managing these miniscule updates themselves. The reason we might need this right now because currently, Solid naively flushes updates w/o priority and there have been many cases that it has been ideal/necessary. The only work around we have is explicitly using batch and startTransition although these things isn't something a beginning user may not understand correctly.

if you can describe or demonstrate a use-case where this kind of performance tuning is necessary, I'd be very receptive.

I have explained it in the fourth paragraph of the thread starter. Although to give you an example, the event processing frame must take place in no less than 50ms. There are updates that isn't necessarily needed to synchronously propagate within that given time frame (e.g. an autocomplete component that renders a suggestion list when input value changes) so it would be better to not only schedule an update, but schedule it in a timely manner.

[ryansolid]

I think the performance argument is commonly used here from the perspective that if you are performant enough all scheduling is unnecessary overhead since it's never going to be an issue anyway. Priorities don't matter if nothing ever is blocked in a meaningful way.

Which is what begs the question of what a real example looks like. I have to admit I have never seen one. Every example we do for this feels really artificial. I conceptually get what it solves but have never seen this actual problem, or if I have I've never seen something like this solve it. This is where skepticism comes from because anything less than manufactured where React showcases these benefits other frameworks accomplish on pure speed. And the manufactured examples feel hard to extrapolate to real world. I'm also wondering if 2 levels normal and low(transitions with schedulingEnabled) are sufficient. If load is moved out of the way will animations or responsiveness ever not reach their targets?

What we(the whole frontend ecosystem) really need is better examples.

[lxsmnsyc]

I believe continuous events (e.g. mousemove, input, resize, etc.) are sufficient examples wherein updates may trigger in a rapid manner and I believe that if a subsequent update comes in synchronously (like what Solid is doing right now), it may introduce some unexpected behavior.

[Nick-Mazuk]

One thing to note is that DOM updates always happen asynchronously in the browser, regardless of the framework's update model.

So SolidJS can update a DOM node's value 100 times in a single frame, but the browser will only apply those changes to the page once with the most recent values. That's just how the event loop works.

(yes, when you access the value via JavaScript, it will immediately be updated synchronously as Ryan mentions in the docs. But the browser will not apply those updates to the actual HTML elements immediately)

[lxsmnsyc]

I know about that, I was talking about reactive consumers like createEffect. Some of them are not scheduled and runs synchronously when the update queue gets flushed.

[Nick-Mazuk]

I know about that, I was talking about reactive consumers like createEffect. Some of them are not scheduled and runs synchronously when the update queue gets flushed.

Totally fine. Just double-checking.