isOnline renamed to updateOnlineStatus and removes params
updateOnlineStatus default to true
Improved the window.navigator.onLine check
Adds tests for updateOnlineStatus
Removes debug
Fixes isTouchDevice test
File cleanup
Simplifies mock for window.navigator.onLine
I unfortunately can’t seem to understand this test: `should execute all
the postprocessors when uploading a file` in Core.test.js:
6bee4f427f
eb771774b/src/core/Core.test.js#L388
@richardwillars could you please help explain why the fileID is used
there and how, and if it’s wrong to change it the way I did here?
@goto-bus-stop potential danger point. introduced to support multiple
dashboard open triggers #326
Maybe we should always return an array and just use the first element
where multiple elements don’t make sense
Adds tests for src/core/Utils
Ports translator tests to jest
Adds tests for core/index
Added code coverage report
Adds tests for core/UppySocket
Adds tests to src/core and cleanup of test directory
Switched from import to require as the project supports node v4
Runs tests using Babel for backwards compatibilty
Adds src/core state tests
Adds src/core reset & close tests
Updates stagnant snapshot
Adds tests for preprocessors and postprocessors in src/core/Core.js
Adds tests for uploaders and metadata in src/core/Core
Adds tests for adding and removing files in src/core/Core
Adds test for getFile
XHRUpload and Tus were relying on `core:upload-complete` to determine
when their uploads had all finished, but `core:upload-complete` could
fire before all XHR `onload` handlers were called. Then, because
XHRUpload and Tus would resolve their `handleUpload` promises at that
point, the `core:success` event could fire *before* all
`core:upload-success` events had fired, and before the plugins properly
handled responses. In particular, some files may not have `.uploadURL`
properties when `core:success` is fired:
https://community.transloadit.com/t/unable-to-get-to-work-the-awss3-plugin/14477/16
I think, that the XHR `onprogress` event would fire first at 100%, and
then the `onload` handler fired at some point later (after the response
was parsed or whatever the browser does to it). This could cause the
`core:upload-complete` event to fire before responses were handled by
Uppy.
The XHRUpload and Tus plugins now use the Promises that they were
already creating to wait for uploads to complete. This way they will
always have handled responses before handing over control to
postprocessors and before the `core:success` event is fired.
Since `core:upload-complete` is now unused, I just removed it for now.
Fixes#315
This patch makes some function options that can return Promises a bit
easier to use. Previously, most of these required that the user returned
a Promise, even if they were doing sync work. Also, if an error was
thrown inside the provided function, it would actually throw the error
instead of rejecting a Promise, thus not allowing Uppy to show an error
notification or anything.
Instead, these options now use this pattern:
```js
Promise.resolve()
.then(() => this.opts.onSomething(argument))
```
Inside a `.then()` handler, both a Promise and a plain value can be
returned, and the resulting Promise will be resolved with the correct
value. Also, any sync errors `throw`n inside a `.then()` handler cause
the returned Promise to be rejected.
Previously this would throw "Plugin is not a constructor" when trying to
instantiate the plugin. Now it checks that the Plugin is actually a
function (and hopefully a constructor…) and throws a more helpful error
if it is not.
This adds back the ability to run assemblies without uploading any
files, which is useful in case the assembly uses an import robot.
To do this, this patch adds a new state key to the Transloadit plugin's
state, named `uploadsAssemblies` (open to bikeshedding lol)
This key associates assembly IDs with the upload ID that triggered them.
This allows figuring out which assemblies need to finish before
resolving the upload promise.
The upload ID is now passed into preprocessors and postprocessors so
they can use it to store metadata that is related to an upload instead
of a single file.
When `alwaysRunAssembly` is set to true, and zero files are available
for upload, an assembly is created anyway for the options returned by
`getAssemblyOptions(null)`.
It turns out that `afterUpload` actually didn't work correctly if
multiple assemblies were used for a single upload. I changed it so that
it does, and incidentally that also made it work again with zero-file
assemblies.
