Skip to content
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 Request: Expose Full Response from /rails/active_storage/direct_uploads #37

Open
jdalt opened this issue Jul 15, 2019 · 2 comments

Comments

@jdalt
Copy link

jdalt commented Jul 15, 2019

Request

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.

Here's a PR demonstrating the solution: #36

@eggei
Copy link

eggei commented Mar 4, 2024

This would be very useful. I am currently having trouble because of this same limitation.

@eggei
Copy link

eggei commented Mar 4, 2024

If anyone ends up here like me, here is your savior: https://github.com/quorak/react-activestorage-provider

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants