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

Group block: When in its initial setup state, it's not a container and can't be dragged into #49256

Closed
jasmussen opened this issue Mar 22, 2023 · 3 comments · Fixed by #49361
Closed
Assignees
Labels
[Block] Group Affects the Group Block [Type] Bug An existing feature does not function as intended

Comments

@jasmussen
Copy link
Contributor

When a group block is inserted empty, it comes with a setup state allowing you to choose between the default flow group, a row, and a stack variation. In this state, the group looks like a group container in the list view, but it isn't, so I cannot drag any blocks into this container. GIF showing this:

drag into group

Filing this as a bug, as I would expect dragging a block into the group, even in its setup state, to have the dragged block nest under it.

Related: #39064

@jasmussen jasmussen added [Type] Bug An existing feature does not function as intended [Block] Group Affects the Group Block labels Mar 22, 2023
@richtabor
Copy link
Member

100%. This seems an easy win.

@richtabor richtabor added the Needs Dev Ready for, and needs developer efforts label Mar 22, 2023
@andrewserong
Copy link
Contributor

I did a little digging into this one, and it's a little more complex than I realised at first glance. Just jotting down a few technical notes. Feel free to ignore these, but I thought I'd write them down in case it helps anyone else looking. If no-one beats me to it, I'll look at seeing if I can put up a fix next week!

  • The list view calls canInsertBlocks here to determine whether to allow the dragged blocks as children.
  • Then the canInsertBlockTypeUnmemoized function checks getBlockListSettings for the Group block here. A Group block that is in its placeholder state has no entry in the block list settings.
  • When a Group block is in its placeholder state, it doesn't render out the result from useInnerBlocksProps, which means that InnerBlocks is never rendered.
  • InnerBlocks is responsible for calling useNestedSettingsUpdate here which calls updateBlockListSettings here. This is how a block that renders its inner blocks winds up with an entry in the block list settings.

So, long story short — I think if we were to try moving the call to useNestedSettingsUpdate up so that it gets called when useInnerBlocksProps is used, instead of when InnerBlocks is rendered, then we might be able to get the block list settings updated for container blocks when they're inserted / in their placeholder state, rather than just when they already have inner blocks. That's my idea at the moment, anyway 🙂

@andrewserong
Copy link
Contributor

I've got a fix up in #49361 — it works by ensuring that useInnerBlocksProps and its children are output when the block is in the placeholder state. Seems to work pretty well so far 🤞

@priethor priethor removed the [Status] In Progress Tracking issues with work in progress label May 11, 2023
@priethor priethor removed the Needs Dev Ready for, and needs developer efforts label Jul 24, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Block] Group Affects the Group Block [Type] Bug An existing feature does not function as intended
Projects
Status: Done
Development

Successfully merging a pull request may close this issue.

4 participants