Support providing Block Context from non-interactive blocks

[michalczaplinski]

⚠️ This is still WIP

We have added support for BlockContext in #7.

Interactive blocks can now provide block context to other interactive blocks on the frontend.

However, static (not hydrated) blocks cannot provide context to interactive blocks. This PR is adding support for this feature.

[michalczaplinski]

I've recorded a brief overview of what we've been trying to achieve. If anybody would like to continue this work, you're very welcome to do so!

2022-05-24_16-59-49.mp4

[luisherranz]

Context is not available on save, but why do you need it? If a block provides a context, the value is in one of its attributes. We just need to serialize that value, then add a global event listener.

[michalczaplinski]

Our idea was simply:

• Read the context that is passed from the static parent in the save() of the interactive block.
• Serialize it in and add it to the attribute like in the save().
• Deserialize and use in the frontend.

But you're right that with the context not being available on save() it's not going to work.

If a block provides a context, the value is in one of its attributes. We just need to serialize that value, then add a global event listener.

Yup, but I think that would require some modification to the "static" blocks, like adding a wrapper around the save() of the static blocks and we were trying to avoid that. Unless you had a different idea here? 🤔

[luisherranz]

like adding a wrapper around the save() of the static blocks

I don't really care if it's a wrapper or a blocks.getSaveContent.extraProps filter, as long as it is abstracted by Gutenberg and not exposed to the developer 🙂

[michalczaplinski]

We paired up to pair-program on this PR with @luisherranz.

We still have to figure out where and how to serialize the data in the static (non-interactive) block:

[michalczaplinski]

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 made some more progress:

• Got it to work with multiple parents
• Got it to work with initially hidden blocks

(basically, what I have mentioned in the comment above)

I'm sure it's still buggy but seems to work at least in the happy path.

2022-07-06_19-24-35.mp4

[luisherranz]

I'm resolving the conflicts with my refactor on d61391c.

[luisherranz]

@michalczaplinski everything should be working again now. Feel free to continue with this 🙂

The attributeFilter approach didn't work. We're going with Michal's initial custom-element proposal.

[luisherranz]

As the Mutation Observer option could introduce performance concerns and the attributeFilter approach didn't work, I just renamed gutenberg-interactive-block to gutenberg-block and reused all the code.

I've also renamed all the blocks. I hope the new names will help to make more sense of the structure of these experiments for new people looking into them.

I've made a video to explain the changes.

https://www.loom.com/share/72d45ab8574c42258e8eee48c3dca3d5

@michalczaplinski would you mind taking a look? Thanks!! 🙂

[luisherranz]

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

[luisherranz]

Done 👍️

AFAIK, everything should be ready to merge now.

[michalczaplinski]

Looks great, thanks for working on this, @luisherranz ! 🙂

I can't approve my own PR just going to merge it.

[luisherranz]

Thanks, Michal! 🎉