Skip to content
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

Merged
merged 5 commits into from
Apr 25, 2018

Conversation

youknowriad
Copy link
Contributor

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

@youknowriad youknowriad added the Framework Issues related to broader framework topics, especially as it relates to javascript label Apr 23, 2018
@youknowriad youknowriad self-assigned this Apr 23, 2018
@youknowriad youknowriad requested a review from a team April 23, 2018 09:48
@youknowriad youknowriad force-pushed the try/extract-block-library branch from b47f314 to 56c4b7f Compare April 23, 2018 09:49
} from '@wordpress/blocks';

// Hack to avoid the wrapping HoCs.
import { BlockEdit } from '../../../blocks/block-edit';
Copy link
Contributor Author

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

Copy link
Member

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 :)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks ❤️

@aduth
Copy link
Member

aduth commented Apr 23, 2018

Related / conflicting: #6087 cc @kanishkdudeja

@youknowriad
Copy link
Contributor Author

youknowriad commented Apr 23, 2018

I feel #6087 is more ambitious. Both require the same refactoring inside blocks (use imports from @wordpress/blocks). #6087 tries to build each block in a separate script/stylesheet while this one just keep them in a single stylesheet.

I think the current PR could be considered as the first iteration towards achieving #6087

@@ -1,11 +1,16 @@
/**
* Internal dependencies
* External dependencies
Copy link
Member

@gziolo gziolo Apr 23, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: WordPress not External

Copy link
Member

@gziolo gziolo left a 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 = () => {
Copy link
Member

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 ];
Copy link
Member

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';
Copy link
Member

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.

Copy link
Contributor Author

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.

Copy link
Member

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.
Copy link
Member

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 :)

Copy link
Contributor Author

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

@youknowriad youknowriad force-pushed the try/extract-block-library branch from d0f0509 to 0761e09 Compare April 24, 2018 08:22
@@ -8,7 +8,7 @@ import path from 'path';
/**
* Internal dependencies
*/
import { registerCoreBlocks } from '../../../../library';
import { registerCoreBlocks } from '../../../../../core-blocks';
Copy link
Member

@gziolo gziolo Apr 24, 2018

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.

Copy link
Contributor Author

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?

Copy link
Member

@gziolo gziolo left a 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 on core-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 👍

@youknowriad youknowriad force-pushed the try/extract-block-library branch from 0761e09 to db6059d Compare April 25, 2018 07:42
@youknowriad youknowriad merged commit eabf682 into master Apr 25, 2018
@youknowriad youknowriad deleted the try/extract-block-library branch April 25, 2018 07:48
nuzzio pushed a commit to nuzzio/gutenberg that referenced this pull request Apr 25, 2018
* 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Framework Issues related to broader framework topics, especially as it relates to javascript
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants