(PoC) UI PHP components: Store a base render plus variant changes - #84905

🤖 PR meta 🤖

📦 Bundle size

Size Change: 0 B

Total Size: 8.96 MB

_{7fd56f8 Run}

⚡ Performance

_{7fd56f8 Run}

🏁 Flaky tests

Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

Error: expect(received).toStrictEqual(expected) // deep equality

- Expected  - 1
+ Received  + 1

  Array [
    "rewrite_rules",
-   "SERIALIZED DATA",
+   "",
  ]
    at forEach (/home/runner/work/gutenberg/gutenberg/test/e2e/specs/editor/various/core-settings.spec.js:46:26)
    at /home/runner/work/gutenberg/gutenberg/test/e2e/specs/editor/various/core-settings.spec.js:43:35

TypeError: Cannot read properties of null (reading 'y')
    at /home/runner/work/gutenberg/gutenberg/test/e2e/specs/editor/various/draggable-blocks.spec.js:824:57
    at dragSelectionBelowLanding (/home/runner/work/gutenberg/gutenberg/test/e2e/specs/editor/various/draggable-blocks.spec.js:823:3)
    at /home/runner/work/gutenberg/gutenberg/test/e2e/specs/editor/various/draggable-blocks.spec.js:844:3

Error: expect(string).toMatchSnapshot(expected) failed

  @@ -1,3 +1,3 @@
   <!-- wp:paragraph -->
  -<p>2Cut - collapsed selection</p>
  +<p>2</p>
   <!-- /wp:paragraph -->


    at /home/runner/work/gutenberg/gutenberg/test/e2e/specs/editor/various/copy-cut-paste.spec.js:45:49

_{7fd56f8 Run}

This definitely has a marked improvement on the size of the manifest itself 👏 And in general if we were to adopt this approach of automatically converting React variants to equivalent PHP output, this would likely be the direction we'd want to adopt. To the original scalability concern raised in #84036 (comment), this doesn't help in regards to the fact that we're still computing every possible combination of props for every component, and managing this as diffs introduces its own complexity too. That seems like it may be inherently necessary as part of automating conversion of components, which is what gives me pause to that direction overall, and reevaluating whether there's a direction that allows us to reuse as much as possible across PHP & JavaScript implementations to narrow the scope of maintenance burden to the thin layer that needs to be specific to each (e.g. something like a language-agnostic class variance authority for managing at least the variant -> class mapping in each context).

Another thought that occurs to me is whether we can reduce complexity by reusing pieces that are already available, like Interactivity API for some aspects of the "slots" that have been introduced here. I know you've been thinking about Interactivity API in #84036 in the context of interactive components, but I also wonder if there's aspects we can leverage there for strictly the attribute binding behavior, to reduce the custom behavior we have to implement.

Thanks for taking a look @aduth!

this doesn't help in regards to the fact that we're still computing every possible combination of props for every component

That's a fair concern, especially for components with many props like Button. Right now, the changes come from rendering each prop value once against the defaults, and rendering every combination is only there to check the result. So, that part could be reduced (for example, only checking props that interact), but the diffing itself would still be there to maintain.

something like a language-agnostic class variance authority for managing at least the variant -> class mapping in each context

This is close to the prototype you shared, and I looked at a similar spec at the start. I explored this other direction because I was trying to reduce the friction that changing how @wordpress/ui components are written may bring. Interestingly, what this PR computes is pretty much that recipe, just derived from React instead of written by hand.

So there might be a middle ground. A recipe and a small PHP template like in the prototype, checked against react's renders with parity tests, instead of react reading the recipe. React stays as it is, and the PHP side stays thin. It'd be worth comparing both with the same component.

whether we can reduce complexity by reusing pieces that are already available, like Interactivity API

That's interesting. Something like that could replace the placeholders, and take care of escaping. I'll take a look.