Tracking Issue

[michalczaplinski]

Description

The goal of this project is to test the experiments being done in the Block Hydration Experiments repo (BHE) with some real blocks. And due to the complexity of some of the WooCommerce blocks, we believe it could be a great place to start.

Bear in mind that right now these blocks are already dealing with frontend interactivity and they are working perfectly fine, so don’t expect changes in the UX during this project. It isn’t its goal.

We feel that we can start testing in simpler blocks and work later on more complex ones. These are the initial use cases with client interactivity we are planning to start replicating:

• Cart block and some of its inner blocks like the Coupon form or the Shipping block.
• Checkout block and its inner blocks, which seem pretty similar to the Cart.
• Minicart block and its inner blocks, which seem pretty similar as well.

@SantosGuillamot made a quick video to show how they currently work in terms of UX -> Loom video.

Feel free to share any feedback or any other block that you believe could be interesting.

Goals

The goal is to integrate the hydration technique used in Block Hydration Experiments repo into this repo to test it with the Woo blocks.

Based on our initial assessment, using the technique from BHE should allow us to use “wrapperless” hydration based on custom elements which should simplify this logic that handles the hydration of parent and inner blocks.

Out of scope

In this initial phase, we aren’t planning to work on the Product Grid block as it is more complex and will probably require more functionalities we haven’t developed yet. This doesn’t mean we won’t test the experiments there, we will probably do that, but it won’t be part of these first tests.

Tasks / tentative roadmap

These are the steps we defined, although they’re subject to change.

We can start working on:

1. The All Products Block as it is quite simple and does not have inner blocks.
2. The Summary Coupon form, which is the inner block of the Cart block. This way, we can progressively start adding BHE hydration to inner blocks of the Cart block. Mind that the Cart block is the parent block of the Summary Coupon Form block. Currently, the parent blocks are responsible for handling the hydration of their inner blocks. So, working on the Summary Coupon Form will require “disabling” the current hydration mechanism for the Summary Coupon block inside of the Cart block and adding the hydration mechanism from BHE.

Rough plan of action

For the very first iteration, I think we should try to hydrate the All Products Block as it does not have any inner blocks:

• [x] Enqueue the code that adds our custom <wp-block> element to the frontend. In the first iteration, it probably makes sense NOT to add the <static-context> to the frontend.

  Done in #39.

• [x] Add the serialization of block attributes and return the blocks wrapped in our custom elements in the add_data_attributes(). During SSR, each (hydrated) block should be wrapped with <wp-block> and pass the attributes to that element instead of the wrapper inadd_data_attributes(). This step would roughly require substituting the code in add_data_attributes() with the one from the bhe_block_wrapper().

  Worked on in #21

• [x] In the All Products block, update the implementation of thefrontend.js file to NOT use the renderFrontend() function but instead register the block in the frontend block registry using (a simplified version of) registerBlockType() from BHE.

  Worked on in #21

Those steps should (roughly) be sufficient to hydrate a simple block that does not have any inner blocks!

As for hydrating the Cart block or other blocks that include inner blocks, the plan becomes a bit more complex. It would be a good idea to try to first hydrate a single inner block of the Cart block (like the aforementioned Summary Coupon Form). Then, we can progressively expand the set of hydrated inner blocks until all of them are hydrated using the technique from BHE, including the Cart itself.

This would involve (some of) the following steps:

1. Removing the code for the current block registration mechanism from the Summary Coupon Form
2. Hardcode a temporary “exception” in the Cart block so that it does NOT hydrate the Summary Coupon Form using the current hydration mechanism. This is necessary because we want to Summary Coupon Form to “hydrate itself” (as this is the way hydration works in BHE).
3. Update the implementation of the frontend.js of the Summary Coupon Form to register the block in the frontend block registry using (a simplified version of) registerBlockType() from BHE. (This is roughly the same step as step 3. for the All Products block).
4. [x] #66
5. [ ] #67

Notes

In BHE, we are automatically deriving the save from the frontend. For the first iteration, I would NOT include that in our integration so as not to complicate things too much. We can work on this as a later optimization.

Questions

