Lighter Block: allow block types to render their own wrapper #19701
Conversation
| ); | ||
| } ); | ||
|
|
||
| const elements = [ 'p', 'div' ]; |
There was a problem hiding this comment.
To do: add list of all block level elements.
There was a problem hiding this comment.
|
I was just wondering how this might be approached and this is super cool to see! |
ellatrix
force-pushed
the
try/block-wrapper
branch
from
374b93f to
6bd8b7d
Compare
ellatrix
force-pushed
the
try/block-wrapper
branch
from
99a1617 to
eb5ee1f
Compare
|
I wonder if there could be overlap between these new block wrapper elements and the |
|
@chrisvanpatten Could you elaborate? |
| @@ -18,6 +18,10 @@ describe( 'block mover', () => { | |||
| // Select a block so the block mover is rendered. | |||
| await page.focus( '.block-editor-block-list__block' ); | |||
|
|
|||
| // Move the mouse to show the block toolbar | |||
| await page.mouse.move( 0, 0 ); | |||
| await page.mouse.move( 10, 10 ); | |||
There was a problem hiding this comment.
This is necessary because the typing observer does not set isTyping to false when a text field receives focus. Perhaps this can be adjusted in a follow-up PR.
ellatrix
force-pushed
the
try/block-wrapper
branch
7 times, most recently
from
db4f5ed to
1600346
Compare
ellatrix
added
the
[Feature] Block API
ellatrix
requested review from
ajitbohra,
gziolo,
jorgefilipecosta,
nerrad,
ntwb,
Soean,
talldan and
youknowriad
as code owners
| await editorPage.keyboard.type( 'content 2' ); | ||
| await editorPage.keyboard.press( 'End' ); | ||
| await editorPage.keyboard.press( 'Backspace' ); | ||
| await editorPage.keyboard.type( '2' ); |
There was a problem hiding this comment.
I changed the above test because it was failing specifically on Travis and not when testing manually or running the e2e tests locally. I throttled CPU, but the tests still passed locally. I've looked into this issue for over a day, and couldn't find what's causing the problem.
I did find a reduced test case that fails:
it( 'test', async () => {
await page.keyboard.type( 'title 1' );
await page.keyboard.press( 'Tab' );
await page.keyboard.type( 'content 1' );
await page.click( '.editor-post-title__input' );
await pressKeyWithModifier( 'primary', 'a' ); // <== Remove this line and the test passes...
await page.keyboard.type( 'title 2' );
await page.keyboard.press( 'Tab' );
await pressKeyWithModifier( 'primary', 'a' );
await page.keyboard.type( 'content 2' );
expect( await getEditedPostContent() ).toMatchSnapshot();
} );So it looks like it has something to do with Cmd+A in the title, before doing the same in a paragraph. It's worth mentioning that we are emulating Cmd+A, so maybe it has to do with that and a change to the paragraph block.
|
Just pinging some theme folks for more eyes, @kjellr and @allancole. |
|
WOW. This PR sounds excellent! Especially, if the purpose is to make writing CSS rules for the frontend and the backend identical. I agree that having this initially be an opt-in solution will give themers time to adapt to the change and get things right before it becomes the default. Super exciting :-) |
ellatrix
force-pushed
the
try/block-wrapper
branch
from
8d3b156 to
9d23cb0
Compare
|
Size Change: -189 B (0%) Total Size: 865 kB
ℹ️ View Unchanged
|
|
Thanks for the positive feedback! Let's merge, iterate, and continue work in #19910. |
|
Great work here. Looking forward to see how this translates to all blocks (and potentially float refactoring) |
|
👏 ᕕ( ᐛ )ᕗ |
The behavior of manipulating blocks in the recent G2 refresh regressed slightly in #19701, this PR addresses that. Specifically, the blue border is meant to indicate _block focus_, i.e. when it is present you can press Delete to remove the block. It is not meant to indicate the block boundaries when focus is inside text.
The behavior of manipulating blocks in the recent G2 refresh regressed slightly in #19701, this PR addresses that. Specifically, the blue border is meant to indicate _block focus_, i.e. when it is present you can press Delete to remove the block. It is not meant to indicate the block boundaries when focus is inside text.
youknowriad
added
the
Needs Dev Note
|
Added the "Needs Dev Note" label. I believe we need to document this change (update in the different blocks DDOM structure) for devs even if we don't make the API stable yet. |
|
This experimental API is still being revised a bit, so it seems premature for a Dev Note. |
ellatrix
removed
the
Needs Dev Note
Description
This is still a work in progress as there are some final details to be figured out.
This is the final step in lightening the block DOM. This PR allows block types to opt in to rendering their own wrapper.
Why?
getEditWrapperPropssetting. Blocks can now apply the props themselves. The could be useful for e.g. alignment. A block can now set proper classes instead ofdata-alignattributes, which will make it easier for themes to style the editor. Currently, for many themes, even the latest core theme, alignment in the editor doesn't reflect the alignment on the front-end.InnerBlocksDOM, it will be possible to build more complex block that need a semantic relationship with its child blocks. E.g. for a table and list block, the table cells and list items need to be direct children of the parent block, so these blocks need to render their own wrapper.The above is much nicer to handle than many layers of nested
divelements.I believe that allowing simple block markup in the editor will be essential for full site editing and theming.
Implementation notes
The way I'm approaching this is a bit inspired by
react-spring. I created a base block component that is provided with the context it needs to render and the props that the blockEditcomponent may pass. For every element that can act as a block wrapper, I created a wrapped component as properties of the base component, so you can haveBlock.p,Block.div,Block.figureetc.This works well together with
RichTexttoo. You can pass the component through thetagNameprops, andRichTextwill render the wrapper.How has this been tested?
Screenshots
Types of changes
Checklist: