Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Allow Transloadit-hosted Companion with other uploaders #5558
base: main
Are you sure you want to change the base?
Allow Transloadit-hosted Companion with other uploaders #5558
Changes from all commits
22b183a
5bec1c1
9fa3f7d
1bcd04c
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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 really don't like using state for this. Can't we instead make it a pure option on each uploader, instead of passing the transloadit plugin option through state like this? Yes it's more verbose but it's so much easier to grok when reading/understanding how the code works, compared to analysing state mutations. If the verbosity is a problem, that could be solved with good documation, or something like a helper method or wrapper plugin that will initialise the correct plugins with the correct options
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.
How would that work? One uploader does not know if there is another uploader to set such a property. I could make a property on the uppy class instead of uppy's state, but not sure if that's much better.
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.
What I meant is that we can add an option
remoteUploader
to the plugins@uppy/aws-s3
and@uppy/aws-xhr-upload
. then we don't need this bidirectional state dependency. So when using this feature you'd instead initialise plugins like this:this will still allow people to customise the remote uploader (as needed in #5515)
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.
imo
remoteUploader: 'tus'
and then installingTransloadit
is very confusing and not worth it to make our code better.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.
this whole feature is extremely confusing, but the hidden state behavior makes it even more confusing compared to an option imo
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 meant I'm open to alternatives that do not involve yet another option besides this new option. If you can give me that we can talk about that more concretely. Two options that need to coordinate of which one is a confusing
tus
value while there is no tus in sight can't be the best way forward.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.
there is a tus uploader in sight though, inside companion - and that’s the one we’re using for remote files when this option is set, hence imo it makes sense to call a spade a spade and call the option remoteUploader: ‘tus’. It describes exactly what we’re doing here:
For remote files we use the uploader «tus».
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 don’t have any better idea for which option to solve it, other than maybe an option on uppy core
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.
Place yourself in the shoes of a user, they used
@uppy/aws-s3
before and now want to use Transloadit-hosted companion. They install@uppy/transloadit
and that's it, they don't care and may not know what Companion internals do, they just care that remote files end up at Transloadit. Therefor having to set not one, but two, options is error prone and the value of'tus'
is not expected. This will be confusing.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 think that having to pass an option onlyRemoteFiles: true to Transloadit is equally confusing. But if we document it properly, they don't have to think much about whether there's 1 or 2 confusing options. And this option is not confusing for the people who want to customise the remote uploader being used, like in #5515