fix: use a data transfer object supplied by the event caller

[johnjesse]

What:

Pass the data transfer value through to the event if it's already an instance of window.DataTransfer
see #857

Why:

If you try and use a real DataTransfer object for a drag/drop event it is thrown away and it's properties aren't copied over to the one created within create event.

How:

I test the dataTransferValue to see if it is an instanceof window.DataTransfer

Checklist:

• Documentation added to the
  docs site N/A
• Tests
• Typescript definitions updated N/A
• Ready to be merged
  

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit 8807c56:

Sandbox	Source
react-testing-library-examples	Configuration

[marcosvega91]

Hi @johnjesse could you please rebase this branch with master?

[codecov]

Codecov Report

Merging #858 (8807c56) into master (c6acb0a) will not change coverage.
The diff coverage is 100.00%.

@@            Coverage Diff            @@
##            master      #858   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files           26        26           
  Lines          944       946    +2     
  Branches       285       287    +2     
=========================================
+ Hits           944       946    +2     

Flag	Coverage Δ
node-10.14.2	100.00% <100.00%> (ø)
node-12	100.00% <100.00%> (ø)
node-14	100.00% <100.00%> (ø)
node-15	100.00% <100.00%> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
src/events.js	100.00% <100.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update c6acb0a...8807c56. Read the comment docs.

[nickmccurdy]

@eps1lon Would we still want to support this considering the discussion #865?

[eps1lon]

@eps1lon Would we still want to support this considering the discussion #865?

I generally have a big problem with doing these polyfills in a library. So I'm the wrong person to ask since I was already against the original PR that started to polyfill these. This PR supports my position on not doing any polyfill in this library since it might cause bugs in proper environments.

[nickmccurdy]

I think I agree with you on that, JSDOM workarounds can be pretty complex and sometimes cause more subtle bugs.

We can merge this if you're okay with it.

[johnjesse]

Hey - just commenting to see if you want any changes on this PR or not, as it's been sat here for a while

[nickmccurdy]

@eps1lon Do you think this is ready to merge?

[johnjesse]

Is there any movement on this?