2021-10-17 10:36:14 +02:00
|
|
|
// @flow
|
|
|
|
import { handleActions } from 'util/redux-utils';
|
|
|
|
import { buildURI } from 'util/lbryURI';
|
Support resume-able upload via tus (#186)
* Publish button: use spinner instead of "Publishing..."
Looks better, plus the preview could take a while sometimes.
* Refactor `doPublish`. No functional change
This is to allow `doPublish` to accept a custom payload as an input (for resuming uploads), instead of always resolving it from the redux data.
* Add doPublishResume
* Support resume-able upload via tus
## Issue
38 Handle resumable file upload
## Notes
Since we can't serialize a File object, we'll need to the user to re-select the file to resume.
* Exclude "modified date" for Firefox/Android
## Issue
It appears that the modification date of the Android file changes when selected, so that file was deemed "different" when trying to resume upload.
## Change
Exclude modification date for now. Let's assume a smart user.
* Move 'currentUploads' to 'publish' reducer
`publish` is currently rehydrated, so we can ride on that and don't need to store the `currentUploads` in `localStorage` for persistence. This would allow us to store Markdown Post data too, as `localStorage` has a 5MB limit per app.
We could have also made `webReducer` rehydrate, but in this repo, there is no need to split it to another reducer. It also makes more sense to be part of publish anyway (at least to me).
This change is mostly moving items between files, with the exception of
1. An additional REHYDRATE in the publish reducer to clean up the tusUploader.
2. Not clearing `currentUploads` in CLEAR_PUBLISH.
* Restore v1 code for livestream replay, etc.
v2 (tus) does not handle `remote_url`, so the app still needs v1 for that. Since we'll still have v1 code, use v1 for previews as well.
2021-11-10 19:16:16 +01:00
|
|
|
import { serializeFileObj } from 'util/file';
|
2021-12-07 15:48:09 +01:00
|
|
|
import { tusLockAndNotify, tusUnlockAndNotify, tusRemoveAndNotify, tusClearRemovedUploads } from 'util/tus';
|
2021-10-17 10:36:14 +02:00
|
|
|
import * as ACTIONS from 'constants/action_types';
|
|
|
|
import * as THUMBNAIL_STATUSES from 'constants/thumbnail_upload_statuses';
|
|
|
|
import { CHANNEL_ANONYMOUS } from 'constants/claim';
|
|
|
|
|
2021-12-07 15:48:09 +01:00
|
|
|
// This is the old key formula. Retain it for now to allow users to delete
|
|
|
|
// any pending uploads. Can be removed from January 2022 onwards.
|
|
|
|
const getOldKeyFromParam = (params) => `${params.name}#${params.channel || 'anonymous'}`;
|
Support resume-able upload via tus (#186)
* Publish button: use spinner instead of "Publishing..."
Looks better, plus the preview could take a while sometimes.
* Refactor `doPublish`. No functional change
This is to allow `doPublish` to accept a custom payload as an input (for resuming uploads), instead of always resolving it from the redux data.
* Add doPublishResume
* Support resume-able upload via tus
## Issue
38 Handle resumable file upload
## Notes
Since we can't serialize a File object, we'll need to the user to re-select the file to resume.
* Exclude "modified date" for Firefox/Android
## Issue
It appears that the modification date of the Android file changes when selected, so that file was deemed "different" when trying to resume upload.
## Change
Exclude modification date for now. Let's assume a smart user.
* Move 'currentUploads' to 'publish' reducer
`publish` is currently rehydrated, so we can ride on that and don't need to store the `currentUploads` in `localStorage` for persistence. This would allow us to store Markdown Post data too, as `localStorage` has a 5MB limit per app.
We could have also made `webReducer` rehydrate, but in this repo, there is no need to split it to another reducer. It also makes more sense to be part of publish anyway (at least to me).
This change is mostly moving items between files, with the exception of
1. An additional REHYDRATE in the publish reducer to clean up the tusUploader.
2. Not clearing `currentUploads` in CLEAR_PUBLISH.
* Restore v1 code for livestream replay, etc.
v2 (tus) does not handle `remote_url`, so the app still needs v1 for that. Since we'll still have v1 code, use v1 for previews as well.
2021-11-10 19:16:16 +01:00
|
|
|
|
2021-10-17 10:36:14 +02:00
|
|
|
type PublishState = {
|
|
|
|
editingURI: ?string,
|
|
|
|
fileText: ?string,
|
|
|
|
filePath: ?string,
|
|
|
|
remoteFileUrl: ?string,
|
|
|
|
contentIsFree: boolean,
|
|
|
|
fileDur: number,
|
|
|
|
fileSize: number,
|
|
|
|
fileVid: boolean,
|
|
|
|
fee: {
|
|
|
|
amount: number,
|
|
|
|
currency: string,
|
|
|
|
},
|
|
|
|
title: string,
|
|
|
|
thumbnail_url: string,
|
|
|
|
thumbnailPath: string,
|
|
|
|
uploadThumbnailStatus: string,
|
|
|
|
thumbnailError: ?boolean,
|
|
|
|
description: string,
|
|
|
|
language: string,
|
|
|
|
releaseTime: ?number,
|
|
|
|
releaseTimeEdited: ?number,
|
|
|
|
channel: string,
|
|
|
|
channelId: ?string,
|
|
|
|
name: string,
|
|
|
|
nameError: ?string,
|
|
|
|
bid: number,
|
|
|
|
bidError: ?string,
|
|
|
|
otherLicenseDescription: string,
|
|
|
|
licenseUrl: string,
|
|
|
|
tags: Array<string>,
|
|
|
|
optimize: boolean,
|
|
|
|
useLBRYUploader: boolean,
|
Support resume-able upload via tus (#186)
* Publish button: use spinner instead of "Publishing..."
Looks better, plus the preview could take a while sometimes.
* Refactor `doPublish`. No functional change
This is to allow `doPublish` to accept a custom payload as an input (for resuming uploads), instead of always resolving it from the redux data.
* Add doPublishResume
* Support resume-able upload via tus
## Issue
38 Handle resumable file upload
## Notes
Since we can't serialize a File object, we'll need to the user to re-select the file to resume.
* Exclude "modified date" for Firefox/Android
## Issue
It appears that the modification date of the Android file changes when selected, so that file was deemed "different" when trying to resume upload.
## Change
Exclude modification date for now. Let's assume a smart user.
* Move 'currentUploads' to 'publish' reducer
`publish` is currently rehydrated, so we can ride on that and don't need to store the `currentUploads` in `localStorage` for persistence. This would allow us to store Markdown Post data too, as `localStorage` has a 5MB limit per app.
We could have also made `webReducer` rehydrate, but in this repo, there is no need to split it to another reducer. It also makes more sense to be part of publish anyway (at least to me).
This change is mostly moving items between files, with the exception of
1. An additional REHYDRATE in the publish reducer to clean up the tusUploader.
2. Not clearing `currentUploads` in CLEAR_PUBLISH.
* Restore v1 code for livestream replay, etc.
v2 (tus) does not handle `remote_url`, so the app still needs v1 for that. Since we'll still have v1 code, use v1 for previews as well.
2021-11-10 19:16:16 +01:00
|
|
|
currentUploads: { [key: string]: FileUploadItem },
|
2021-10-17 10:36:14 +02:00
|
|
|
};
|
|
|
|
|
|
|
|
const defaultState: PublishState = {
|
|
|
|
editingURI: undefined,
|
|
|
|
fileText: '',
|
|
|
|
filePath: undefined,
|
|
|
|
fileDur: 0,
|
|
|
|
fileSize: 0,
|
|
|
|
fileVid: false,
|
|
|
|
remoteFileUrl: undefined,
|
|
|
|
contentIsFree: true,
|
|
|
|
fee: {
|
|
|
|
amount: 1,
|
|
|
|
currency: 'LBC',
|
|
|
|
},
|
|
|
|
title: '',
|
|
|
|
thumbnail_url: '',
|
|
|
|
thumbnailPath: '',
|
|
|
|
uploadThumbnailStatus: THUMBNAIL_STATUSES.API_DOWN,
|
|
|
|
thumbnailError: undefined,
|
|
|
|
description: '',
|
|
|
|
language: '',
|
|
|
|
releaseTime: undefined,
|
|
|
|
releaseTimeEdited: undefined,
|
|
|
|
nsfw: false,
|
|
|
|
channel: CHANNEL_ANONYMOUS,
|
|
|
|
channelId: '',
|
|
|
|
name: '',
|
|
|
|
nameError: undefined,
|
|
|
|
bid: 0.01,
|
|
|
|
bidError: undefined,
|
|
|
|
licenseType: 'None',
|
|
|
|
otherLicenseDescription: 'All rights reserved',
|
|
|
|
licenseUrl: '',
|
|
|
|
tags: [],
|
|
|
|
publishing: false,
|
|
|
|
publishSuccess: false,
|
|
|
|
publishError: undefined,
|
|
|
|
optimize: false,
|
|
|
|
useLBRYUploader: false,
|
Support resume-able upload via tus (#186)
* Publish button: use spinner instead of "Publishing..."
Looks better, plus the preview could take a while sometimes.
* Refactor `doPublish`. No functional change
This is to allow `doPublish` to accept a custom payload as an input (for resuming uploads), instead of always resolving it from the redux data.
* Add doPublishResume
* Support resume-able upload via tus
## Issue
38 Handle resumable file upload
## Notes
Since we can't serialize a File object, we'll need to the user to re-select the file to resume.
* Exclude "modified date" for Firefox/Android
## Issue
It appears that the modification date of the Android file changes when selected, so that file was deemed "different" when trying to resume upload.
## Change
Exclude modification date for now. Let's assume a smart user.
* Move 'currentUploads' to 'publish' reducer
`publish` is currently rehydrated, so we can ride on that and don't need to store the `currentUploads` in `localStorage` for persistence. This would allow us to store Markdown Post data too, as `localStorage` has a 5MB limit per app.
We could have also made `webReducer` rehydrate, but in this repo, there is no need to split it to another reducer. It also makes more sense to be part of publish anyway (at least to me).
This change is mostly moving items between files, with the exception of
1. An additional REHYDRATE in the publish reducer to clean up the tusUploader.
2. Not clearing `currentUploads` in CLEAR_PUBLISH.
* Restore v1 code for livestream replay, etc.
v2 (tus) does not handle `remote_url`, so the app still needs v1 for that. Since we'll still have v1 code, use v1 for previews as well.
2021-11-10 19:16:16 +01:00
|
|
|
currentUploads: {},
|
2021-10-17 10:36:14 +02:00
|
|
|
};
|
|
|
|
|
|
|
|
export const publishReducer = handleActions(
|
|
|
|
{
|
|
|
|
[ACTIONS.UPDATE_PUBLISH_FORM]: (state, action): PublishState => {
|
|
|
|
const { data } = action;
|
|
|
|
return {
|
|
|
|
...state,
|
|
|
|
...data,
|
|
|
|
};
|
|
|
|
},
|
|
|
|
[ACTIONS.CLEAR_PUBLISH]: (state: PublishState): PublishState => ({
|
|
|
|
...defaultState,
|
|
|
|
uri: undefined,
|
|
|
|
channel: state.channel,
|
|
|
|
bid: state.bid,
|
|
|
|
optimize: state.optimize,
|
|
|
|
language: state.language,
|
Support resume-able upload via tus (#186)
* Publish button: use spinner instead of "Publishing..."
Looks better, plus the preview could take a while sometimes.
* Refactor `doPublish`. No functional change
This is to allow `doPublish` to accept a custom payload as an input (for resuming uploads), instead of always resolving it from the redux data.
* Add doPublishResume
* Support resume-able upload via tus
## Issue
38 Handle resumable file upload
## Notes
Since we can't serialize a File object, we'll need to the user to re-select the file to resume.
* Exclude "modified date" for Firefox/Android
## Issue
It appears that the modification date of the Android file changes when selected, so that file was deemed "different" when trying to resume upload.
## Change
Exclude modification date for now. Let's assume a smart user.
* Move 'currentUploads' to 'publish' reducer
`publish` is currently rehydrated, so we can ride on that and don't need to store the `currentUploads` in `localStorage` for persistence. This would allow us to store Markdown Post data too, as `localStorage` has a 5MB limit per app.
We could have also made `webReducer` rehydrate, but in this repo, there is no need to split it to another reducer. It also makes more sense to be part of publish anyway (at least to me).
This change is mostly moving items between files, with the exception of
1. An additional REHYDRATE in the publish reducer to clean up the tusUploader.
2. Not clearing `currentUploads` in CLEAR_PUBLISH.
* Restore v1 code for livestream replay, etc.
v2 (tus) does not handle `remote_url`, so the app still needs v1 for that. Since we'll still have v1 code, use v1 for previews as well.
2021-11-10 19:16:16 +01:00
|
|
|
currentUploads: state.currentUploads,
|
2021-10-17 10:36:14 +02:00
|
|
|
}),
|
|
|
|
[ACTIONS.PUBLISH_START]: (state: PublishState): PublishState => ({
|
|
|
|
...state,
|
|
|
|
publishing: true,
|
|
|
|
publishSuccess: false,
|
|
|
|
}),
|
|
|
|
[ACTIONS.PUBLISH_FAIL]: (state: PublishState): PublishState => ({
|
|
|
|
...state,
|
|
|
|
publishing: false,
|
|
|
|
}),
|
|
|
|
[ACTIONS.PUBLISH_SUCCESS]: (state: PublishState): PublishState => ({
|
|
|
|
...state,
|
|
|
|
publishing: false,
|
|
|
|
publishSuccess: true,
|
|
|
|
}),
|
|
|
|
[ACTIONS.DO_PREPARE_EDIT]: (state: PublishState, action) => {
|
|
|
|
const { ...publishData } = action.data;
|
|
|
|
const { channel, name, uri } = publishData;
|
|
|
|
|
|
|
|
// The short uri is what is presented to the user
|
|
|
|
// The editingUri is the full uri with claim id
|
|
|
|
const shortUri = buildURI({
|
|
|
|
channelName: channel,
|
|
|
|
streamName: name,
|
|
|
|
});
|
|
|
|
|
|
|
|
return {
|
|
|
|
...defaultState,
|
|
|
|
...publishData,
|
|
|
|
editingURI: uri,
|
|
|
|
uri: shortUri,
|
Support resume-able upload via tus (#186)
* Publish button: use spinner instead of "Publishing..."
Looks better, plus the preview could take a while sometimes.
* Refactor `doPublish`. No functional change
This is to allow `doPublish` to accept a custom payload as an input (for resuming uploads), instead of always resolving it from the redux data.
* Add doPublishResume
* Support resume-able upload via tus
## Issue
38 Handle resumable file upload
## Notes
Since we can't serialize a File object, we'll need to the user to re-select the file to resume.
* Exclude "modified date" for Firefox/Android
## Issue
It appears that the modification date of the Android file changes when selected, so that file was deemed "different" when trying to resume upload.
## Change
Exclude modification date for now. Let's assume a smart user.
* Move 'currentUploads' to 'publish' reducer
`publish` is currently rehydrated, so we can ride on that and don't need to store the `currentUploads` in `localStorage` for persistence. This would allow us to store Markdown Post data too, as `localStorage` has a 5MB limit per app.
We could have also made `webReducer` rehydrate, but in this repo, there is no need to split it to another reducer. It also makes more sense to be part of publish anyway (at least to me).
This change is mostly moving items between files, with the exception of
1. An additional REHYDRATE in the publish reducer to clean up the tusUploader.
2. Not clearing `currentUploads` in CLEAR_PUBLISH.
* Restore v1 code for livestream replay, etc.
v2 (tus) does not handle `remote_url`, so the app still needs v1 for that. Since we'll still have v1 code, use v1 for previews as well.
2021-11-10 19:16:16 +01:00
|
|
|
currentUploads: state.currentUploads,
|
|
|
|
};
|
|
|
|
},
|
|
|
|
[ACTIONS.UPDATE_UPLOAD_ADD]: (state: PublishState, action) => {
|
|
|
|
const { file, params, uploader } = action.data;
|
|
|
|
const currentUploads = Object.assign({}, state.currentUploads);
|
|
|
|
|
2021-12-07 15:48:09 +01:00
|
|
|
currentUploads[params.guid] = {
|
Support resume-able upload via tus (#186)
* Publish button: use spinner instead of "Publishing..."
Looks better, plus the preview could take a while sometimes.
* Refactor `doPublish`. No functional change
This is to allow `doPublish` to accept a custom payload as an input (for resuming uploads), instead of always resolving it from the redux data.
* Add doPublishResume
* Support resume-able upload via tus
## Issue
38 Handle resumable file upload
## Notes
Since we can't serialize a File object, we'll need to the user to re-select the file to resume.
* Exclude "modified date" for Firefox/Android
## Issue
It appears that the modification date of the Android file changes when selected, so that file was deemed "different" when trying to resume upload.
## Change
Exclude modification date for now. Let's assume a smart user.
* Move 'currentUploads' to 'publish' reducer
`publish` is currently rehydrated, so we can ride on that and don't need to store the `currentUploads` in `localStorage` for persistence. This would allow us to store Markdown Post data too, as `localStorage` has a 5MB limit per app.
We could have also made `webReducer` rehydrate, but in this repo, there is no need to split it to another reducer. It also makes more sense to be part of publish anyway (at least to me).
This change is mostly moving items between files, with the exception of
1. An additional REHYDRATE in the publish reducer to clean up the tusUploader.
2. Not clearing `currentUploads` in CLEAR_PUBLISH.
* Restore v1 code for livestream replay, etc.
v2 (tus) does not handle `remote_url`, so the app still needs v1 for that. Since we'll still have v1 code, use v1 for previews as well.
2021-11-10 19:16:16 +01:00
|
|
|
file,
|
|
|
|
fileFingerprint: file ? serializeFileObj(file) : undefined, // TODO: get hash instead?
|
|
|
|
progress: '0',
|
|
|
|
params,
|
|
|
|
uploader,
|
|
|
|
resumable: !(uploader instanceof XMLHttpRequest),
|
2021-10-17 10:36:14 +02:00
|
|
|
};
|
Support resume-able upload via tus (#186)
* Publish button: use spinner instead of "Publishing..."
Looks better, plus the preview could take a while sometimes.
* Refactor `doPublish`. No functional change
This is to allow `doPublish` to accept a custom payload as an input (for resuming uploads), instead of always resolving it from the redux data.
* Add doPublishResume
* Support resume-able upload via tus
## Issue
38 Handle resumable file upload
## Notes
Since we can't serialize a File object, we'll need to the user to re-select the file to resume.
* Exclude "modified date" for Firefox/Android
## Issue
It appears that the modification date of the Android file changes when selected, so that file was deemed "different" when trying to resume upload.
## Change
Exclude modification date for now. Let's assume a smart user.
* Move 'currentUploads' to 'publish' reducer
`publish` is currently rehydrated, so we can ride on that and don't need to store the `currentUploads` in `localStorage` for persistence. This would allow us to store Markdown Post data too, as `localStorage` has a 5MB limit per app.
We could have also made `webReducer` rehydrate, but in this repo, there is no need to split it to another reducer. It also makes more sense to be part of publish anyway (at least to me).
This change is mostly moving items between files, with the exception of
1. An additional REHYDRATE in the publish reducer to clean up the tusUploader.
2. Not clearing `currentUploads` in CLEAR_PUBLISH.
* Restore v1 code for livestream replay, etc.
v2 (tus) does not handle `remote_url`, so the app still needs v1 for that. Since we'll still have v1 code, use v1 for previews as well.
2021-11-10 19:16:16 +01:00
|
|
|
|
|
|
|
return { ...state, currentUploads };
|
|
|
|
},
|
|
|
|
[ACTIONS.UPDATE_UPLOAD_PROGRESS]: (state: PublishState, action) => {
|
2021-12-07 15:48:09 +01:00
|
|
|
const { guid, progress, status } = action.data;
|
|
|
|
const key = guid;
|
Support resume-able upload via tus (#186)
* Publish button: use spinner instead of "Publishing..."
Looks better, plus the preview could take a while sometimes.
* Refactor `doPublish`. No functional change
This is to allow `doPublish` to accept a custom payload as an input (for resuming uploads), instead of always resolving it from the redux data.
* Add doPublishResume
* Support resume-able upload via tus
## Issue
38 Handle resumable file upload
## Notes
Since we can't serialize a File object, we'll need to the user to re-select the file to resume.
* Exclude "modified date" for Firefox/Android
## Issue
It appears that the modification date of the Android file changes when selected, so that file was deemed "different" when trying to resume upload.
## Change
Exclude modification date for now. Let's assume a smart user.
* Move 'currentUploads' to 'publish' reducer
`publish` is currently rehydrated, so we can ride on that and don't need to store the `currentUploads` in `localStorage` for persistence. This would allow us to store Markdown Post data too, as `localStorage` has a 5MB limit per app.
We could have also made `webReducer` rehydrate, but in this repo, there is no need to split it to another reducer. It also makes more sense to be part of publish anyway (at least to me).
This change is mostly moving items between files, with the exception of
1. An additional REHYDRATE in the publish reducer to clean up the tusUploader.
2. Not clearing `currentUploads` in CLEAR_PUBLISH.
* Restore v1 code for livestream replay, etc.
v2 (tus) does not handle `remote_url`, so the app still needs v1 for that. Since we'll still have v1 code, use v1 for previews as well.
2021-11-10 19:16:16 +01:00
|
|
|
const currentUploads = Object.assign({}, state.currentUploads);
|
|
|
|
|
2021-12-07 15:48:09 +01:00
|
|
|
if (guid === 'force--update') {
|
|
|
|
return { ...state, currentUploads };
|
|
|
|
}
|
|
|
|
|
Support resume-able upload via tus (#186)
* Publish button: use spinner instead of "Publishing..."
Looks better, plus the preview could take a while sometimes.
* Refactor `doPublish`. No functional change
This is to allow `doPublish` to accept a custom payload as an input (for resuming uploads), instead of always resolving it from the redux data.
* Add doPublishResume
* Support resume-able upload via tus
## Issue
38 Handle resumable file upload
## Notes
Since we can't serialize a File object, we'll need to the user to re-select the file to resume.
* Exclude "modified date" for Firefox/Android
## Issue
It appears that the modification date of the Android file changes when selected, so that file was deemed "different" when trying to resume upload.
## Change
Exclude modification date for now. Let's assume a smart user.
* Move 'currentUploads' to 'publish' reducer
`publish` is currently rehydrated, so we can ride on that and don't need to store the `currentUploads` in `localStorage` for persistence. This would allow us to store Markdown Post data too, as `localStorage` has a 5MB limit per app.
We could have also made `webReducer` rehydrate, but in this repo, there is no need to split it to another reducer. It also makes more sense to be part of publish anyway (at least to me).
This change is mostly moving items between files, with the exception of
1. An additional REHYDRATE in the publish reducer to clean up the tusUploader.
2. Not clearing `currentUploads` in CLEAR_PUBLISH.
* Restore v1 code for livestream replay, etc.
v2 (tus) does not handle `remote_url`, so the app still needs v1 for that. Since we'll still have v1 code, use v1 for previews as well.
2021-11-10 19:16:16 +01:00
|
|
|
if (!currentUploads[key]) {
|
|
|
|
return state;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (progress) {
|
|
|
|
currentUploads[key].progress = progress;
|
|
|
|
delete currentUploads[key].status;
|
2021-11-12 06:59:51 +01:00
|
|
|
|
2021-12-07 15:48:09 +01:00
|
|
|
if (currentUploads[key].uploader.url) {
|
|
|
|
// TUS has finally obtained an upload url from the server...
|
|
|
|
if (!currentUploads[key].params.uploadUrl) {
|
|
|
|
// ... Stash that to check later when resuming.
|
|
|
|
// Ignoring immutable-update requirement (probably doesn't matter to the GUI).
|
|
|
|
currentUploads[key].params.uploadUrl = currentUploads[key].uploader.url;
|
|
|
|
}
|
|
|
|
|
|
|
|
// ... lock this tab as the active uploader.
|
|
|
|
tusLockAndNotify(key);
|
2021-11-12 06:59:51 +01:00
|
|
|
}
|
Support resume-able upload via tus (#186)
* Publish button: use spinner instead of "Publishing..."
Looks better, plus the preview could take a while sometimes.
* Refactor `doPublish`. No functional change
This is to allow `doPublish` to accept a custom payload as an input (for resuming uploads), instead of always resolving it from the redux data.
* Add doPublishResume
* Support resume-able upload via tus
## Issue
38 Handle resumable file upload
## Notes
Since we can't serialize a File object, we'll need to the user to re-select the file to resume.
* Exclude "modified date" for Firefox/Android
## Issue
It appears that the modification date of the Android file changes when selected, so that file was deemed "different" when trying to resume upload.
## Change
Exclude modification date for now. Let's assume a smart user.
* Move 'currentUploads' to 'publish' reducer
`publish` is currently rehydrated, so we can ride on that and don't need to store the `currentUploads` in `localStorage` for persistence. This would allow us to store Markdown Post data too, as `localStorage` has a 5MB limit per app.
We could have also made `webReducer` rehydrate, but in this repo, there is no need to split it to another reducer. It also makes more sense to be part of publish anyway (at least to me).
This change is mostly moving items between files, with the exception of
1. An additional REHYDRATE in the publish reducer to clean up the tusUploader.
2. Not clearing `currentUploads` in CLEAR_PUBLISH.
* Restore v1 code for livestream replay, etc.
v2 (tus) does not handle `remote_url`, so the app still needs v1 for that. Since we'll still have v1 code, use v1 for previews as well.
2021-11-10 19:16:16 +01:00
|
|
|
} else if (status) {
|
|
|
|
currentUploads[key].status = status;
|
|
|
|
if (status === 'error') {
|
|
|
|
delete currentUploads[key].uploader;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return { ...state, currentUploads };
|
|
|
|
},
|
|
|
|
[ACTIONS.UPDATE_UPLOAD_REMOVE]: (state: PublishState, action) => {
|
2021-12-07 15:48:09 +01:00
|
|
|
const { guid, params } = action.data;
|
|
|
|
const key = guid || getOldKeyFromParam(params);
|
Support resume-able upload via tus (#186)
* Publish button: use spinner instead of "Publishing..."
Looks better, plus the preview could take a while sometimes.
* Refactor `doPublish`. No functional change
This is to allow `doPublish` to accept a custom payload as an input (for resuming uploads), instead of always resolving it from the redux data.
* Add doPublishResume
* Support resume-able upload via tus
## Issue
38 Handle resumable file upload
## Notes
Since we can't serialize a File object, we'll need to the user to re-select the file to resume.
* Exclude "modified date" for Firefox/Android
## Issue
It appears that the modification date of the Android file changes when selected, so that file was deemed "different" when trying to resume upload.
## Change
Exclude modification date for now. Let's assume a smart user.
* Move 'currentUploads' to 'publish' reducer
`publish` is currently rehydrated, so we can ride on that and don't need to store the `currentUploads` in `localStorage` for persistence. This would allow us to store Markdown Post data too, as `localStorage` has a 5MB limit per app.
We could have also made `webReducer` rehydrate, but in this repo, there is no need to split it to another reducer. It also makes more sense to be part of publish anyway (at least to me).
This change is mostly moving items between files, with the exception of
1. An additional REHYDRATE in the publish reducer to clean up the tusUploader.
2. Not clearing `currentUploads` in CLEAR_PUBLISH.
* Restore v1 code for livestream replay, etc.
v2 (tus) does not handle `remote_url`, so the app still needs v1 for that. Since we'll still have v1 code, use v1 for previews as well.
2021-11-10 19:16:16 +01:00
|
|
|
|
2021-12-07 15:48:09 +01:00
|
|
|
if (state.currentUploads[key]) {
|
|
|
|
const currentUploads = Object.assign({}, state.currentUploads);
|
|
|
|
delete currentUploads[key];
|
|
|
|
tusUnlockAndNotify(key);
|
|
|
|
tusRemoveAndNotify(key);
|
Support resume-able upload via tus (#186)
* Publish button: use spinner instead of "Publishing..."
Looks better, plus the preview could take a while sometimes.
* Refactor `doPublish`. No functional change
This is to allow `doPublish` to accept a custom payload as an input (for resuming uploads), instead of always resolving it from the redux data.
* Add doPublishResume
* Support resume-able upload via tus
## Issue
38 Handle resumable file upload
## Notes
Since we can't serialize a File object, we'll need to the user to re-select the file to resume.
* Exclude "modified date" for Firefox/Android
## Issue
It appears that the modification date of the Android file changes when selected, so that file was deemed "different" when trying to resume upload.
## Change
Exclude modification date for now. Let's assume a smart user.
* Move 'currentUploads' to 'publish' reducer
`publish` is currently rehydrated, so we can ride on that and don't need to store the `currentUploads` in `localStorage` for persistence. This would allow us to store Markdown Post data too, as `localStorage` has a 5MB limit per app.
We could have also made `webReducer` rehydrate, but in this repo, there is no need to split it to another reducer. It also makes more sense to be part of publish anyway (at least to me).
This change is mostly moving items between files, with the exception of
1. An additional REHYDRATE in the publish reducer to clean up the tusUploader.
2. Not clearing `currentUploads` in CLEAR_PUBLISH.
* Restore v1 code for livestream replay, etc.
v2 (tus) does not handle `remote_url`, so the app still needs v1 for that. Since we'll still have v1 code, use v1 for previews as well.
2021-11-10 19:16:16 +01:00
|
|
|
|
2021-12-07 15:48:09 +01:00
|
|
|
return { ...state, currentUploads };
|
|
|
|
}
|
|
|
|
|
|
|
|
return state;
|
Support resume-able upload via tus (#186)
* Publish button: use spinner instead of "Publishing..."
Looks better, plus the preview could take a while sometimes.
* Refactor `doPublish`. No functional change
This is to allow `doPublish` to accept a custom payload as an input (for resuming uploads), instead of always resolving it from the redux data.
* Add doPublishResume
* Support resume-able upload via tus
## Issue
38 Handle resumable file upload
## Notes
Since we can't serialize a File object, we'll need to the user to re-select the file to resume.
* Exclude "modified date" for Firefox/Android
## Issue
It appears that the modification date of the Android file changes when selected, so that file was deemed "different" when trying to resume upload.
## Change
Exclude modification date for now. Let's assume a smart user.
* Move 'currentUploads' to 'publish' reducer
`publish` is currently rehydrated, so we can ride on that and don't need to store the `currentUploads` in `localStorage` for persistence. This would allow us to store Markdown Post data too, as `localStorage` has a 5MB limit per app.
We could have also made `webReducer` rehydrate, but in this repo, there is no need to split it to another reducer. It also makes more sense to be part of publish anyway (at least to me).
This change is mostly moving items between files, with the exception of
1. An additional REHYDRATE in the publish reducer to clean up the tusUploader.
2. Not clearing `currentUploads` in CLEAR_PUBLISH.
* Restore v1 code for livestream replay, etc.
v2 (tus) does not handle `remote_url`, so the app still needs v1 for that. Since we'll still have v1 code, use v1 for previews as well.
2021-11-10 19:16:16 +01:00
|
|
|
},
|
|
|
|
[ACTIONS.REHYDRATE]: (state: PublishState, action) => {
|
|
|
|
if (action && action.payload && action.payload.publish) {
|
|
|
|
const newPublish = { ...action.payload.publish };
|
|
|
|
|
|
|
|
// Cleanup for 'publish::currentUploads'
|
|
|
|
if (newPublish.currentUploads) {
|
2021-12-07 15:48:09 +01:00
|
|
|
const uploadKeys = Object.keys(newPublish.currentUploads);
|
|
|
|
if (uploadKeys.length > 0) {
|
|
|
|
// Clear uploader and corrupted params
|
|
|
|
uploadKeys.forEach((key) => {
|
|
|
|
const params = newPublish.currentUploads[key].params;
|
|
|
|
if (!params || Object.keys(params).length === 0) {
|
|
|
|
delete newPublish.currentUploads[key];
|
|
|
|
} else {
|
|
|
|
delete newPublish.currentUploads[key].uploader;
|
|
|
|
}
|
|
|
|
});
|
|
|
|
} else {
|
|
|
|
tusClearRemovedUploads();
|
|
|
|
}
|
Support resume-able upload via tus (#186)
* Publish button: use spinner instead of "Publishing..."
Looks better, plus the preview could take a while sometimes.
* Refactor `doPublish`. No functional change
This is to allow `doPublish` to accept a custom payload as an input (for resuming uploads), instead of always resolving it from the redux data.
* Add doPublishResume
* Support resume-able upload via tus
## Issue
38 Handle resumable file upload
## Notes
Since we can't serialize a File object, we'll need to the user to re-select the file to resume.
* Exclude "modified date" for Firefox/Android
## Issue
It appears that the modification date of the Android file changes when selected, so that file was deemed "different" when trying to resume upload.
## Change
Exclude modification date for now. Let's assume a smart user.
* Move 'currentUploads' to 'publish' reducer
`publish` is currently rehydrated, so we can ride on that and don't need to store the `currentUploads` in `localStorage` for persistence. This would allow us to store Markdown Post data too, as `localStorage` has a 5MB limit per app.
We could have also made `webReducer` rehydrate, but in this repo, there is no need to split it to another reducer. It also makes more sense to be part of publish anyway (at least to me).
This change is mostly moving items between files, with the exception of
1. An additional REHYDRATE in the publish reducer to clean up the tusUploader.
2. Not clearing `currentUploads` in CLEAR_PUBLISH.
* Restore v1 code for livestream replay, etc.
v2 (tus) does not handle `remote_url`, so the app still needs v1 for that. Since we'll still have v1 code, use v1 for previews as well.
2021-11-10 19:16:16 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
return newPublish;
|
|
|
|
}
|
|
|
|
|
|
|
|
return state;
|
2021-10-17 10:36:14 +02:00
|
|
|
},
|
|
|
|
},
|
|
|
|
defaultState
|
|
|
|
);
|