Closed dlockhart closed 3 years ago
My current thoughts about this:
I am sort of imagining:
d2l-file-input
- the visual component that just gets the file objects. This could perhaps even be split into d2l-file-drop
, d2l-file-browse
, and d2l-file-drop-behavior
.
d2l-file-upload-behavior
- JS logic that handles the XHR upload to some end-point, passes back progress info (as per XHR's standard progress event), passes back handle that can be used by consuming code to abort, and potentially even pause/restart.
d2l-file-upload
or d2l-file-upload-status
- a visual component that interacts with d2l-file-upload-behavior and shows name of file, progress, and an [x] button to abort. One of these per file.
Uncertain about the state of the message that is baked into d2l-file-uploader
. Presumably we would want to use this same message component for error/warning messages that arise from the file upload operation such as restricted file type, file too big, duplicate file name, network error, etc
Baking all of this into d2l-file-uploader
avoids putting too much thought into the API between such components, but I think it makes sense the separate these visual components and behavior (re-usability, flexibility, testability, etc).
In the back of my mind I've been thinking about how we will update MVC file-input control to use this. I'm not sure if anyone has thought about how these things will hang together...
This is now a labs component -- we can consider a rename later when/if this gets pulled into core.
This component gets used in conjunction with other progress components to do the actual file upload. Its role is simply to provide a drop target, an event and list of files when a drop occurs. As such, calling it a "file uploader" is misleading, since it doesn't do any actual uploading.
Other options:
d2l-file-drop-target
d2l-file-input