Uppy: Transloadit Template selection

[payner35]

is it possible to have the Transloadit Template ID change based on the file type.

I have 3 templates for mp4, image, Mp3. I'd like to be able to drop them all onto uppy

any thoughts?

[kvz]

Hi @payner35 thanks for the suggestion, I think the way to work around this could be having a single Template and using the /file/filter Robot to direct the proper types to the proper steps.

I can see why shorter more focussed Templates are preferred though, and we'll think also on what we can do to accommodate this use case in Uppy. There are quite some strings attached though. Currently if you select multiple files and upload them, they'll be in one Assembly. So there's implications throughout and we'd like to steer clear of overly hacky approaches to solving this, so it may take some time, sorry! Would the workaround I suggested be of any help already?

[oyeanuj]

@payner35 @kvz I am in a similar boat where I have a different template for each media type. This makes the 100+ line templates much easier to deal with.

So, in my case, I have built my own UI and using Uppy for the upload/tus functionality. So, to deal with multiple files being selected case, I go through each file type, and create an Uppy instance (with their respective templateId) for each file type (which maps to each template type).

But clearly it isn't an optimum solution. An ability to let Transloadit plugin initiate per file would be much cleaner. Then the Transloadit plugin took a function that returned a templateId. Uppy could instantiate the plugin for each file, pass the file and be returned a templateId. That would be the most flexible, and then if needed Uppy, could do optimizations of combining if the templateIds are the same.

[kvz]

That's a better idea than what I had already, thanks!

How did you do this before Uppy if I may ask?

Sent from mobile, pardon the brevity.

On 22 Jun 2017, at 23:49, Anuj [e-mail] wrote:

@payner35 @kvz I am in a similar boat where I have a different template for each media type. This makes the 100+ line templates much easier to deal with.

So, in my case, I have built my own UI and using Uppy for the upload/tus functionality. So, to deal with multiple files being selected case, I go through each file type, and create an Uppy instance (with their respective templateId) for each file type (which maps to each template type).

But clearly it isn't an optimum solution. An ability to let Transloadit plugin initiate per file would be much cleaner. Then the Transloadit plugin took a function that returned a templateId. Uppy could instantiate the plugin for each file, pass the file and be returned a templateId. That would be the most flexible, and then if needed Uppy, could do optimizations of combining if the templateIds are the same.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[goto-bus-stop]

An ability to let Transloadit plugin initiate per file would be much cleaner. Then the Transloadit plugin took a function that returned a templateId.

Yeah, this sounds really good. Since the Transloadit plugin already has support for running multiple assemblies simultaneously, I think this is within reach.

e; Something like this:

.use(Transloadit, {
  params: (file) => ({
    auth: { key: 'xyz' },
    template_id: file.type.generic === 'image' ? 'abc' : 'def'
  })
})

If params is a function, it'll be called for each file. Files can be bunched together into a single assembly when their params are identical.

This would also address an open TODO from #173 re: using file MetaData to generate params:

.use(MetaData, {
  fields: [
    { id: 'resizeTo', name: 'Resize to', value: 1200 },
  ]
})
.use(Transloadit, {
  params: (file) => ({
    auth: { key: 'xyz' },
    template_id: 'something for resizing images',
    steps: {
      resize: {
        width: file.meta.resizeTo,
        height: file.meta.resizeTo
      }
    }
  })
})

[oyeanuj]

@goto-bus-stop This looks good to me as it provides maximum flexibility!

How did you do this before Uppy if I may ask?

@kvz: I hadn't implemented it before Uppy but I was planning to implement it in just native javascript without any SDK, but in a similar fashion to my suggestion. So each file would be an individual XHR call and then have a function to determine template id based on file type.

[payner35]

sounds good.

would it be possible to know what template triggered a step?

so if we have uppy.on('transloadit:result', (step, result) => {} and the step is called "thumb" from transloadit. it would be good to know if its a "thumb" step from template x / y / z

[oyeanuj]

@goto-bus-stop @kvz Another thing which came to mind which has been hard with the current API and will probably be solved with @goto-bus-stop's above comment - the signature really needs to be calculated per-file (because of the expiry time in it).

Currently, I am essentially using an uppy object per file (in my redux actions) to maintain a unique signature. The other option would be to reuse the same signature and keep refreshing but that felt problematic. Initializing Transloadit params per file would solve this issue.

[goto-bus-stop]

the signature really needs to be calculated per-file (because of the expiry time in it).

I guess this means the params function option should also be able to do asynchronous work, like a network request to retrieve a signature.

[oyeanuj]

@goto-bus-stop Right, that could help. In my case, I first initiate signature action and once that is done, call the action which creates the Uppy object and adds the file.

[oyeanuj]

@goto-bus-stop An API suggestion based on this comment I posted about content disposition

Regardless of whether you update .use(Transloadit, ...) to what you were suggesting or keep it how it is today, you could add an option to augment uppy.addFile API to take in a parameter called transloaditParams (or s3Params for that matter):

uppy.addFile({
  name: file.name,
  mime: file.mime,
  data: file.data,
  transloaditParams: {}
})

And the transloaditParams passed in addFile can be merged with the params passed earlier in .use, and overwrite wherever specified.

[goto-bus-stop]

250 added a getAssemblyOptions function option to the Transloadit plugin that allows to use different template_ids for different files. Something like:

uppy.use(Transloadit, {
  getAssemblyOptions (file) {
    return {
      params: {
        auth: { key: 'xyz' },
        template_id: file.type.general === 'audio'
          ? 'abcdefabcdefabcdef1234'
          : '123456123456123456abcd'
      }
    }
  }
})

It'll be in the next release 0.18, planned for the end of the month. I hope that addresses it! If not, let us know :v:

@oyeanuj As for transloaditParams in addFile, that'd be really good for programmatic use indeed—we should have something like that. I think we can add a transloadit key which would be merged into the Transloadit options, which is similar to how the Tus and XHR upload plugins work (undocumented 🙈).

[oyeanuj]

@oyeanuj As for transloaditParams in addFile, that'd be really good for programmatic use indeed—we should have something like that. I think we can add a transloadit key which would be merged into the Transloadit options, which is similar to how the Tus and XHR upload plugins work (undocumented 🙈).

@goto-bus-stop That would be awesome 😃 Also, is master good to use to be able to use that functionality?