The `replaceTargetContent` option wasn't being set correctly, this has been updated.
The `mount` method uses a `render` method (which is not set in the Plugin) so I've had to manually add this to the instance for the tests.
This patch makes sure only blobs that are referenced by the localStorage
state are actually restored. Blobs that are returned from the persistent
serviceWorker or IndexedDB stores, but aren't referenced by the `files`
state object restored from localStorage, will be deleted.
Should fix#348.
Part of #342, but we need to do more before we can call that fixed :)
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.
