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

FR: Async fetching prior to block registration #12232

Closed
ockham opened this issue Nov 22, 2018 · 2 comments
Closed

FR: Async fetching prior to block registration #12232

ockham opened this issue Nov 22, 2018 · 2 comments
Labels
[Feature] Block API API that allows to express the block paradigm. [Feature] Extensibility The ability to extend blocks or the editing experience [Status] Duplicate Used to indicate that a current issue matches an existing one and can be closed

Comments

@ockham
Copy link
Contributor

ockham commented Nov 22, 2018

Is your feature request related to a problem? Please describe.
While working on Jetpack Gutenberg blocks and plugins, we've recently found a few instances where some sort of async fetching of resources prior to block registration would come in handy. Examples include:

  1. Translation files. This is relevant when Gutenberg is used outside of wp-admin, e.g. in Calypso. We have a Calypso-specific workaround (Gutenberg: Load Jetpack block translations in Calypso synchronously Automattic/wp-calypso#28304) that takes care of loading translation files prior to loading Gutenberg, but we were wondering if more native tooling might be in order here. (We can't simply load translations after the editor and rely on React re-rendering strings afterwards for things like block names and descriptions that we pass to registerBlockType).
  2. Information relevant for block availability. We might want to register blocks conditionally, depending on criteria obtained from a REST API endpoint.

Describe the solution you'd like
A bit fuzzy, but maybe allow registerBlockType() (and registerPlugin()) to return a promise, and wait for that to be resolved?

Describe alternatives you've considered
For 1. -- see the workaround mentioned there.
For 2. -- In wp-admin, we're using wp_localize_script to set a global variable to contain relevant information
(None of which are particularly nice.)

/cc @sirreal @tyxla @simison @lezama @enejb

@gziolo
Copy link
Member

gziolo commented Nov 23, 2018

This is related to what I proposed to #2768. It all also heavily depends on #4116 which proposes to introduce a way to make blocks discoverable using some sort of API, which would allow to show them in the inserter but defer loading until you really need them.

@gziolo gziolo added [Feature] Block API API that allows to express the block paradigm. [Feature] Extensibility The ability to extend blocks or the editing experience labels Nov 23, 2018
@gziolo
Copy link
Member

gziolo commented Nov 23, 2018

@ockham, I moved your comment to #2768 (comment). Let's discuss there, thanks.

@gziolo gziolo closed this as completed Nov 23, 2018
@gziolo gziolo added the [Status] Duplicate Used to indicate that a current issue matches an existing one and can be closed label Aug 9, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Block API API that allows to express the block paradigm. [Feature] Extensibility The ability to extend blocks or the editing experience [Status] Duplicate Used to indicate that a current issue matches an existing one and can be closed
Projects
None yet
Development

No branches or pull requests

2 participants