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

Block API: Extend the block registration API technical proposal #16209

Closed
14 tasks done
gziolo opened this issue Jun 18, 2019 · 5 comments
Closed
14 tasks done

Block API: Extend the block registration API technical proposal #16209

gziolo opened this issue Jun 18, 2019 · 5 comments
Labels
[Feature] Block API API that allows to express the block paradigm. [Feature] Block Directory Related to the Block Directory, a repository of block plugins Framework Issues related to broader framework topics, especially as it relates to javascript [Type] Tracking Issue Tactical breakdown of efforts across the codebase and/or tied to Overview issues.

Comments

@gziolo
Copy link
Member

gziolo commented Jun 18, 2019

Continues the work toward server-side awareness of block types: #2751 and follow-up for #13693.

Development Roadmap

This highly related to core blocks and the way they integrate with WordPress.

Proposals

There are some items that weren't included in the initial proposal which should be processed and included based on the further discussion. Many of the items discussed are very WordPress specific and therefore we need to find a good way to make it explicit what is truly platform agnostic and what is meant to be work only when using it with WordPress.

New screenshot property

From @perandre in #13693 (comment)

Implementing a standard for block screenshot would be valuable. Size, format, what it should contain and not contain.

This seems like a good addition in the context of the block discovery when it isn't installed.

Auto-discover of block.json metadata file

The original discussion sparked by a comment from @moorscode in #13693 (comment).

WordPress automatically discovers all the block.json files in the plugin/core blocks folder and registers the corresponding block types. These block types are made available through the block registry PHP class and the blocks scripts and styles are added as dependencies to the wp-block-library script and style handles.

This is WordPress specific and that's why it wasn't included in the first version. We definitely want to have it implemented but this might be added after some code exploration which will make it easier to solidify.

Client-side properties referenced as files

This was removed from the initial proposal (see this commit: 5ec9cd9) as noted in #13693 (comment):

I removed the following properties from this document:

  • save
  • edit
  • transforms
  • deprecated

The idea was to keep them referenced from block.json file but this seemed to be a bit confusing in relation to the assets you would normally enqueue in WordPress. This is something we will revisit later as it doesn't seem to be essential for the Block Directory project.

I think we should continue exploring this idea as this could give us some ways to optimize the size of assets loaded by deferring the moment when those files are loaded on the page. In particular deprecated and edit fields loaded only when they are actually used could bring some performance optimizations in case of blocks heavy loaded with JavaScript logic.

Extend flexibility of parent property

Also filed in #30679 by @priethor.

See comment from @aduth in #13693 (comment):

We should create a follow-on issue for this. That said, it's not directly mentioned as being possible in this RFC. Which begs the question: Should it be, if we're saying it ought to be possible?

Consider adding renderTemplate property

See comment from @spacedmonkey in #13693 (comment):

Current the render callback is a function call. How would it work as a file? Why not make it renderTemplate but still allow for renderCallback. Function calls, should be a method in a class or be namespaced, which wouldn't really work in a another file.

ACF blocks, has a rendercallback / render template in it's block definitions.

There is also another thread started by @spacedmonkey in #13693 (comment) which expands on this topic.

@gziolo gziolo added [Feature] Block API API that allows to express the block paradigm. [Type] RFC Framework Issues related to broader framework topics, especially as it relates to javascript [Feature] Block Directory Related to the Block Directory, a repository of block plugins labels Jun 18, 2019
@aduth aduth added the [Type] Tracking Issue Tactical breakdown of efforts across the codebase and/or tied to Overview issues. label Jun 25, 2019
@gziolo gziolo changed the title Extend the block registration API technical proposal Block API: Extend the block registration API technical proposal Jun 4, 2020
@tellyworth tellyworth mentioned this issue Jun 23, 2020
20 tasks
@paaljoachim
Copy link
Contributor

Should this issue be closed, Greg @gziolo ?

@gziolo
Copy link
Member Author

gziolo commented Jan 13, 2021

No, there are open tasks.

@gziolo
Copy link
Member Author

gziolo commented Apr 14, 2021

Consider adding renderTemplate property

@ryelle, I was thinking about this proposal again and it might be a great fit for extending what Block Directory can support. If we would ensure that the file you reference outputs the HTML for the block on the frontend and it can only use the same attributes that render_callback accepts. In general, render_template would work as a more limited version of render_callback.

@gziolo
Copy link
Member Author

gziolo commented May 4, 2021

I consider all items from to-do list as done. Let's close this issue and continue working on individual enhancements separately:

@gziolo gziolo closed this as completed May 4, 2021
@mtias
Copy link
Member

mtias commented May 4, 2021

Nice work driving these @gziolo

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] Block Directory Related to the Block Directory, a repository of block plugins Framework Issues related to broader framework topics, especially as it relates to javascript [Type] Tracking Issue Tactical breakdown of efforts across the codebase and/or tied to Overview issues.
Projects
None yet
Development

No branches or pull requests

5 participants