JSX Outlining

[gsathya]

Currently, the react compiler can not compile within callbacks which can potentially cause over rendering. Consider this example:

function Component(countries, onDelete) {
  const name = useFoo();
  return countries.map(() => {
    return (
      <Foo>
        <Bar name={name}/>
        <Baz onclick={onDelete} />
      </Foo>
    );
  });
}

In this case, there's no memoization of the nested jsx elements. But instead if we were to manually refactor the nested jsx into separate component like this:

function Component(countries, onDelete) {
  const name = useFoo();
  return countries.map(() => {
    return <Temp name={name} onDelete={onDelete} />;
  });
}

function Temp({ name, onDelete }) {
  return (
    <Foo>
      <Bar name={name} />
      <Baz onclick={onDelete} />
    </Foo>
  );
}

The compiler can now optimise both these components:

function Component(countries, onDelete) {
  const $ = _c(4);
  const name = useFoo();
  let t0;
  if ($[0] !== name || $[1] !== onDelete || $[2] !== countries) {
    t0 = countries.map(() => <Temp name={name} onDelete={onDelete} />);
    $[0] = name;
    $[1] = onDelete;
    $[2] = countries;
    $[3] = t0;
  } else {
    t0 = $[3];
  }
  return t0;
}

function Temp(t0) {
  const $ = _c(7);
  const { name, onDelete } = t0;
  let t1;
  if ($[0] !== name) {
    t1 = <Bar name={name} />;
    $[0] = name;
    $[1] = t1;
  } else {
    t1 = $[1];
  }
  let t2;
  if ($[2] !== onDelete) {
    t2 = <Baz onclick={onDelete} />;
    $[2] = onDelete;
    $[3] = t2;
  } else {
    t2 = $[3];
  }
  let t3;
  if ($[4] !== t1 || $[5] !== t2) {
    t3 = (
      <Foo>
        {t1}
        {t2}
      </Foo>
    );
    $[4] = t1;
    $[5] = t2;
    $[6] = t3;
  } else {
    t3 = $[6];
  }
  return t3;
}

Now, when countries is updated by adding one single value, only the newly added value is re-rendered and not the entire list. Rather than having to do this manually, this PR teaches the react compiler to do this transformation.

This PR adds a new pass (OutlineJsx) to capture nested jsx statements and outline them in a separate component. This newly outlined component can then by memoized by the compiler, giving us more fine grained rendering.

There's a lot of improvements we can do in the future:

• For now, we only outline nested jsx inside callbacks, but this can be extended in the future (for ex, to outline nested jsx inside loops).

function Component(arr) {
  const jsx = [];
  for (const i of arr) {
    jsx.push(
      // this nested jsx can be outlined
      <Bar>
        <Baz i={i}></Baz>
      </Bar>,
    );
  }
  return jsx;
}

• Only the JSX expression statements are outlined, none of the other statements that flow into the jsx are outlined. This is a bit tricky as we must only outline non-mutating statements using our effects analysis.

function Component(arr) {
  return arr.map((i) => {
    // this statement should not be outlined
    const y = mutate(i);
    // this statement can be outlined
    const x = { i };
    return (
      <Bar>
        <Baz x={x} y={y}></Baz>
      </Bar>
    );
  });
}

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
react-compiler-playground	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Oct 17, 2024 5:13pm

[josephsavona]

Awesome! Looking forward to reading through this. Quick question:

This PR adds a new HIR node (StartJsx) to track when the jsx statement starts, which lets us start capturing nested jsx expressions.

Why do we need this as an instruction, vs doing a quick scan through the instructions to find the outermost JSX instruction?

[gsathya]

Why do we need this as an instruction, vs doing a quick scan through the instructions to find the outermost JSX instruction?

Yeah, this is a good question! I initially started with the scan approach but then hit a roadblock for this case:

// @enableJsxOutlining
function T({ t, a, b }) {
  return t.map(() => {
    let x = <Foo a={a} />
    let y = <Baz b={b} />
    // ... potential shenanigans ...
    return <Bar>{y}{x}</Bar>
  });
}

function B({t, a, b }) {
  return t.map(() => <Bar><Foo a={com(a)} /><Baz b={b} /></Bar>)
}

Here we want to differentiate between the two cases and not outline the first example. The jsx expressions, in either case, aren't in a consecutive sequence to make the quick scan work. For the second case, the children are read as jsx expressions and not from a local. This is potentially a way to differentiate but doesn't seem future proof as lowering to a local shouldn't have any semantic change, so I can see us doing this as part of some future change. I ended up going with the StartJsx (similar to StartMemoize) to be sure that we're inside a jsx expression.

[josephsavona]

Hmm, it seems pretty reasonable to just use a scan and exclude StoreLocal, which would reject the first example and allow the second. We could always expand to allow StoreLocal if we determined that it was only used once, in the subsequent JSX code. This could be a backwards traversal with a narrow allowlist of instructions like jsx, primitives, globals.

It's really really nice to avoid adding instruction variants.

[josephsavona]

This is why it's so nice to avoid adding instructions :-)

[josephsavona]

yay i'm so glad this worked!

[gsathya]

This could be a backwards traversal with a narrow allowlist of instructions like jsx, primitives, globals.

Oh good call! I've updated the PR to do this instead

[josephsavona]

This is really exciting! Seems pretty close, see comments about duplicate attribute names

[josephsavona]

Requesting changes for handling intermediate instructions and duplicate attribute names

[josephsavona]

Awesome!