adopted-ember-addons
How best to handle on upload completion
My use-case is to make an API request after all files are uploaded and wonder what the best design pattern would be to handle this.
I have found that it's necessary to decrement the files.length property of the fileQueue service. I can then test for it to be 0 and then make the final API call to in my case attach the completed files to a content entity. Should I have the manually decrement the files.length property?
@blainelang that's probably not best to do; the files are managed by the service and are sweeped when all files in progress have finished for a queue. It ensures that the group of files doesn't change the progress meter.
What's the case that you want to call a method after all instead of individual?
In my case, the backend has a separate API to upload the files (where they are maintained as separate entities to be attached to one or more content entities) and a second API to attach the files to the content entity. I use a PATCH API request to attach the new files (file id's were returned on each file upload success). This is all working and now refining the logic for better error handling.
Presently I am maintaining my own state to track the successful file uploads and decrementing the files.length property but will remove that as you noted your using that internally for the progress tracking. It may be good to have another property to track the number of remaining files. I saw that your tracking the remaining bytes.
The backend returns a 422 if the file already exists with the same name. So additionally I need to handle that as well. I'm presently checking the status and was going to post a separate question to see if there was a way to prevent the POST failed console message logging. I'm essentially using your uploadPhoto implementation and the catch block is firing as expected. The POST error is appearing before any of the logic in the catch block executes.
Thanks again for your contribution and support!
If we add an onFileAdd event to Queue to address #29 we might also want to add onFileUpload and onFileUploaded to address such use cases? :thinking: onFileUpload would be triggered whenever an upload is started and onFileUploaded whenever an upload is finished. Maybe even adding a onFileUploadFailed for error handling? All should get the Queue as first argument.
This would allow to address the use case described here like this:
@action
fileUploaded(queue) {
if (queue.length !== 0) {
// still files in the queue
return;
}
// do whatever is needed as soon as all files in the queue have been uploaded
}
Taking the API proposed in #316 into account the consumer could add such an event handler using the {{file-queue}} template helper:
{{file-upload-queue @name="photos" @onFileUploaded=(this.fileUploaded)}}
As a queue with a specific name is a singleton this would allow to register multiple event handles for the same queue at the same time. But I see this more as an advantage than as a problem.