• Probably the most important right now: Figure out in finer detail how the hydration of inner block should work e.g. in the Cart block.
• How to deal with block deprecations? We'll have to save additional custom elements in the save() functions, thus changing the block's markup.
• How do we test our integration?
  • Here it might be helpful to get help from the Woo team to understand their testing so that we can (ideally) write some e2e tests to verify our integration did not break too many things :)
• Find out if we need to make any changes to the code that updates fragments (updateCartFragments) - I think that probably not.

[luisherranz]

We'll have to save additional custom elements in the save() functions

Not anymore. @ockham has been working on that 🙂

• https://github.com/WordPress/block-hydration-experiments/pull/34
• https://github.com/WordPress/block-hydration-experiments/pull/41

[Aljullu]

Very excited about this project! Count with us with anything we can help with. :slightly_smiling_face:

The All Products Block as it is quite simple and does not have inner blocks.

@michalczaplinski, just wanted to give a heads-up that the All Products block is a block that might be refactored in the future as we make progress towards a new standard to render Product grids. Currently we are in early explorations and we don't have any plans in the short term to refactor or migrate the All Products block to the new Product grid; however, I wanted to mention this is a possibility in case you want to focus on some other blocks.

[michalczaplinski]

Very excited about this project! Count with us with anything we can help with. 🙂

Thank you, Albert! 🙌

@michalczaplinski, just wanted to give a heads-up that the All Products block is a block that might be refactored in the future as we make progress towards a new standard to render Product grids.

Roger that! I think we'll try to see how to hydrate it anyway because it should be (relatively) simple and should also inform how we handle more complex blocks. I see that @ockham has already taken a stab at it in #21 😃

[cbravobernal]

As for hydrating the Cart block or other blocks that include inner blocks, the plan becomes a bit more complex. It would be a good idea to try to first hydrate a single inner block of the Cart block (like the aforementioned Summary Coupon Form). Then, we can progressively expand the set of hydrated inner blocks until all of them are hydrated using the technique from BHE, including the Cart itself.

I will start working on this one 😄

[michalczaplinski]

We've merged the first two PRs 🥳 :

• 39 - This one was simple - just adding the WpBlock to the frontend.

• 21 - The All Products block is successfully hydrated using the BHE techniques. Before merging it, we've had to trace and fix a nasty bug related to unnecessary module bundling.

[cbravobernal]

I added a couple of issues to keep working on 😄

• 66

• 67

[DAreRodz]

I'm going to try reimplementing the Checkout and inner blocks from scratch using only the BHE API. I want to test if it is easy to implement the same without using renderParent.

I'll open a draft PR and link it here soon. 🙂

[DAreRodz]

Before starting with the Checkout block, I wanted to test how easy it is to add new blocks to the repository. For that, I created a PR porting all the BHE blocks and context files.

I also added the BHE repo as a dependency in package.json (I know, it's not ideal, but it works 😅), so the files inside /src/gutenberg-packages are imported as external modules.

• 80

[DAreRodz]

I think I forgot to mention this (apologies for that):

The reason I wanted to reimplement Checkout from scratch (see https://github.com/woocommerce/woocommerce-blocks-hydration-experiments/issues/20#issuecomment-1210938588) is because parent blocks (e.g., Cart and Checkout) take over their content and render a different HTML tree, thus forcing inner <wp-block> components to render twice: first during HTML parsing, and again during Cart/Checkout rendering.

I partly mentioned that in the following issue, where I shared concerns regarding our first idea of modifying existing blocks instead of rewriting them from scratch.

• https://github.com/woocommerce/woocommerce-blocks-hydration-experiments/issues/68

[DAreRodz]

Quick update: I stopped (a while ago) my plans of re-implementing the Checkout block in favor of pushing the "directives hydration" research. I'll continue with the re-implementation later (if we consider it would be worth it). 🙂

• https://github.com/WordPress/block-hydration-experiments/issues/64

[github-actions[bot]]

This issue has been marked as stale because it has not seen any activity within the past 60 days. Our team uses this tool to help surface issues for review. If you are the author of the issue there's no need to comment as it will be looked at.

Internal: After 10 days with no activity this issue will be automatically be closed.

[michalczaplinski]

Indeed, this tracking issue is somewhat "stale" as the team is focusing on https://github.com/WordPress/block-hydration-experiments/issues/64.

I don't expect that to change in the coming weeks, possibly months but if plans change we'll keep updating this issue.