Tracking issue: Custom Elements Hydration 🧩

[luisherranz]

This issue aims to list and keep track of the tasks related to the Custom Elements Hydration experiment.

For the Directives Hydration experiment, please check the Tracking Issue: Directives Hydration ⚛️.

The main branch of this experiment is main-custom-elements-hydration. Make sure you select it when opening a pull request if it is related to this experiment.

Please proactively comment on this issue whenever you start working on a new task, get blocked, or finish a task, sharing as much detail and information as possible. Thanks!!

Done

• Hydrate Frontend components
• Make sure Frontend components are automatically rehydrated if they appear in the DOM at any point (not only on page load)
• Support partial hydration with Inner blocks (children raw HTML)
• Serialize attributes and pass them down to the View component
• Use children instead of in the Save component to be able to reuse the same component in the View
• Support definition of public frontend attributes and only serialize those #15
• Support initially hidden inner blocks #8
• Add wrapperless blocks, hook shims and a block support #3
• Reuse the same RichText component across the different environments (Edit, Save and Frontend) #2
• Add wrapperless blocks, hook shims and a block support #3
• Implement different hydration techniques #14
• Support BlockContext between different blocks #7
• Add the interactive block attributes during server-side rendering #34
• Support attribute sourcing #30
• Support React Context API #40
• Support providing Block Context from non-interactive blocks #28
• Support className and style blockProps on block wrapper #41
• Nomenclature changes #45
• Unmount react component when WpBlock is disconnected #47
• Hydrate views even if they are registered after the DOM nodes appear #57

Required to expose as experimental API in Gutenberg

• Layout issues around <wp-block> and display: contents #49
• Export different code depending on the context (Edit, Save, or View) #11
• <wp-inner-blocks> causes DOM differences between edit and frontend #50
• Make sure inner blocks are sent to the frontend even if the Save/View component doesn't render them initially #59
• setTimeout callback doesn't seem 100 % reliable #69

Future improvements

• Children slots in client components #62
• Connect React context provider if it is created after a child using that context has been already hydrated #58
• Add support for frontend-side i18n
• Research how to hydrate different block variations
• Change hydration technique based on block attributes
• Add an onClick hydration technique (like Qwik or Rocket)
• Support for Suspense and Error boundaries between different blocks
• Search for alternative bundling strategies to wp globals that can support tree-shaking and code deduplication

[luisherranz]

Previous video summaries

Originally posted in #6

Update 1

https://www.loom.com/share/549258dfe6844fe0b3fdc8c3fc856b13

For context, when I mention Turbolinks in the video, I'm referring to this type of client-side navigation: WordPress/gutenberg#38713

Update 2

https://www.loom.com/share/e5a5541d027d4149a91a70f30b0913be

Resources mentioned:

• Block Context
• Attribute serialization
• hpq

[cbravobernal]

I'm currently working on #38. Still digging and trying to discover the best way to duplicate the Context Provider and sync the value of that context.

[michalczaplinski]

I have started working on adding support for providing context from non-interactive blocks.

[cbravobernal]

Added a WIP draft PR for #38 -> #40

[michalczaplinski]

Resharing this brief status update on my work on #28:

I was able to make it work so far in the simplest case: one static (non-interactive) parent and one child interactive block 👍 .

Most immediate next steps would be:

• Making it work with multiple parents. An interactive block can inherit context from multiple parent blocks.
• Making it work with initially hidden blocks. Adding a global event listener on load does not work because if a new interactive block is dynamically added to the DOM, it will not be subscribed to the events! I guess we have to encapsulate this code in the connectedCallback() of our <gutenberg-interactive-block> custom component.

[michalczaplinski]

I've finished the work on Support providing context from non-interactive blocks #28. It's gonna go through some review now but should be close to what we want to merge 🙂 .

[cbravobernal]

The React Context API subtasks are 90% complete! We still need to check how it works on the editor, where it should be easy.

I will update the tracking issue again as soon as we unsubscribe the contexts after using them.

[luisherranz]

