Description
We replaced hardcoded store keys with imported store definitions with #27088 and all related PRs. However, there are still several places where we have hardcoded store names, but they require some architectural changes because the stores used in the code are present conditionally depending on the execution context.
There is a group of items to look at raised for the code used with native mobile apps covered in #27751 issue.
In the web part of the universe, we still have two places that need more work:
Discovered in #32801:
|
// FIXME: @wordpress/block-library should not depend on @wordpress/editor. |
|
// Blocks can be loaded into a *non-post* block editor. |
|
// eslint-disable-next-line @wordpress/data-no-store-string-literals |
|
const editorSelectors = select( 'core/editor' ); |
|
if ( editorSelectors ) { |
Discovered in #32537
|
// FIXME: @wordpress/server-side-render should not depend on @wordpress/editor. |
|
// It is used by blocks that can be loaded into a *non-post* block editor. |
|
// eslint-disable-next-line @wordpress/data-no-store-string-literals |
|
const coreEditorSelect = select( 'core/editor' ); |
|
if ( coreEditorSelect ) { |
There are more places that require a fix as updated in #32866. It's related to the following core blocks:
- Table of Contents
- Template Part
My initial thought is that we should seek a way to consuming the data through block context. Although, it isn't clear how that could look in practice. I would start exploration with learning what shared data is available in PHP like the $post object or all the information that helps to decide what type of posts should be displayed on a given page. At least for the two cases referenced in this issue, the only data that is necessary can be retrieved from the currently edited $post object.
Description
We replaced hardcoded store keys with imported store definitions with #27088 and all related PRs. However, there are still several places where we have hardcoded store names, but they require some architectural changes because the stores used in the code are present conditionally depending on the execution context.
There is a group of items to look at raised for the code used with native mobile apps covered in #27751 issue.
In the web part of the universe, we still have two places that need more work:
Discovered in #32801:
gutenberg/packages/block-library/src/calendar/edit.js
Lines 51 to 55 in ee69822
Discovered in #32537
gutenberg/packages/server-side-render/src/index.js
Lines 19 to 23 in 58aab25
There are more places that require a fix as updated in #32866. It's related to the following core blocks:
My initial thought is that we should seek a way to consuming the data through block context. Although, it isn't clear how that could look in practice. I would start exploration with learning what shared data is available in PHP like the
$postobject or all the information that helps to decide what type of posts should be displayed on a given page. At least for the two cases referenced in this issue, the only data that is necessary can be retrieved from the currently edited$postobject.