-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Try extracting the block library into a separate module #6351
Conversation
b47f314
to
56c4b7f
Compare
} from '@wordpress/blocks'; | ||
|
||
// Hack to avoid the wrapping HoCs. | ||
import { BlockEdit } from '../../../blocks/block-edit'; |
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 still have a failing test, I suspected it's happening because of this but couldn't figure out exactly. Any idea @gziolo
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.
ContrastChecker
wasn't exported. Fixed with 6918595 :)
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.
Thanks ❤️
Related / conflicting: #6087 cc @kanishkdudeja |
I feel #6087 is more ambitious. Both require the same refactoring inside blocks (use imports from I think the current PR could be considered as the first iteration towards achieving #6087 |
core-blocks/index.js
Outdated
@@ -1,11 +1,16 @@ | |||
/** | |||
* Internal dependencies | |||
* External dependencies |
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.
Nit: WordPress
not External
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 like this PR a lot. I would vote to have it merged as soon as possible to so we could attack other aspects proposed in the linked issue.
@@ -78,3 +83,13 @@ export const registerCoreBlocks = () => { | |||
setDefaultBlockName( paragraph.name ); | |||
setUnknownTypeHandlerName( freeform.name ); | |||
}; | |||
|
|||
// Backwards compatibility | |||
wp.blocks.registerCoreBlocks = () => { |
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.
Interesting workaround :)
@@ -61,7 +63,7 @@ const FONT_SIZES = { | |||
larger: 48, | |||
}; | |||
|
|||
const autocompleters = [ blockAutocompleter, ...defaultAutocompleters ]; | |||
const autocompleters = [ blockAutocompleter, userAutocompleter ]; |
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 should be improved with #6357.
import serialize from '../api/serializer'; | ||
import { getBlockTypes } from '../api/registration'; | ||
import { registerCoreBlocks } from '../'; | ||
import { parse as grammarParse } from '../../blocks/api/post.pegjs'; |
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.
Just noting that it is imported from blocks
.
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, I know, it seems fine for a test. I didn't want to expose the grammar parsing as an official API in the blocks module.
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.
Another question is if those tests need to use low-level functions? Maybe there is a simpler way to achieve the same level of confidence.
@@ -1,5 +1,9 @@ | |||
Gutenberg's deprecation policy is intended to support backwards-compatibility for two minor releases, when possible. The current deprecations are listed below and are grouped by _the version at which they will be removed completely_. If your plugin depends on these behaviors, you must update to the recommended alternative before the noted version. | |||
|
|||
## 3.0.0 | |||
|
|||
- `wp.blocks.registerCoreBlocks` function removed. Please use `wp.coreBlocks.registerCoreBlocks` instead. |
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.
Question is if we still want to keep registerCoreBlocks
or rather refactor further codebase to tackle it differently :)
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, Could be useless with the proposed "registerBlock" action, but let's iterate in a separate PR
d0f0509
to
0761e09
Compare
@@ -8,7 +8,7 @@ import path from 'path'; | |||
/** | |||
* Internal dependencies | |||
*/ | |||
import { registerCoreBlocks } from '../../../../library'; | |||
import { registerCoreBlocks } from '../../../../../core-blocks'; |
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.
Should we move this test to core-blocks
? It seems to be very dependent on them.
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, maybe I'll defer to @iseulde and probably leave this to a separate task?
Also, maybe we could improve the core block tests we have now. They are all pretty equivalent relying on blockEditRender
and test a snapshot. I think we should improve them one by one and just call the edit
, save
, transforms
etc... without any mocking unless we can't do that for edit
for a reason I'm missing?
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.
Some things to further improve
- There is one test suite with integration tests which might better fit as part of
core-blocks
module. - There are 4
editor
tests which depend oncore-blocks
module. In the first place, they shouldn't depend on bocks at all. We should investigate it further and try to find a way to make it work differently. This has been an issue for a while already.
Other than that everything looks solid. I'm giving 👍
0761e09
to
db6059d
Compare
* Try extracting the block library into a separate module * Add a deprecation message * Blocks: Do not expose default autocompleters * Fix php unit tests * Fix dependencies comment
related #6275
This PR extracts the block library to a separate module. If you want to understand the reasoning behind the PR, please read #6275