Support BlockContext between different blocks #7

luisherranz · 2022-04-08T15:10:21Z

The idea is to try using a custom event that is captured by a parent block that populates the context.

luisherranz · 2022-05-17T15:46:15Z

I've added a small explanation of how this could work in the last summary video: #6 (comment) (minute 6:30)

michalczaplinski · 2022-05-18T23:56:09Z

Sorry, for the triple force-push - I've changed the base of this PR (to include the fix in #19) and messed up the local branch in the process. All fixed now 🙂 .

luisherranz · 2022-05-19T10:15:47Z

No problem. I've merged main to keep it in sync with the latest changes (mainly formatting) 👍

luisherranz · 2022-05-19T10:17:24Z

I'm now the one who has messed something up 😆

luisherranz · 2022-05-19T10:22:17Z

Rebasing is not working either. Main commits are still appearing 😕

luisherranz · 2022-05-19T10:22:56Z

Ohhhh, ok. I got it. It's because you changed the base. I'll change it back to main.

luisherranz · 2022-05-19T10:23:28Z

Great. Everything back to normal 🙂

luisherranz · 2022-05-19T14:38:32Z

@michalczaplinski, are you working on this?

michalczaplinski · 2022-05-19T16:32:14Z

Yes! I don't have it in a workable state yet, but I ll share an update later today 🙂

michalczaplinski · 2022-05-20T04:40:35Z

Below's the current status update in video form.

The code is "working" but I didn't make much effort to clean it up yet.

There is also an issue that I have mentioned in the video, which I ll document later on. When including the parent block includes only the child block, it does not render that child block. I think this might be an issue with rendering inner blocks that was introduced in #8.

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

michalczaplinski · 2022-05-21T00:03:08Z

src/gutenberg-packages/frontend.js

+// We assign `blockTypes` to window to make sure it's a global singleton.
+//
+// Have to do this because of the way we are currently bundling the code
+// in this repo, each block gets its own copy of this file.
+//
+// We COULD fix this by doing some webpack magic to spit out the code in
+// `gutenberg-packages` to a shared chunk but assigning `blockTypes` to window
+// is a cheap hack for now that will be fixed once we can merge this code into Gutenberg.


In the comment I explain why I'm doing window.blockTypes (it's a hack).

Yep, this should be part of the Gutenberg APIs, so we can keep the hack for now 🙂

michalczaplinski · 2022-05-21T00:03:26Z

src/gutenberg-packages/frontend.js

-customElements.define( 'gutenberg-interactive-block', GutenbergBlock );
+// We need to wrap the element registration code in a conditional for the same
+// reason we assing `blockTypes` to window (see top of the file).
+//
+// We need to ensure that the component registration code is only run once
+// because it throws if you try to register an element with the same name twice.
+if ( customElements.get( 'gutenberg-interactive-block' ) === undefined ) {
+	customElements.define( 'gutenberg-interactive-block', GutenbergBlock );
+}


Directing your attention to the comment 🙂

michalczaplinski · 2022-05-21T00:08:03Z

@luisherranz I can't assign you for review because you've opened the PR 🙂
@DAreRodz can't assign you either (maybe cause you're not a collaborator? 🤔)

michalczaplinski · 2022-05-21T01:30:59Z

There is also an issue that I have mentioned in the video, which I ll document later on. When including the parent block includes only the child block, it does not render that child block. I think this might be an issue with rendering inner blocks that was introduced in #8.

I've managed to debug it and opened a new issue for this: #23

cbravobernal

Nice job!

luisherranz

I can't approve my own PR.

This is fantastic, Michal! 😄👏

I've added a couple of questions, but it's looking great. I'm glad this approach seems to work fine.

If you don't mind, I'm going to rename the blocks as I did in #25.

EDIT: I've also moved the frontend components to each block folder to make the block structure clearer.

The next step would probably be supporting dynamic contexts. I'll add a task for that but basically, we need to make this work:

