In there a plan for static-view direct updates in R18?

[drcmda]

In React we used to call setState 60fps to push animation forward (react-motion) but each update goes through diffing, hooks, sub-trees. This is something that time-slicing can't solve because here we really need fast access. Some animation libs handle updates outside of React (animated, framer-motion, react-spring), the price is internal complexity and inflexibility (they can't function cross platform bc they need to "know" the host).

One approach was setNativeProps but that was problematic. A simpler approach may be to give React the ability to handle transient values. In the following example React would re-hydrate the view if count is changed, given that it is static (non-changing). Thereby we would have zero overhead write access. The component would not re-render but simply update the dom.

function FastCounter() {
  const [count, set] = useTransientState(0)
  useEffect(() => {
    let frame
    function loop() {
      frame = requestAnimationFrame(loop)
      set(count => count + 1)
    }
    loop()
    return () => cancelAnimationFrame(frame)
  }, [])

  // count is not a value, but a function that React knows to call to get a fresh value
  // when count changes react would pick up the last generated view and inject a fresh value
  return (
    <div>
      {count}

As for interpolation, where the same value creates different variants or interpretations of its own content:

  return (
    <div style={{ opacity: count.interpolate(count => (1 + Math.sin(count)) / 2) }}>
      {count}

[gaearon]

I will respond about the problem rather than about the proposed solution because I don’t have enough background info on the solution itself (other than that we’ve intentionally not pursued it so far).

The problem you’re highlighting is animations. And specifically updating some parts of the tree very fast, and how diffing doesn’t scale to that. We agree it’s a different use case.

First-class React Animations will not be a part of the React 18 release. This is both because it’s a large scope of work which would delay the release by a lot, and because it requires a bunch of research as well as a change in internal data structures.

However, the thinking here is this. We would “teach” the reconciler to interpolate between two versions of the tree. In other words, before the animation starts, we’ll render (in memory) the tree before and the tree after the animation. We will diff them, taking into account an opt-in API that lets components specify their visual state on enter and exit, and recording any values that are different and can be interpolated. Then we would “hand it off” that list of values to a renderer-specific “driver” which would be a highly optimized piece of code that performs the interpolation — ideally, using the platform primitives when possible.

I’m not sure we can use CSS transitions today given that they aren’t springy, but RN would use a native driver where possible, and maybe if CSS supports springs, we could switch to that as well. So it’s a constraint that for the common case we don’t want any tree re-renders during the animation at all. However, there would be ability to hand off the animation to a gesture-driven “driver” which might still execute on JS thread. In this case it would still use the precalculated interpolation though rather than do a re-render on every frame.

This is still very high-level so I probably won’t be able to respond to detailed follow-up questions — but that’s more or less what we’re thinking.

[drcmda]

A ref is not generic or composable, it can't be abstracted. For instance, i wish framer could animate more platforms than the dom, but React libraries that handle fast updates (animation, transition, gestures, etc) cannot be x-platform bc of it. React-motion can be, because it lets React resolve the view by re-rendering the component with new values. This would be so useful to have, without the overhead.

As for use cases, maybe @vjeux has something to say about this, he introduced platform targets to the animated library back then to teach React about platform semantics. In there is all the complexity of updating, say, a style prop. But React renderers have that knowledge inbuilt.

That used to be a constant source of criticism by Rich Harris and Evan You. Using React for fast updates daily i must say they do have a real point, it is something that is missing. I'm just here to nag about this every once a year. 😅

[gaearon]

but React libraries that handle fast updates (animation, transition, gestures, etc) cannot be x-platform bc of it

Sure, and that’s why we want to have a high-level first-class animation API built into React itself. Exposing low-level primitives helps for some cases but it doesn’t let us build powerful enough high-level APIs.

So if the use case you’re discussing is gestures/animations, we do plan to address it — but not through a low-level API. At least not initially.

[gaearon]

More concretely, the low-level platform-specific parts would be a part of the renderer config. So each renderer would be able to implement them in a way that works best for the target platform.

[drcmda]

Imo concentrating on animation misses the point. You don't want React in your animation, you don't want it to touch it, defer it, schedule it, execute it, you want to be closest to a system base op as humanly possible without any interference. And the same goes to gestures. The 🔑 that unlocks fast updates (for any purpose) in the React eco system is if React learns to step aside, but not as an escape hatch like with refs, but in a way that still lets us operate upon a view with React semantics. Looking forward to any progress - but until then, we'll enjoy React 18 and its amazing contributions for what it is. 🎉 😊

[gaearon]

Since we haven’t actually written up our plan on Animations anywhere yet (and that’s quite a big task by itself) it’s hard to have these conversations. Yes, you don’t want React to be “in the middle” of the animation — this is precisely why the animation/gesture APIs we’re planning don’t re-render on every frame by default, and why effects wouldn’t observe intermediate values. Instead, for example, we could calculate keyframes (to hand off to the platform) by interpolating between multiple precalculated React trees (and keeping React rendering minimal during the animation or gesture).

To sum up:

• Many use cases for what you’re suggesting are related to either animations, gestures, or other manipulation that maps to a timeline-ish source (like a scroll timeline).
• We want to have a first-class API for those cases. There are things that are uniquely possibly in React that userland solutions can’t implement. This includes layout animations and enter/exit animations that “understand” the React tree, can be added anywhere without low-level components (like design system) having special awareness of animations/gestures, that work with arbitrary third party components, and that are able to see the “correct” context and state during the animation (unlocked by concurrency).
• Of course, we want React to mostly “get out of the way” during the animation which is why the design will be split into two parts. The reconciler only produces trees to interpolate between. That happens early, not during the animation. The renderer config specifies how this interpolation is applied. We plan to start this research this year. This is where there’s a lot to learn from Framer Motion and similar projects. Thanks to this separation, we will be able to make animations truly composable (you’ve seen Suspense—we want to do the same for animations), while also not tied to React re-renders on every frame for the majority of cases.

This doesn’t mean that we can’t expose anything lower level ever. When we get to Animations it’s possible this will be on the table in some way. But we don’t want to expose a low-level API before we’ve had a chance to build a high-level one. This is because low-level APIs have a nasty habit of making high-level ones impossible because too much has been exposed imperatively and we can’t make a declarative system anymore.