Description
openedon Nov 19, 2020
Description
With #26655 it's possible to use store definitions as param for select
/useSelect
/withSelect
and dispatch
/useDispatch
/withDispatch
API method calls exposed from @wordpress/data
. It resolves the issue with the need to use unscoped import statements for packages that define stores used as explained in #8981 (comment):
To be clear, all packages that use a given datastore should import it in the entry point by convention. It's something that could be improved because if it's missed, it might indeed cause errors. At the moment, there is no simple way to validate it happens. Example:
gutenberg/packages/edit-post/src/index.js
Lines 4 to 10 in 87fa5f5
The next step is to use newly exposed store
definitions from the corresponding packages similar to how it was applied to the store
exposef from @wordpress/viewport
in #26655. Example:
diff --git a/packages/interface/src/components/complementary-area/index.js b/packages/interface/src/components/complementary-area/index.js
index 56ad63c601e1..f35fcf9d14bc 100644
--- a/packages/interface/src/components/complementary-area/index.js
+++ b/packages/interface/src/components/complementary-area/index.js
@@ -11,6 +11,7 @@ import { useDispatch, useSelect } from '@wordpress/data';
import { __ } from '@wordpress/i18n';
import { check, starEmpty, starFilled } from '@wordpress/icons';
import { useEffect, useRef } from '@wordpress/element';
+import { store as viewportStore } from '@wordpress/viewport';
/**
* Internal dependencies
@@ -104,10 +105,8 @@ function ComplementaryArea( {
isActive: _activeArea === identifier,
isPinned: isItemPinned( scope, identifier ),
activeArea: _activeArea,
- isSmall: select( 'core/viewport' ).isViewportMatch(
- '< medium'
- ),
- isLarge: select( 'core/viewport' ).isViewportMatch( 'large' ),
+ isSmall: select( viewportStore ).isViewportMatch( '< medium' ),
+ isLarge: select( viewportStore ).isViewportMatch( 'large' ),
};
},
[ identifier, scope ]
The goal is to make it simpler to maintain dependencies between packages to avoid bugs when consuming from npm. The other benefit is that we will prevent cyclic dependencies in the early stages of development.
Tasks
This is the list of store names that should be replaced with their newly introduced store definitions:
-
core
-
core/annotation
(Annotations: Replace store name string with exposed store definition #28156 @rafaelgalani) -
core/block-directory
(Block Directory: Replace store name string with exposed store definition #27178 @rafaelgalani) -
core/block-editor
-
core/blocks
(Blocks: Replace store name string with exposed store definition #27336 @rafaelgalani ) -
core/data
-
core/edit-navigation
(Edit Navigation: Replace store name string with exposed store definition #27182, Edit Navigation: Replace remaining store name string with constant #27281 @rafaelgalani) -
core/edit-post
(Edit Post: Replace store name string with exposed store definition #27414 @rafaelgalani) -
core/edit-site
(Site Editor: Replace core/edit-site store name with store object #28695 @david-szabo97) -
core/edit-widgets
(Edit Widgets: Replace store name string with exposed store definition #28044 @rafaelgalani) -
core/editor
-
core/interface
(Interface: Replace store name string with exposed store definition #28041 @rafaelgalani) -
core/keyboard-shortcuts
(Keyboard Shortcuts: Replace store name string with exposed store definition #27355 @bosconian-dynamics) -
core/notices
(Code Quality: Use store definition instead of string for notices packages #27548 @gziolo) -
core/reusable-blocks
(Reusable Blocks: Change from store name provided as a string to store definition #27094 @grzim) -
core/rich-text
(Rich Text: Replace store name string with exposed store definition #27820 @rafaelgalani) -
core/viewport
(@gziolo)