// Parent provides attributes.count as context
const ParentFrontend = ({ attributes, setAttributes }) => {
  return (
    <button
      onClick={() => {
        setAttributes({ count: attributes.count + 1 });
      }}
    >
      increment context
    </button>
  );
};

// Children is rerendered when context changes (on the parent click)
const ChildrenFrontend = ({ context }) => (
  <div>The count is: {context.count}</div>
);

EDIT: I've added a new task for this.

luisherranz · 2022-05-23T15:30:30Z

src/blocks/block-hydration-experiments-child/edit.js

+// This import is needed to ensure that the `wp.blockEditor` global is available
+// by the time this component gets loaded. The `Title` component consumes the
+// global but cannot import it because it shouldn't be loaded on the frontend of
+// the site.
+import '@wordpress/block-editor';


Can you explain this a little bit? This block doesn't use the Title component, does it?

Oh, it seems that it does work fine even if I remove the import '@wordpress/block-editor'; which makes sense.

I have added it because it seemed make the warning about wp.RichText go away, but looks like I don't need it after all.

luisherranz · 2022-05-23T15:34:48Z

src/gutenberg-packages/frontend.js

+				if ( el !== null ) {
+					// listen for the ping from the child
+					el.addEventListener( 'gutenberg-context', ( event ) => {
+						event.stopPropagation();


Is there any reason to stop the propagation?

yes! I explain below in the video 🙂

luisherranz · 2022-05-23T15:38:05Z

src/gutenberg-packages/frontend.js

+			ref={( el ) => {
+				if ( el !== null ) {
+					// listen for the ping from the child
+					el.addEventListener( 'gutenberg-context', ( event ) => {


I'm not saying this is right or wrong, but what's your reasoning for adding the event listener to the guntenberg-inner-blocks instead of the block wrapper? 🙂

I think that this is the only option we have if I'm not mistaken. Lemme explain in a video:

2022-05-23_20-24-04.mp4

Ok, thanks for the video, Michal 🙂

I think those problems can be circumvented, but we shouldn't worry for now, this is perfectly fine as it is. If there's a simpler solution, it will present itself once we do more complex stuff!

Just for completeness, I also thought we could wrap the Comp like in a "useless" div like:

<div style={{ display: 'contents' }} ref={el => { /* add the eventListener here */ } } > <Comp attributes={attributes} blockProps={blockProps} suppressHydrationWarning={true} context={context} > <Children value={innerBlocks && innerBlocks.innerHTML} suppressHydrationWarning={true} /> </Comp> </div>

but that doesn't work well - it was e.g. breaking some styles. And that <div> does not have the blockProps applied to it which can cause other problems.

What would be the benefit of using an extra div versus using this as you explain in the video?

this points to the <gutenberg-interactive-block> wrapper.

There would be no benefit, that's what I was trying to say. But the issue is that you only want to ask the parent that is one level up for the context:

I've realized that we could also do this:

// inside of the connectedCallback() this.addEventListener( 'gutenberg-context', ( event ) => { if ( this !== event.target ) { // <- only set the context if we're in the parent. event.stopPropagation(); event.detail.context = providedContext; } } ); // ping the parent for the context const event = new CustomEvent( 'gutenberg-context', { detail: {}, bubbles: true, cancelable: true, } ); this.dispatchEvent( event );

So, this way we can both listen to and fire the event on the same element (the <interactive-gutenberg-block>) but only set the context if we're in the parent. This works because the event bubbles up.

Was this what you were suggesting or did you have another idea in mind?

Yes, I think so 🙂

I think you could also add the event listener after you've dispatched the event so they don't interfere.

michalczaplinski force-pushed the context-experiments branch 2 times, most recently from 5c467a2 to f4a3a28 Compare May 18, 2022 23:36

michalczaplinski changed the base branch from main to feature/opt-out-frontend-attributes May 18, 2022 23:37

michalczaplinski force-pushed the context-experiments branch from f4a3a28 to 2030199 Compare May 18, 2022 23:40

Add custom event

2e4bf34

michalczaplinski force-pushed the context-experiments branch from 2030199 to 2e4bf34 Compare May 18, 2022 23:53

luisherranz force-pushed the context-experiments branch from dcd361f to bc47e20 Compare May 19, 2022 10:21

luisherranz changed the base branch from feature/opt-out-frontend-attributes to main May 19, 2022 10:23

Add the first version of the context

d4242ab

michalczaplinski force-pushed the context-experiments branch from bc47e20 to d4242ab Compare May 20, 2022 03:24

michalczaplinski added 3 commits May 19, 2022 22:29

Merge branch 'main' into context-experiments

cb839e1

Format with dprint

3dddb88

Remove unnecessary ternary

809e690

michalczaplinski added 2 commits May 20, 2022 18:41

update package-lock.json

59b6cce

Add better comments

fb4b06b

michalczaplinski reviewed May 21, 2022

View reviewed changes

michalczaplinski requested a review from cbravobernal May 21, 2022 00:08

cbravobernal requested a review from DAreRodz May 23, 2022 07:41

cbravobernal approved these changes May 23, 2022

View reviewed changes

luisherranz commented May 23, 2022

View reviewed changes

luisherranz added 4 commits May 23, 2022 17:48

Merge branch 'main' into context-experiments

7d2ecf6

Rename blocks and move frontend code to blocks

bed7517

Update tasks

f71d477

Merge branch 'main' into context-experiments

039e1f2

luisherranz merged commit 80477ca into main May 24, 2022

michalczaplinski mentioned this pull request May 24, 2022

Support providing Block Context from non-interactive blocks #28

Merged

luisherranz mentioned this pull request Jun 30, 2022

Tracking issue: Custom Elements Hydration 🧩 #39

Closed

luisherranz deleted the context-experiments branch September 6, 2022 10:38

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Support BlockContext between different blocks #7

Support BlockContext between different blocks #7

luisherranz commented Apr 8, 2022

luisherranz commented May 17, 2022

michalczaplinski commented May 18, 2022

luisherranz commented May 19, 2022

luisherranz commented May 19, 2022

luisherranz commented May 19, 2022

luisherranz commented May 19, 2022

luisherranz commented May 19, 2022

luisherranz commented May 19, 2022

michalczaplinski commented May 19, 2022

michalczaplinski commented May 20, 2022 •

edited by luisherranz

Loading

michalczaplinski May 21, 2022

luisherranz May 23, 2022

michalczaplinski May 21, 2022

michalczaplinski commented May 21, 2022 •

edited

Loading

michalczaplinski commented May 21, 2022

cbravobernal left a comment

luisherranz left a comment •

edited

Loading

luisherranz May 23, 2022

michalczaplinski May 24, 2022

luisherranz May 23, 2022

michalczaplinski May 24, 2022

luisherranz May 23, 2022

michalczaplinski May 24, 2022

luisherranz May 24, 2022

michalczaplinski May 24, 2022

luisherranz May 25, 2022

michalczaplinski May 26, 2022

luisherranz May 31, 2022

Support BlockContext between different blocks #7

Support BlockContext between different blocks #7

Conversation

luisherranz commented Apr 8, 2022

luisherranz commented May 17, 2022

michalczaplinski commented May 18, 2022

luisherranz commented May 19, 2022

luisherranz commented May 19, 2022

luisherranz commented May 19, 2022

luisherranz commented May 19, 2022

luisherranz commented May 19, 2022

luisherranz commented May 19, 2022

michalczaplinski commented May 19, 2022

michalczaplinski commented May 20, 2022 • edited by luisherranz Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

michalczaplinski commented May 21, 2022 • edited Loading

michalczaplinski commented May 21, 2022

cbravobernal left a comment

Choose a reason for hiding this comment

luisherranz left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

michalczaplinski commented May 20, 2022 •

edited by luisherranz

Loading

michalczaplinski commented May 21, 2022 •

edited

Loading

luisherranz left a comment •

edited

Loading