I've opened an issue to see how we could unmount the interactive-block components before they are removed from the DOM:

• Unmount interactive blocks before removing them from the DOM #42

[luisherranz]

I've also added Matías' nomenclature suggestions to the list, although I'd wait until the rest of the PRs are merged to avoid merge conflicts.

• Nomenclature suggestions #37

[cbravobernal]

• Support React Context API #40 Status update:

The last commits are adding a double Map to link blocks to context, and then the values and update values functions to those block->Context-> Value

On the other hand, I will next take a look if we can suppress custom warnings for the useEffect, or either way, look for an alternative to run the code once without it.

Weakmap seems to be valid in most edge cases, but @luisherranz offered to take a deeper view to see if it fits our requirements.

I will then wait for #28 to be merged, so we can check later if there are any conflicts and we can start testing altogether.

• Support providing Block Context from non-interactive blocks #28

[michalczaplinski]

• Support providing Block Context from non-interactive blocks #28 status update:

Luis has suggested that we try a slightly different approach in that PR in order to avoid using a custom element to wrap all blocks that pass context.

The idea is to serialize the context and pass it as an HTML attribute of the top-level HTML element of the block itself (as opposed to setting it on the custom element). Then, we can use a MutationObserver on the document to detect changes to the DOM and pass the context whenever that happens. This is necessary because the "new", updated DOM might contain new interactive blocks that are subscribed to some piece of context.

My worry is that this can have poor performance because we'll have to fire the MutationObserver callback on every DOM change and the DOM changes can come from unexpected sources (browser extensions, ads, third party scripts, etc.)

Next step: I will make a quick test to try to see how bad the new implementation would perform if there are very frequent DOM updates.

[cbravobernal]

-#40 status update:

I added another Context to see if it works and seems to be failing. Feel free to keep working on that, as I will be 2 weeks AFK!

[luisherranz]

Before we start adding code to the WooCommerce Block Hydration Experiments repo, I'd like to finish the three PRs we have open right now:

• Support React Context API #40 – @c4rl0sbr4v0 is on holiday so I can take care of this
• Support providing Block Context from non-interactive blocks #28
• Support className and style blockProps on block wrapper #41

And once those are merged, I'd like to do the nomenclature refactor:

• Nomenclature suggestions #37

Not important for Woo, but at that point, I'd also like to remove dprint, and test prettier with the prettier-php plugin.

[luisherranz]

I've finished the support for the React Context API (#40), including a code refactoring of frontend.js, which was getting a bit out of hand (d61391c). I've also resolved the conflicts on #28 and I'm working to resolve them in #41.

[luisherranz]

I've switched to prettier in #43 and resolved conflicts on #28 and #41.

@michalczaplinski, @ockham everything should be fine now.

Once you finish, I'll do the nomenclature changes.

[luisherranz]

#28 should be ready now. I've made a video to explain the changes because I unified everything in gutenberg-block.

I want to take a fresh look at the inner blocks template to see if we can avoid this problem now (and don't wait if/until we do this in Gutenberg):

• Inner block duplication on initially shown inner blocks #29

EDIT: BTW, I also added prettier-php in #28 to test it out.

[luisherranz]

@ockham finished #41 🎉🎉

I'm going to resolve the conflicts with #28.

[luisherranz]

I'm going to resolve the conflicts with #28.

Done. I think everything should be ready now.

[michalczaplinski]

• Support providing Block Context from non-interactive blocks #28 has been merged.

As Luis mentioned in this comment already, the approach of using the MutationObserver did not work so we're still going to wrap the non-interactive blocks with a custom element. However, Luis has moved the serialization to PHP so we're not saving the context in the content in save() anymore.

[luisherranz]

Thanks, Michal 🙂

I'll work on #37 today, and if I can, I'll check if #29 can be solved during render_block.

[luisherranz]

I've opened an issue to talk about prettier-php. If you're playing with this repository, please help us test it and if you have any problem, please report it here:

• Prettier PHP #44

[luisherranz]

The PR for the nomenclature changes is ready for review:

• Nomenclature changes #45

[luisherranz]

Update 3

Ok, now that we've kind of reached another milestone, I did another video summary to explain the latest changes.

https://www.loom.com/share/3b68a95ac80f43ecbe86ca8225cb35a0

[luisherranz]

I've opened a new issue for the bug I discovered during the video:

• Child using React context throws when there is no parent that provides that context #46

[michalczaplinski]

The PR for the nomenclature changes is ready for review:

• Nomenclature changes #45

I've merged this PR as well! 🙂

[SantosGuillamot]

I've created this repo to replicate the experiments done here but using Alpinejs. The main idea is to be able to compare the developer experience and limitations of both approaches. Right now, I just recreated the current blocks, but we will probably run a few more tests there.

[DAreRodz]

I took the liberty of merging the fix for the WpBlock unmounting issue (#42) as it was a simple PR and was tested already. 😄

• Unmount react component when WpBlock is disconnected #47

I also updated the tracking issue description with the latest changes.

[luisherranz]

I've updated the Up Next list with two new items:

• Add support for frontend-side i18n
• Research how to hydrate different block variations

[ockham]

I've filed #51 (which Carlos approved and merged -- thanks!) to fix

• Child using React context throws when there is no parent that provides that context #46

[luisherranz]

I've opened the issue to make sure the order of execution of the registerBlockType() and connectedCallback is not important:

• Make sure View components are automatically hydrated even if their component is registered after the connectedCallback execution #52

[luisherranz]

@DAreRodz and I have explored a fix for the race condition problem (#52):

• Hydrate views even if they are registered after the DOM nodes appear #57

Reviews are welcomed!

[DAreRodz]

I've discussed with @luisherranz what things we need to solve before exposing these APIs as experimental from Gutenberg.

It ended in a to-do list, included in the issue description. ☝️

[luisherranz]

I've added a bit more context to the Export different code depending on the context issue.

• Export different code depending on the context (Edit, Save, or View) #11 (comment)

[DAreRodz]

I created a new issue for the remaining item in the "Required for experimental API" list.

• Make sure inner blocks are sent to the frontend even if the Save/View component doesn't render them initially #59

[luisherranz]

I've added a proposal for an alternative wrapperless hydration method based on a static virtual DOM of the full page:

• Wrapperless hydration alternative: Directives hydration #60

[luisherranz]

We opened a new issue to discuss possible solutions to locate the children of the islands/client-components (moved from #60):

• Children slots in client components #62

[luisherranz]

@DAreRodz and I have created a new Tracking Issue to track the work related to the Directives Hydration:

• Tracking issue: Directives Hydration ⚛️ #64

From now on, please use this Tracking Issue for the Custom Elements Hydration experiment and the other one for the Directives Hydration experiment.

We've also renamed the main branch to main-custom-elements-hydration for this experiment and created a new one called main-directives-hydration for the other one. Please, select the correct branch when opening pull requests.

[SantosGuillamot]

• setTimeout callback doesn't seem 100 % reliable #69

As explained in this issue, it looks like the setTimeout callback we are using inside connectedCallback is not 100% reliable. So we may need to look for an alternative.

[luisherranz]

To avoid confusion, I've renamed "Island Hydration" to "Custom Elements Hydration" because both this and Directives are just ways of doing island hydration.

[luisherranz]

Closed as we're not actively working on this experiment anymore. Our work continues in:

• Tracking issue: WordPress Directives Plugin 🎨 #80

[fabiankaegy]

Closed as we're not actively working on this experiment anymore. Our work continues in:

@luisherranz I've been trying to track down the reasons why this approach was abandoned :) Would you be able to shed some light on that? :) Thanks in advance!

[luisherranz]

It had a few issues:

• There's no easy way to use this approach with dynamic blocks.
• Any dynamic markup modifications (done with PHP hooks) are not reflected on the JSX template and are reverted after hydration.
• It also makes some things like internationalization much more complex than needed.

[fabiankaegy]

Thanks for sharing that insight :)