-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Drag and drop: allow dragging to the beginning and end of a document #56070
Changes from all commits
e144126
11376a9
7635836
1fe9f39
f93ac8e
c6d84ac
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -411,6 +411,13 @@ export default function VisualEditor( { styles } ) { | |
: `${ blockListLayoutClass } wp-block-post-content` // Ensure root level blocks receive default/flow blockGap styling rules. | ||
} | ||
layout={ blockListLayout } | ||
__unstableDropZoneElement={ | ||
// When iframed, pass in the html element of the iframe to | ||
// ensure the drop zone extends to the edges of the iframe. | ||
isToBeIframed | ||
? ref.current?.parentNode | ||
: ref.current | ||
} | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Interesting, I'd have expected this to be There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yep! Yeah, interestingly enough it's There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Oooh I see, thanks! |
||
/> | ||
</RecursionProvider> | ||
</BlockCanvas> | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we want to make this private, prefixing is not the way anymore. I think we're now avoiding any new
__unstable
or__experimental
prefix.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just read your message above, you should use the lock/unlock API to mark this private. These days prefixing or not doesn't impact our policies for new APIs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the suggestion and extra context @youknowriad! I've had a go at doing this over in #56308, would love your feedback to see if that's what you had in mind. Due to how
useInnerBlocksProps
is written and used, the solution wound up being a little indirect.A potential alternative would be for us to stabilise
dropZoneElement
foruseInnerBlocksProps
andBlockList
if we're comfortable with it as an API. We could then still look into further follow-ups that abstract it away a little further for the post and site editors (or folks building custom block editors).There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we're making this private with the intention of removing it later and making the drop zone part of BlockCanvas as suggested above, my main question as to whether we should go one way or the other is if it would be useful at all to be able to set a drop zone in inner blocks. #26049 has been open for 3 years with no comments and few links to it, and the issue itself only links to one potential use case, so there doesn't seem to be a huge demand for such an API.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suppose the presence of that issue nudges me slightly toward "let's go for private for now" as it means we can then continue to explore the idea of allowing it for (likely 3rd party) container blocks in follow-up PRs (by digging into the potential use case). If we find it isn't useful, we can abandon it and go with making it part of
BlockCanvas
, and if it is useful, we can make the API public (and also potentially still explore making it an internal implementation detail ofBlockCanvas
). In both cases, it sounds like the private approach in #56308 could make for a decent interim place for now? I agree it doesn't sound like there's much demand for it for core container blocks to set their own element 🤔I don't feel strongly about which way we go, though, my main interest is getting us to an interim state we feel comfortable with for now 🙂
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A lot of folks complain generally about the drag and drop experience being clunky without really providing specifics or knowing the underlying reason. I don't think I did a good job of writing that issue, I should really have led with the problem rather than a solution, and I think that has meant not many comments.
There are a few blocks it happens with - Cover, Media & Text and Group. It happens any time there's padding around the inner blocks element.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, excellent. Thanks for confirming, Dan! That gives us something concrete to investigate here 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can reproduce with the Cover block. I've added a screengrab to #26049 (comment) to demonstrate the problem. I'm happy to pick up that task next as it's very related to this PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another update: given that solutions to #26049 will likely involve the
dropZoneElement
prop onuseInnerBlocksProps
, I've opened up another PR to stabilise thedropZoneElement
prop, over in #56313, as an alternative to making it private. We can likely go either way, but stabilising is the simpler code change.