Fix template part variations registration subscription.#31772
Fix template part variations registration subscription.#31772Addison-Stavlo wants to merge 3 commits intotrunkfrom
Conversation
|
Size Change: +605 B (0%) Total Size: 1.32 MB
ℹ️ View Unchanged
|
gwwar
left a comment
There was a problem hiding this comment.
import './variations'; is ignored by the non-dev build process as it does not see any use from the import. Instead we can import a function and call it from the code.
If there are side-effects, we can let webpack know by updating the sideEffects property:
gutenberg/packages/block-library/package.json
Lines 27 to 30 in ff4c3c4
https://webpack.js.org/guides/tree-shaking/#mark-the-file-as-side-effect-free
| const unsubscribe = subscribe( () => { | ||
| const definedVariations = select( | ||
| editorStore | ||
| ).__experimentalGetDefaultTemplatePartAreas(); |
There was a problem hiding this comment.
I'm not sure if it'd be useful in this case, but just wanted to note it's possible to register variations via register_block_type_from_metadata eg
gutenberg/packages/block-library/src/navigation-link/index.php
Lines 325 to 331 in ff4c3c4
There is still some JS needed for icon setting/isActive logic, since there's a bit more API work to be done to help serialize that.
There was a problem hiding this comment.
Yes, thank you! I saw your PR registering them that way and it works great here. 😁
There was a problem hiding this comment.
oddly that approach doesn't seem to work with everyones testing. For some reason a couple folks seem to have that filter run before the actual php side registers the variations (?)- #31761 (comment)
There was a problem hiding this comment.
That makes sense, thanks!
| editorStore | ||
| ).__experimentalGetDefaultTemplatePartAreas(); | ||
| export default function subscribeToCreateVatiations() { | ||
| const unsubscribe = subscribe( () => { |
There was a problem hiding this comment.
The global subscribe/select/dispatch is something we avoid using as much as we can. For what reason are we subscribing here? I assume we're waiting for something but what is this thing we're waiting for here?
(We should probably document this somewhere)
There was a problem hiding this comment.
Its waiting for the template part area definitions from the php side to initialize in the editor store.
Im looking at refactoring to avoid subscribe and register these variations from the server side here -#31761
There was a problem hiding this comment.
It looks like that fix is hit or miss for some folks, still have to investigate its inconsistencies.
For now, I would think this subscribe should be alright. Technically its only present until the store initializes.
There was a problem hiding this comment.
It looks like that fix is hit or miss for some folks, still have to investigate its inconsistencies.
Nm, that seems to be a WP version issue that we should be able to work around with fallbacks.
|
@youknowriad would it be possible to include this fix in the 10.6 point release (if any)? |
|
closing this in favor of #31761 |
Description
Fixes template part variations from not being present in non-dev builds.
import './variations';is ignored by the non-dev build process as it does not see any use from the import. Instead we can import a function and call it from the code.#31761 fixes this issue as well but also explores refactoring the registration to avoid the initial store subscription. At this point Im not sure if the refactor makes more sense or not, but I explored this refactor before figuring out the root cause of the bug.
How has this been tested?
run
npm run buildfrom this PR and verify variations ("Header", "Footer", in the block inserter) show up as expected.Screenshots
Types of changes
Checklist:
*.native.jsfiles for terms that need renaming or removal).