-
-
Notifications
You must be signed in to change notification settings - Fork 780
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
Feature/custom get data transfer items #616
Feature/custom get data transfer items #616
Conversation
Great work on this! I really like how it's shaping.
|
Inviting @quarklemotion to review and comment. Also, it would be great to sync the release of the directories reader to fit the API. |
fileList.forEach(file => { | ||
if (!disablePreview) { | ||
try { | ||
file.preview = window.URL.createObjectURL(file) // eslint-disable-line no-param-reassign |
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'd propose to create an additional "plugin" called getDataTransferItemsWithPreview
and move this code there. Ideally the core of this library should be not concerned about anything but drag'n'drop.
I'd even go with a breaking change there since I believe most users don't need preview generation by default and it's a runtime cost and a potential memory leak.
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.
It’s not clear to me about how getDataTransferItemsWithPreview
should be separated into an additional plugin. In the previous implementation, we use to have disablePreview
prop which would enable/disable preview generation, so if we will take this code away, how would the user be able to generate previews with a plugin? I mean, importing plugin and passing it as getDataTransferItems
will replace original function with all the core functionality, in this case, we should also export default getDataTransferItems
plugin so the user can make a composition of those, or maybe add an additional prop that will take function to invoke with file list after getDataTransferItems
?
Sorry if I am missing something!
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.
@Nodman I think exporting the default implementation + additional plugins is a way to go. Composition should be the right way of doing this. We should also add examples of how to achieve this.
@@ -585,5 +606,6 @@ Dropzone.defaultProps = { | |||
disableClick: false, | |||
multiple: true, | |||
maxSize: Infinity, | |||
minSize: 0 | |||
minSize: 0, | |||
getDataTransferItems: defaultGetDataTransferItem |
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.
Let's add a signature of the function here as a JSDoc to make it easier for plugins authors.
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 have described it in the propTypes section, should I describe it here too?
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.
Oh sorry I thought that is the propTypes
. No, the way you did it is perfect! Thanks!
@okonet this implementation makes sense to me. I like the use of |
I think the preview plugin should live in this repo. I’d even say your plugin should probably too. I’m not sure how much overhead setting up multiple packages would be, though. Yarn workspaces should solve it, right? |
@okonet Ah, I see - I think that could make sense to convert react-dropzone to multi-package. Were you thinking that the folder drop plugin package would be a small wrapper of html5-file-selector, or html5-file-selector would move into the react-dropzone repo? One thing to consider is that the file selector module was built to support both dropzones and file input fields, whereas react-dropzone only cares about the dropzone support. There are other projects using the file selector module, and I want to make sure they can continue to use it. As for multi-package setup, I haven't used yarn workspaces before, only lerna, but happy to help with this effort! |
Totally makes sense to me. Let’s keep thing simple for now and add your module to documentation. |
Codecov Report
@@ Coverage Diff @@
## master #616 +/- ##
==========================================
+ Coverage 99.01% 99.02% +<.01%
==========================================
Files 3 3
Lines 204 205 +1
Branches 59 59
==========================================
+ Hits 202 203 +1
Misses 2 2
Continue to review full report at Codecov.
|
I think the most important part we're missing is the documentation. Can you please add it and we could merge it as is. After that we could extract bits for preview. |
Ok, I'm going to write a usage of |
@MarinaZadoyanchuk thanks! |
Any update on when this might be merged in? |
Please merge this PR. ASAP. Thanks. |
Since this one is stalling, I decided to proceed and merge it. Anyone wants to work on the documentation? @quarklemotion do you want to add an example? |
I'm not succeding implementing |
@ralexrdz here you go: using-third-party-plugins. |
@rolandjitsu thanks a lot. It was the Promise / async I was missing ;) |
What kind of change does this PR introduce?
Did you add tests for your changes?
If relevant, did you update the documentation?
Summary
Here is a very basic idea of how plugin interface could be implemented (as was suggested by @okonet in #609), basically we are giving the user an ability to specify it's own function getDataTransferItems instead of default one. Would be great to hear some thoughts and suggestions on this.
Does this PR introduce a breaking change?
No
Closes #609