Try: Support block edit defined as tag name for web components interoperability
#2791
Conversation
aduth
added
[Feature] Extensibility
|
Amazing work aduth! I verified that this works with regular web components, ones created by Polymer, and ones created by Stencil as well. This is really cool stuff. Very excited about this, I think others will be as well. I have a commit that fixes the test if you would like me to push. |
Feel free! |
Codecov Report
@@ Coverage Diff @@
## master #2791 +/- ##
==========================================
+ Coverage 33.82% 34.44% +0.61%
==========================================
Files 189 192 +3
Lines 5661 6161 +500
Branches 988 1124 +136
==========================================
+ Hits 1915 2122 +207
- Misses 3171 3396 +225
- Partials 575 643 +68
Continue to review full report at Codecov.
|
|
Leaving some more links by @mikeal and @slightlyoff for further exploration: |
|
Would it also be in the scope of this issue to add an API (to ComponentInterop?) for attaching event listeners to the WC DOM node to fire React synthetic events? See for example, https://staltz.com/react-could-love-web-components.html. Or is there a separate issue for that? |
|
@effulgentsia At least in this specific context, since the editor won't be expected to handle custom events from the web component, I don't know that we'd need to emulate handling these to integrate with React's synthetic event system. But, in a more general use-case and depending on requirements on how the rendered component is used, I could potentially see it being part of |
|
As we move to polishing an initial release of Gutenberg, we’ve been doing some triage of old pull requests. The ideas put forth here are still valid and interesting, but simply in the name of shipping, we’re going to close this one for now. That doesn’t mean it’s not a good idea, nor that it can’t be revisited and reopened. |
Related: #2463
This pull request seeks to add support for defining a block's
editproperty as a tag name, in an effort to explore support for block editable UIs defined as custom elements. The idea being that custom elements may serve as a baseline interface by which the editor creates a block element to be shown in the Gutenberg application. While granting that custom elements are in many ways not an ideal pattern for authoring blocks, they may work well enough as the low-level platform primitive for WordPress to target, and framework wrappers may serve to fill the gap of developer usability.As an example, consider the following plugin which implements a Gutenberg "Stars" block using Vue, with VueCustomElement providing the necessary wrapper to expose the Vue component as a custom element:
https://gist.github.com/aduth/369767f8153eaad1d955a8022f14ec34
Similar wrappers exist for other frameworks, and in fact some frameworks like Polymer implement their components as custom elements, and yet others like Stencil compile at build time to custom elements.
Implementation notes:
When assigning props to a custom element in DOM reconciliation, React currently does not do well to distinguish between attributes and properties. This was originally slated for improvements in React 16, and while treatment of unknown attributes was improved, this particular failed distinction still exists and was noted as "Future Work" now slated for React 17.
To work around this, a new
ComponentInteropcomponent is included to bypass default React reconciliation for custom elements. Currently, it assigns block attributes as DOM attributes vianode.setAttribute, and all other block props as properties of the node. This implementation is open for discussion, and may need to be improved and/or alternative terminology may need to be used to clarify between block attributes and DOM attributes, should the distinction need to be made.Testing instructions:
Download and install the reference Vue custom element block as a plugin to a WordPress installation: