FEATURE: First pass of using uppy in the composer (PR #13935)

Adds uppy upload functionality behind a enable_experimental_composer_uploader site setting (default false, and hidden).

When enabled this site setting will make the composer-editor-uppy component be used within composer.hbs, which in turn points to a ComposerUploadUppy mixin which overrides the relevant functions from ComposerUpload. This uppy uploader has parity with all the features of jQuery file uploader in the original composer-editor, including:

  • progress tracking
  • error handling
  • number of files validation
  • pasting files
  • dragging and dropping files
  • updating upload placeholders
  • upload markdown resolvers
  • processing actions (the only one we have so far is the media optimization worker by falco, this works)
  • cancelling uploads

For now all uploads still go via the /uploads.json endpoint, direct S3 support will be added later.

Also included in this PR are some changes to the media optimization service, to support uppy’s different file data structures, and also to make the promise tracking and resolving more robust. Currently it uses the file name to track promises, we can switch to something more unique later if needed.

Does not include custom upload handlers, that will come in a later PR, it is a tricky problem to handle.

GitHub

Only had to do this because warn is the name of the ember warning logger

Looks like the new tests I added are failing ember CLI…will look into it. Also adding some unit tests for the uppy plugins.

can we avoid introducing jquery in new code please ?

Ah yes good point, will get rid of it, sorry just copied without thinking from the old one.

I’ve had two random test failures unrelated to this work, seems like GitHub CI is just failing for…reasons sometimes with our Ember CLI tests

The 3 above todos I will address in another PR…perfect is the enemy of the good, I need to get this in front of a real world environment.

This one is very similar to the regular composer upload mixin, however that one just stored one placeholder at a time on a shared property which was very hard to reason about. The _uploadPlaceholder method is now a pure function as well.

probably a temporary error with actions

should use layout and not layoutName, look at what I do in select-kit in the codebase

is uppy supposed to be public?

I saw there was a close() function in uppy doc, did you look at using it ?

Could you explain why you need run here ?

why this run ?

why next?

why ? :stuck_out_tongue:

directly return it ?

this._uppyInstance?.reset();

do we need the get here ?

why ?