You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Return the full response of /rails/active_storage/direct_uploads in the DirectUploadProvider#onSuccess() callback.
Use Case
Creating attachments for multiple independent models.
Explanation
Let's say you allow users to upload a large amount of files and you want to create one record with one attachment for each file. This is convenient to do with a single DirectUploadProvider because the user might drop anywhere from 50-1000 files on this uploader, and you don't want them to do this 50-1000 times. Also uploading in parallel is great for fun and profit.
You have form/json data for each model and you know which file the data refers to. There's enough information returned from the rails/active_storage/direct_uploads endpoint to know the key, signed_id, filename, and size to tie this information together so that you could create a collection of objects such that each has an attachment.
However the DirectUploadProvider#onSuccess callback only rips off the signed_id making it impossible to tie each signed_id/ActiveStorage::Blob object to your data. :(
Proposed Solution
Add an attribute to the DirectUploadProvider that will cause the onSuccess() callback to return the entire payload.
Ultimately I would prefer that the onSuccess callback returned the entire payload of /rails/active_storage/direct_uploads, however that would break backwards compatibility of the DirectUploadProvider (though the ActiveStorageProvider could easily maintain compatibility) which would be annoying (unless you're up for cutting a new major version).
To address backward compatibility an optional extra attribute can be added, its default value would maintain the existing API contract, and 1000 files could be attached to 1000 newly created objects.
There's other ways of exposing this information (ie return signed_id array and an array of the full payload) but this seems like the simplest way with the least friction for current users of the library.
Request
Return the full response of
/rails/active_storage/direct_uploads
in theDirectUploadProvider#onSuccess()
callback.Use Case
Creating attachments for multiple independent models.
Explanation
Let's say you allow users to upload a large amount of files and you want to create one record with one attachment for each file. This is convenient to do with a single
DirectUploadProvider
because the user might drop anywhere from 50-1000 files on this uploader, and you don't want them to do this 50-1000 times. Also uploading in parallel is great for fun and profit.You have form/json data for each model and you know which file the data refers to. There's enough information returned from the
rails/active_storage/direct_uploads
endpoint to know thekey
,signed_id
,filename
, andsize
to tie this information together so that you could create a collection of objects such that each has an attachment.However the
DirectUploadProvider#onSuccess
callback only rips off thesigned_id
making it impossible to tie eachsigned_id
/ActiveStorage::Blob
object to your data. :(Proposed Solution
Add an attribute to the
DirectUploadProvider
that will cause theonSuccess()
callback to return the entire payload.Ultimately I would prefer that the
onSuccess
callback returned the entire payload of/rails/active_storage/direct_uploads
, however that would break backwards compatibility of theDirectUploadProvider
(though theActiveStorageProvider
could easily maintain compatibility) which would be annoying (unless you're up for cutting a new major version).To address backward compatibility an optional extra attribute can be added, its default value would maintain the existing API contract, and 1000 files could be attached to 1000 newly created objects.
There's other ways of exposing this information (ie return
signed_id
array and an array of the full payload) but this seems like the simplest way with the least friction for current users of the library.Here's a PR demonstrating the solution: #36
The text was updated successfully, but these errors were encountered: