Size Change: 0 B

Total Size: 1.2 MB

_{compressed-size-action}

This appears to be failing in other sections, too:

• Multi-entity save flow › Site Editor › Should be enabled after edits
• Multi-entity editor states › Multi-entity edit › should only dirty the parent entity when editing the parent
• Template Part › Template part block › Should load customizations when in a template even if only the slug and theme attributes are set.

I assume those are valid, and the insertion will need to be fixed in those places as well? Or does the test/test helper need to be changed?

• editor states › Multi-entity edit › should only dirty the parent entity w

They should be legitimate failures. I'll investigate further.

• editor states › Multi-entity edit › should only dirty the parent entity w

They should be legitimate failures. I'll investigate further.

I'm not certain how all the pieces come together yet, but the behavior of the inserter when using the experimental Full Site editing feature does not work the same. It does not close when a block is added. These tests run within the context of that feature. Since the inserter doesn't close for Full Site editing, it technically shouldn't test it. I wonder if it's purposeful that the inserter doesn't close in FSE.

Adding XPath as a second argument seems a little bit weird to me. Since it encourages the developer to know and test the implementation details rather than what end users see. Do we have a better solution to this? Or am I missing some additional context? 🤔

That's a good point. Alternatives are definitely welcome.

I wouldn't expect most tests to pass in the xPath to the button. It's more a solution for the block directory package as it sits in the experimental menu slot.

1. We could refactor the insertBlock function:

   • Pull out the button related logic into a function
   • Pull out the page.waitForFunction check

2. Create ainsertBlockDirectoryBlock function.

   • We have already included insertPattern & insertReusableBlock.

The code is fairly repetitive and probably could use some 'drying' up.

@StevenDufresne I'd prefer the second solution, a insertBlockDirectoryBlock function.

I won't be too worried about repetitive code though, even though they have similar functionality, they are also very different. Let's not prematurely optimize it unless we really need to.

We can even rename the original insertBlock function to something like insertBlockFromEditor, and name our new function to insertBlockFromBlockDirectory, in order to further differentiate both and make them clearer.

What's your thought on this? Am I missing some context :)?