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.

Sign up for GitHub

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

Jump to bottom

Try avoiding the deprecated findDOMNode API from DropZone Provider #11168

Merged
merged 2 commits into from
Nov 1, 2018
Merged

Try avoiding the deprecated findDOMNode API from DropZone Provider #11168

merged 2 commits into from
Nov 1, 2018

Conversation

youknowriad
Copy link
Contributor

While I don't like adding DOM nodes for nothing (we can probably avoid these nodes if we use hooks), I don't see another way to remove findDOMNode and keep the same functionality.

Thoughs @aduth @gziolo

@youknowriad youknowriad requested a review from a team October 28, 2018 09:20
@youknowriad youknowriad added the [Type] Code Quality Issues or PRs that relate to code quality label Oct 28, 2018
aduth
aduth requested changes Oct 29, 2018
View reviewed changes
Copy link
Member

@aduth aduth left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This breaks "click below to add" behavior, because of the added div (the WritingFlow relies on 100% height of its full ancestry)

packages/components/src/drop-zone/provider.js Outdated
@@ -212,7 +209,7 @@ class DropZoneProvider extends Component {
const { position, hoveredDropZone } = this.state;
const dragEventType = getDragEventType( event );
const dropZone = this.dropZones[ hoveredDropZone ];
const isValidDropzone = !! dropZone && this.container.contains( event.target );
const isValidDropzone = !! dropZone && this.container.current.contains( event.target );
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If this is the only instance of the DOM reference, could we just have onDrop be bound as an event handler to the wrapping div? I guess the main difference is the lack of stopPropagation / preventDefault on all other drops on the page, which I could see as equally "correct" and "annoying" (in cases of mis-drops causing navigation).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, with use of Slot/Fill, using DOM Element#contains isn't guaranteed to be accurate anyways.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If this provider is at the top-level, is there really any point to checking this at all?

Assuming we're tracking hover for the relevant dropZone, that seems to be an extra (better?) level of certainty to where the drop is taking place.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, there is, this fixes a bug where drag and dropping to the media library creates the image twice. (It's also caught by the dropzones in the editor even if the the dragged item is outside the editor)

Copy link
Member

@aduth aduth Oct 29, 2018 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you recall the issue / pull request for it? This sounds a bit fishy...

Makes me wonder if there's possibly something going on with StrictMode double-rendering (#6466 (comment))

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So the original PR fixing this issue is this one #5432

but I recall it being refactored to use the container technique in another PR. Looking

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like it was introduced here #4115 but I don't recall the exact reasons :( Will investigate more.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So yes, in my testing, it is still necessary to avoid the double upload issue.

@aduth
Copy link
Member

aduth commented Oct 29, 2018

There was meant to be an E2E test covering the broken behavior. Apparently it's not working so well.

Originally: https://github.com/WordPress/gutenberg/pull/5991/files#diff-708f5078fca40c1d3de2c973ddc5e255

Current:

gutenberg/test/e2e/specs/adding-blocks.test.js

Lines 17 to 18 in a2f81fa

// Click below editor to focus last field (block appender)
await page.click( '.editor-writing-flow__click-redirect' );

@aduth aduth mentioned this pull request Oct 29, 2018
Merged
@youknowriad
Copy link
Contributor Author

I updated the PR. I fixed the e2e test to break properly if needed. And I also fixed the issue using CSS, I don't have a better alternative at the moment.

@aduth
Copy link
Member

aduth commented Nov 1, 2018 •
edited
Loading

Aside: I really wish display:contents was better supported. It would be perfect for these sorts of wrappers.

@youknowriad youknowriad mentioned this pull request Nov 1, 2018
Closed
12 tasks
@aduth
Copy link
Member

aduth commented Nov 1, 2018

Maybe I'm missing something? I don't see the issue resolved by #5432 with c869c81.

@youknowriad
Copy link
Contributor Author

@aduth I suspect it's because the drop event is triggered in that case because the div container is rendered behind the modal. I'm checking the event.target which is a bit different.

@youknowriad
Copy link
Contributor Author

Or are you saying it's fixed? Because I can't reproduce in my testing, your commit seems fine.

@aduth
Copy link
Member

aduth commented Nov 1, 2018

Right, c869c81 is what I was trying to suggest, and appears to work well enough. Will approve if it's agreeable to you.

@youknowriad youknowriad merged commit 506187b into master Nov 1, 2018
@youknowriad youknowriad deleted the try/remove-find-dom-node branch November 1, 2018 17:06
daniloercoli added a commit that referenced this pull request Nov 1, 2018
@daniloercoli
Merge branch 'master' of https://github.com/WordPress/gutenberg into …
4e7dd62 
…rnmobile/port-quote-block-step-1

* 'master' of https://github.com/WordPress/gutenberg: (22 commits)
  Add removed periods to block descriptions. (#11367)
  Remove findDOMNode usage from the inserter (#11363)
  Remove deprecated componentWillReceiveProps from TinyMCE component (#11368)
  Create file blocks when dropping multiple files at once (#11297)
  Try avoiding the deprecated findDOMNode API from DropZone Provider (#11168)
  Fix: make meta+A behaviour of selecting all blocks work on safari and firefox. (#8180)
  Remove _wpGutenbergCodeEditorSettings and wp.codeEditor assets (#11342)
  Remove the Cloudflare warning (#11350)
  Image Block: Use source_url for media file link (#11254)
  Enhance styling of nextpage block using the Hr element (#11354)
  Embed block refactor and tidy (#10958)
  Nonce Middleware: Wrap the nonce middleware function into it's own function that isn't regenerated on every API request. (#11347)
  Fix RTL block alignments (#11293)
  RichText: fix buggy enter/delete behaviour (#11287)
  Remove code coverage setup (#11198)
  Parser: Runs all parser implementations against the same tests (#11320)
  Stop trying to autosave when title and classic block content both are empty. (#10404)
  Fix "Mac OS" typo + use fancy quotes consistently (#11310)
  Update documentation link paths (#11324)
  Editor: Reshape blocks state under own key (#11315)
  ...

# Conflicts:
#	gutenberg-mobile
@youknowriad youknowriad added this to the 4.3 milestone Nov 2, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@aduth aduth aduth approved these changes

Assignees
No one assigned
Labels
[Type] Code Quality Issues or PRs that relate to code quality
Projects
None yet
Milestone
4.3
Development

Successfully merging this pull request may close these issues.
2 participants
@youknowriad @aduth