-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix template part variations registration subscription. #31772
Conversation
Size Change: +605 B (0%) Total Size: 1.32 MB
ℹ️ View Unchanged
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
"sideEffects": [ | |
"build-style/**", | |
"src/**/*.scss", | |
"src/navigation-link/index.js" |
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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
register_block_type_from_metadata( | |
__DIR__ . '/navigation-link', | |
array( | |
'render_callback' => 'render_block_core_navigation_link', | |
'variations' => array_merge( $built_ins, $variations ), | |
) | |
); |
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah I see you're already created #31761 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, thank you! I saw your PR registering them that way and it works great here. 😁
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That makes sense, thanks!
editorStore | ||
).__experimentalGetDefaultTemplatePartAreas(); | ||
export default function subscribeToCreateVatiations() { | ||
const unsubscribe = subscribe( () => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 build
from this PR and verify variations ("Header", "Footer", in the block inserter) show up as expected.Screenshots
Types of changes
Checklist:
*.native.js
files for terms that need renaming or removal).