Determine canonical way to declare optional dependency on store from another package.

[ZebulanStanphill]

What problem does this address?

In several places of the codebase, you can see something like this:

gutenberg/packages/block-library/src/calendar/edit.js

Lines 51 to 54 in 6821d29

	// 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' );

Technically, there's no bug to "fix" in this exact use case. editorSelectors will simply be null when the core/editor store is not available, and the code that follows handles the null case.

Still, it is awkward to access the store via string literal rather than an imported store object, and one would think that the former should be deprecated eventually. It seems like the ideal solution would be to somehow declare an optional dependency on the @wordpress/editor package, importing its store export if available, and defaulting to null (or undefined) otherwise.

But how would this be done in practice? A normal ESM import declaration doesn't handle optional dependencies.

What is your proposed solution?

Dynamic imports exist, and it looks like they may be the solution. However, I do not know if our current build tooling would work with them, and them being async may pose a problem. I picture using them like so:

// This will either be the store or null.
const editorStore = await import('@wordpress/editor')
	.then(result => result.store)
	.catch(_err => null)

I'm curious what other people think of this idea.

[gziolo]

Hello, there already is a similar issue tracked in the repository: #32842.

The other reason we use strings when referencing stores is to avoid explicitly declaring a dependency which would create cyclic dependencies between packages. However, in that case, it’s an issue with the code architecture.

For the case, you explicitly described, one way to resolve the issue would be to decouple context-based dynamic values from the block. One idea that might help “dynamic tokens” is coming from @dmsnell. You can check the related discussions at #39831.

[ZebulanStanphill]

Thanks, I couldn't find the aforementioned issues by searching. Good to know I'm not the first to bring this up, haha.

[gziolo]

It still would be valuable to get your feedback on the issue I shared. Thank you for opening the issue. I know it’s getting harder to locate previously reported issues.

[dmsnell]

one would think that the former should be deprecated eventually

one would think correctly 😉 not sure when, but I believe we already want to have people pass in the store object itself already.