Indicating context to innerBlocks

[glendaviesnz]

Following on from a question raised by @SiobhyB here about why it was not considered good practice to be adding new contexts to pass down to inner blocks, based on concerns raised here and here by @danr and @youknowriad.

I don't think the idea of adding the additional contexts in general is frowned upon, it was just that our use of them in the Gallery block refactor was seen as non-standard.

Dan's concern was that normally a context value was a used to pass down a standard attribute value from a parent container to child blocks, but in the Gallery block the values we were setting were not being serialized as attributes in the parent. They were instead just constant values that the parent block never actually used or manipulated itself - hence the suggestion of a contextConstant value to differentiate them from the standard use of context values.

Riad's view was that the Image block could just find out if it was part of a Gallery by using the data module instead of the parent block having to pass down a context to indicate this.

I think passing down the context values from the parent is a slightly less coupled approach than having to make the Image block aware of each of the different parent blocks that it might be part of, and how to behave with each parent. For example knowing what to do in a fixedHeight context is much less tightly coupled, and can be relevant to a range of different parent blocks, as apposed to knowing how to behave if my parent is a Gallery block.

I am also not sure that it is a big issue that some of these context may never be serialized into the parent block attributes, as there are a lot of cases where default attributes don't end up serialized in the block content if they aren't changed from the default.

I guess the key questions that need to be answered are:

• Is the likes of the Gallery blocks allowResize far enough outside how developers might expect a context value to behave to warrant a new API, eg. a contextConstant?
• Or ... in cases where a child block needs to behave differently for a given parent, should we in fact couple the block more tightly to the specific parent use cases rather than trying to use more generic context values to dictate behaviour?

[youknowriad]

For me, the main point here is conceptual: the allowResize is an attribute which generally means its value can be changed by the user while in this case it seems what we want is just to provide a static context and that's why I suggested the data module. I agree that the it adds coupling though.

Overall, I'm not too concerned with any of the options though. Starting with the coupling avoids extra attribute/API and doesn't prevent us from introducing it later, doing the opposite is harder.

[SiobhyB]

Thank you for these answers @glendaviesnz and @youknowriad! They're helpful.

For our goals on the mobile-side, instead of continuing to pursue the addition of context constants in #35510, I ended up taking a different approach and adding a new block support, __experimentalHideChildBlockControls, in #36371 and #36618. I was inspired to take this approach after seeing another block support, __experimentalExposeControlsToChildren, that is used for helping parent blocks customize their child blocks.

I'd be curious to hear whether this seems like an okay alternative to contexts or if there any better alternatives for meeting our goals.

[youknowriad]

I think having an API in the framework to change behavior of toolbars between parent and child blocks is definitely a need that has been floating for some time. We also has the "aborbToolbar" behavior I think @gziolo worked on. (cc @mtias ) I'd encourage to think about these APIs in a generic way, my questions here would be:

• why this is a mobile specific behavior, do we want these blocks to behave that way in web as well?
• can we think of other use-cases for other blocks? What about third-party blocks?

[SiobhyB]

I tried to address both of those questions in this reply on the PR here: #36371 (comment)

I'd be happy to create a PR to add __experimentalHideChildBlockControls to the web if there is a use case, but I'm not certain it'd be as necessary for the web for the reasons I outlined in the comment there.

I'm also keen to follow along with any other possible solutions, grateful again for the input 🙇‍♀️

[youknowriad]

There are a lot of benefits to using inner blocks but if the web version of the block doesn't use them (fairly common as inner blocks are relatively new) then there can be problems with getting the block's HTML output to match across web/mobile.
It's not always feasible to refactor the web version of the block to use inner blocks.
where native developers want to use inner blocks even though the web version doesn't use them.

I do think there's value in some API like this like I said above but these arguments doesn't sound compelling for me at first sight. You seem to suggest that blocks are using inner blocks to share UI across "simple blocks" and "advanced blocks" but you don't want the UI that comes with the block itself.

InnerBlocks have more impact that just controls, they also control the output so for me, there's no point in having the native and web version differ here, if one uses inner blocks, the other one should it as well otherwise it creates a lot of issues.

For reusability of UI between across blocks (caption for instance)... I think we should be looking at reusing components and not blocks.

(Maybe I'm misunderstanding though)

[SiobhyB]

You seem to suggest that blocks are using inner blocks to share UI across "simple blocks" and "advanced blocks" but you don't want the UI that comes with the block itself.

Ah, that's not what I intended to suggest. To hopefully clarify: For the project we're working on (a third-party gallery) we do want the image block's UI, we only need to customize certain aspects, including hiding its settings panel.

InnerBlocks have more impact that just controls, they also control the output so for me, there's no point in having the native and web version differ here, if one uses inner blocks, the other one should it as well otherwise it creates a lot of issues.

I agree it'd be perfect if inner blocks were used on both platforms, but we don't always have control over whether the web version of a block is refactored to use inner blocks or not, which is the case for the project we're working on.

Is your suggestion that native blocks should only use inner blocks if they're used on the web? If so, I'm sure that feedback would be welcomed by the mobile team. It's perhaps too late for the third-party gallery project (which is close to wrapping up) but we can make sure to share this thread as part of the project's wrap-up reflections.

For now, it seems like it may be best to stick with __experimentalHideChildBlockControls and iterate in the future.

[glendaviesnz]

__experimentalHideChildBlockControls

Nice, this certainly covers the use case in web for the inner Image blocks of the gallery as the allowResize=false context value is essentially saying "Hide the resize control if I am in a Gallery".

[SiobhyB]

Nice, glad to hear this could be an option for you! :)