lbry-desktop/ui/component/webUploadList/internal/web-upload-item.jsx

235 lines
7.4 KiB
React
Raw Normal View History

// @flow
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 React, { useState } from 'react';
import FileSelector from 'component/common/file-selector';
import Button from 'component/button';
2020-01-06 19:32:35 +01:00
import FileThumbnail from 'component/fileThumbnail';
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 * as MODALS from 'constants/modal_types';
import { serializeFileObj } from 'util/file';
Upload: tab sync and various fixes (#428) * Upload: fix redux key clash ## Issue `params` is the "final" value that will be passed to the SDK and `channel` is not a valid argument (it should be `channel_name`). Also, it seems like we only pass the channel ID now and skip the channel name entirely. For the anonymous case, a clash will still happen when since the channel part is hardcoded to `anonymous`. ## Approach Generate a guid in `params` and use that as the key to handle all the cases above. We couldn't use the `uploadUrl` because v1 doesn't have it. The old formula is retained to allow users to retry or cancel their existing uploads one last time (otherwise it will persist forever). The next upload will be using the new key. * Upload: add tab-locking ## Issue - The previous code does detect uploads from multiple tabs, but it was done by handling the CONFLICT error message from the backend. At certain corner-cases, this does not work well. A better way is to not allow resumption while the same file is being uploading from another tab. - When an upload from 1 tab finishes, the GUI on the other tab does not remove the completed item. User either have to refresh or click Cancel. Clicking Cancel results in the 404 backend error. This should be avoided. ## Approach - Added tab synchronization and locking by passing the "locked" and "removed" information through `localStorage`. ## Other considered approaches - Wallet sync -- but decided not to pollute the wallet. - 3rd-party redux tab syncing -- but decided it's not worth adding another module for 1 usage. * Upload: check if locked before confirming delete ## Reproduce Have 2 tabs + paused upload Open "cancel" dialog in one of the tabs. Continue upload in other tab Confirm cancellation in first tab Upload disappears from both tabs, but based on network traffic the upload keeps happening. (If upload finishes the claim seems to get created)
2021-12-07 15:48:09 +01:00
import { tusIsSessionLocked } from 'util/tus';
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
type Props = {
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
uploadItem: FileUploadItem,
doPublishResume: (any) => void,
Upload: tab sync and various fixes (#428) * Upload: fix redux key clash ## Issue `params` is the "final" value that will be passed to the SDK and `channel` is not a valid argument (it should be `channel_name`). Also, it seems like we only pass the channel ID now and skip the channel name entirely. For the anonymous case, a clash will still happen when since the channel part is hardcoded to `anonymous`. ## Approach Generate a guid in `params` and use that as the key to handle all the cases above. We couldn't use the `uploadUrl` because v1 doesn't have it. The old formula is retained to allow users to retry or cancel their existing uploads one last time (otherwise it will persist forever). The next upload will be using the new key. * Upload: add tab-locking ## Issue - The previous code does detect uploads from multiple tabs, but it was done by handling the CONFLICT error message from the backend. At certain corner-cases, this does not work well. A better way is to not allow resumption while the same file is being uploading from another tab. - When an upload from 1 tab finishes, the GUI on the other tab does not remove the completed item. User either have to refresh or click Cancel. Clicking Cancel results in the 404 backend error. This should be avoided. ## Approach - Added tab synchronization and locking by passing the "locked" and "removed" information through `localStorage`. ## Other considered approaches - Wallet sync -- but decided not to pollute the wallet. - 3rd-party redux tab syncing -- but decided it's not worth adding another module for 1 usage. * Upload: check if locked before confirming delete ## Reproduce Have 2 tabs + paused upload Open "cancel" dialog in one of the tabs. Continue upload in other tab Confirm cancellation in first tab Upload disappears from both tabs, but based on network traffic the upload keeps happening. (If upload finishes the claim seems to get created)
2021-12-07 15:48:09 +01:00
doUpdateUploadRemove: (string, any) => void,
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
doOpenModal: (string, {}) => void,
};
export default function WebUploadItem(props: Props) {
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 { uploadItem, doPublishResume, doUpdateUploadRemove, doOpenModal } = props;
const { params, file, fileFingerprint, progress, status, resumable, uploader } = uploadItem;
const [showFileSelector, setShowFileSelector] = useState(false);
Upload: tab sync and various fixes (#428) * Upload: fix redux key clash ## Issue `params` is the "final" value that will be passed to the SDK and `channel` is not a valid argument (it should be `channel_name`). Also, it seems like we only pass the channel ID now and skip the channel name entirely. For the anonymous case, a clash will still happen when since the channel part is hardcoded to `anonymous`. ## Approach Generate a guid in `params` and use that as the key to handle all the cases above. We couldn't use the `uploadUrl` because v1 doesn't have it. The old formula is retained to allow users to retry or cancel their existing uploads one last time (otherwise it will persist forever). The next upload will be using the new key. * Upload: add tab-locking ## Issue - The previous code does detect uploads from multiple tabs, but it was done by handling the CONFLICT error message from the backend. At certain corner-cases, this does not work well. A better way is to not allow resumption while the same file is being uploading from another tab. - When an upload from 1 tab finishes, the GUI on the other tab does not remove the completed item. User either have to refresh or click Cancel. Clicking Cancel results in the 404 backend error. This should be avoided. ## Approach - Added tab synchronization and locking by passing the "locked" and "removed" information through `localStorage`. ## Other considered approaches - Wallet sync -- but decided not to pollute the wallet. - 3rd-party redux tab syncing -- but decided it's not worth adding another module for 1 usage. * Upload: check if locked before confirming delete ## Reproduce Have 2 tabs + paused upload Open "cancel" dialog in one of the tabs. Continue upload in other tab Confirm cancellation in first tab Upload disappears from both tabs, but based on network traffic the upload keeps happening. (If upload finishes the claim seems to get created)
2021-12-07 15:48:09 +01:00
const locked = tusIsSessionLocked(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
function handleFileChange(newFile: WebFile, clearName = true) {
if (serializeFileObj(newFile) === fileFingerprint) {
setShowFileSelector(false);
doPublishResume({ ...params, file_path: newFile });
Upload: tab sync and various fixes (#428) * Upload: fix redux key clash ## Issue `params` is the "final" value that will be passed to the SDK and `channel` is not a valid argument (it should be `channel_name`). Also, it seems like we only pass the channel ID now and skip the channel name entirely. For the anonymous case, a clash will still happen when since the channel part is hardcoded to `anonymous`. ## Approach Generate a guid in `params` and use that as the key to handle all the cases above. We couldn't use the `uploadUrl` because v1 doesn't have it. The old formula is retained to allow users to retry or cancel their existing uploads one last time (otherwise it will persist forever). The next upload will be using the new key. * Upload: add tab-locking ## Issue - The previous code does detect uploads from multiple tabs, but it was done by handling the CONFLICT error message from the backend. At certain corner-cases, this does not work well. A better way is to not allow resumption while the same file is being uploading from another tab. - When an upload from 1 tab finishes, the GUI on the other tab does not remove the completed item. User either have to refresh or click Cancel. Clicking Cancel results in the 404 backend error. This should be avoided. ## Approach - Added tab synchronization and locking by passing the "locked" and "removed" information through `localStorage`. ## Other considered approaches - Wallet sync -- but decided not to pollute the wallet. - 3rd-party redux tab syncing -- but decided it's not worth adding another module for 1 usage. * Upload: check if locked before confirming delete ## Reproduce Have 2 tabs + paused upload Open "cancel" dialog in one of the tabs. Continue upload in other tab Confirm cancellation in first tab Upload disappears from both tabs, but based on network traffic the upload keeps happening. (If upload finishes the claim seems to get created)
2021-12-07 15:48:09 +01:00
if (!params.guid) {
// Can remove this if-block after January 2022.
doUpdateUploadRemove('', 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
} else {
doOpenModal(MODALS.CONFIRM, {
title: __('Invalid file'),
subtitle: __('It appears to be a different or modified file.'),
body: <p className="help--warning">{__('Please select the same file from the initial upload.')}</p>,
onConfirm: (closeModal) => closeModal(),
hideCancel: true,
});
}
}
function handleCancel() {
doOpenModal(MODALS.CONFIRM, {
title: __('Cancel upload'),
subtitle: __('Cancel and remove the selected upload?'),
body: params.name ? <p className="empty">{`lbry://${params.name}`}</p> : undefined,
onConfirm: (closeModal) => {
Upload: tab sync and various fixes (#428) * Upload: fix redux key clash ## Issue `params` is the "final" value that will be passed to the SDK and `channel` is not a valid argument (it should be `channel_name`). Also, it seems like we only pass the channel ID now and skip the channel name entirely. For the anonymous case, a clash will still happen when since the channel part is hardcoded to `anonymous`. ## Approach Generate a guid in `params` and use that as the key to handle all the cases above. We couldn't use the `uploadUrl` because v1 doesn't have it. The old formula is retained to allow users to retry or cancel their existing uploads one last time (otherwise it will persist forever). The next upload will be using the new key. * Upload: add tab-locking ## Issue - The previous code does detect uploads from multiple tabs, but it was done by handling the CONFLICT error message from the backend. At certain corner-cases, this does not work well. A better way is to not allow resumption while the same file is being uploading from another tab. - When an upload from 1 tab finishes, the GUI on the other tab does not remove the completed item. User either have to refresh or click Cancel. Clicking Cancel results in the 404 backend error. This should be avoided. ## Approach - Added tab synchronization and locking by passing the "locked" and "removed" information through `localStorage`. ## Other considered approaches - Wallet sync -- but decided not to pollute the wallet. - 3rd-party redux tab syncing -- but decided it's not worth adding another module for 1 usage. * Upload: check if locked before confirming delete ## Reproduce Have 2 tabs + paused upload Open "cancel" dialog in one of the tabs. Continue upload in other tab Confirm cancellation in first tab Upload disappears from both tabs, but based on network traffic the upload keeps happening. (If upload finishes the claim seems to get created)
2021-12-07 15:48:09 +01:00
if (tusIsSessionLocked(params.guid)) {
// Corner-case: it's possible for the upload to resume in another tab
// after the modal has appeared. Make a final lock-check here.
// We can invoke a toast here, but just do nothing for now.
// The upload status should make things obvious.
} else {
if (uploader) {
if (resumable) {
// $FlowFixMe - couldn't resolve to TusUploader manually.
uploader.abort(true); // TUS
} else {
uploader.abort(); // XHR
}
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
}
Upload: tab sync and various fixes (#428) * Upload: fix redux key clash ## Issue `params` is the "final" value that will be passed to the SDK and `channel` is not a valid argument (it should be `channel_name`). Also, it seems like we only pass the channel ID now and skip the channel name entirely. For the anonymous case, a clash will still happen when since the channel part is hardcoded to `anonymous`. ## Approach Generate a guid in `params` and use that as the key to handle all the cases above. We couldn't use the `uploadUrl` because v1 doesn't have it. The old formula is retained to allow users to retry or cancel their existing uploads one last time (otherwise it will persist forever). The next upload will be using the new key. * Upload: add tab-locking ## Issue - The previous code does detect uploads from multiple tabs, but it was done by handling the CONFLICT error message from the backend. At certain corner-cases, this does not work well. A better way is to not allow resumption while the same file is being uploading from another tab. - When an upload from 1 tab finishes, the GUI on the other tab does not remove the completed item. User either have to refresh or click Cancel. Clicking Cancel results in the 404 backend error. This should be avoided. ## Approach - Added tab synchronization and locking by passing the "locked" and "removed" information through `localStorage`. ## Other considered approaches - Wallet sync -- but decided not to pollute the wallet. - 3rd-party redux tab syncing -- but decided it's not worth adding another module for 1 usage. * Upload: check if locked before confirming delete ## Reproduce Have 2 tabs + paused upload Open "cancel" dialog in one of the tabs. Continue upload in other tab Confirm cancellation in first tab Upload disappears from both tabs, but based on network traffic the upload keeps happening. (If upload finishes the claim seems to get created)
2021-12-07 15:48:09 +01:00
// The second parameter (params) can be removed after January 2022.
doUpdateUploadRemove(params.guid, 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
}
closeModal();
},
});
}
function resolveProgressStr() {
Upload: tab sync and various fixes (#428) * Upload: fix redux key clash ## Issue `params` is the "final" value that will be passed to the SDK and `channel` is not a valid argument (it should be `channel_name`). Also, it seems like we only pass the channel ID now and skip the channel name entirely. For the anonymous case, a clash will still happen when since the channel part is hardcoded to `anonymous`. ## Approach Generate a guid in `params` and use that as the key to handle all the cases above. We couldn't use the `uploadUrl` because v1 doesn't have it. The old formula is retained to allow users to retry or cancel their existing uploads one last time (otherwise it will persist forever). The next upload will be using the new key. * Upload: add tab-locking ## Issue - The previous code does detect uploads from multiple tabs, but it was done by handling the CONFLICT error message from the backend. At certain corner-cases, this does not work well. A better way is to not allow resumption while the same file is being uploading from another tab. - When an upload from 1 tab finishes, the GUI on the other tab does not remove the completed item. User either have to refresh or click Cancel. Clicking Cancel results in the 404 backend error. This should be avoided. ## Approach - Added tab synchronization and locking by passing the "locked" and "removed" information through `localStorage`. ## Other considered approaches - Wallet sync -- but decided not to pollute the wallet. - 3rd-party redux tab syncing -- but decided it's not worth adding another module for 1 usage. * Upload: check if locked before confirming delete ## Reproduce Have 2 tabs + paused upload Open "cancel" dialog in one of the tabs. Continue upload in other tab Confirm cancellation in first tab Upload disappears from both tabs, but based on network traffic the upload keeps happening. (If upload finishes the claim seems to get created)
2021-12-07 15:48:09 +01:00
if (locked) {
return __('File being uploaded in another tab or window.');
}
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 (!uploader) {
if (status === 'notify') {
return __('File uploaded to server.');
} else {
return __('Stopped.');
}
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 (resumable) {
if (status) {
switch (status) {
case 'retry':
return __('Uploading...');
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
case 'error':
return __('Failed.');
2021-11-22 09:06:28 +01:00
case 'conflict':
return __('Stopped. Duplicate session detected.');
case 'notify':
return __('Processing file. Please wait...');
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
default:
return status;
}
} else {
const progressInt = parseInt(progress);
return progressInt === 100 ? __('Processing...') : __('Uploading...');
}
} else {
return __('Uploading...');
}
}
function getRetryButton() {
Upload: tab sync and various fixes (#428) * Upload: fix redux key clash ## Issue `params` is the "final" value that will be passed to the SDK and `channel` is not a valid argument (it should be `channel_name`). Also, it seems like we only pass the channel ID now and skip the channel name entirely. For the anonymous case, a clash will still happen when since the channel part is hardcoded to `anonymous`. ## Approach Generate a guid in `params` and use that as the key to handle all the cases above. We couldn't use the `uploadUrl` because v1 doesn't have it. The old formula is retained to allow users to retry or cancel their existing uploads one last time (otherwise it will persist forever). The next upload will be using the new key. * Upload: add tab-locking ## Issue - The previous code does detect uploads from multiple tabs, but it was done by handling the CONFLICT error message from the backend. At certain corner-cases, this does not work well. A better way is to not allow resumption while the same file is being uploading from another tab. - When an upload from 1 tab finishes, the GUI on the other tab does not remove the completed item. User either have to refresh or click Cancel. Clicking Cancel results in the 404 backend error. This should be avoided. ## Approach - Added tab synchronization and locking by passing the "locked" and "removed" information through `localStorage`. ## Other considered approaches - Wallet sync -- but decided not to pollute the wallet. - 3rd-party redux tab syncing -- but decided it's not worth adding another module for 1 usage. * Upload: check if locked before confirming delete ## Reproduce Have 2 tabs + paused upload Open "cancel" dialog in one of the tabs. Continue upload in other tab Confirm cancellation in first tab Upload disappears from both tabs, but based on network traffic the upload keeps happening. (If upload finishes the claim seems to get created)
2021-12-07 15:48:09 +01:00
if (!resumable || locked) {
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 null;
}
if (uploader) {
// Should still be uploading. Don't show.
return null;
} else {
// Refreshed or connection broken ...
if (status === 'notify') {
// ... but 'notify' sent, so we have to assume it is processed.
// Can't do much until the polling API is available.
return null;
}
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 isFileActive = file instanceof File;
return (
<Button
label={isFileActive ? __('Resume') : __('Retry')}
button="link"
onClick={() => {
if (isFileActive) {
doPublishResume({ ...params, file_path: file });
} else {
setShowFileSelector(true);
}
}}
disabled={showFileSelector}
/>
);
}
}
function getCancelButton() {
Upload: tab sync and various fixes (#428) * Upload: fix redux key clash ## Issue `params` is the "final" value that will be passed to the SDK and `channel` is not a valid argument (it should be `channel_name`). Also, it seems like we only pass the channel ID now and skip the channel name entirely. For the anonymous case, a clash will still happen when since the channel part is hardcoded to `anonymous`. ## Approach Generate a guid in `params` and use that as the key to handle all the cases above. We couldn't use the `uploadUrl` because v1 doesn't have it. The old formula is retained to allow users to retry or cancel their existing uploads one last time (otherwise it will persist forever). The next upload will be using the new key. * Upload: add tab-locking ## Issue - The previous code does detect uploads from multiple tabs, but it was done by handling the CONFLICT error message from the backend. At certain corner-cases, this does not work well. A better way is to not allow resumption while the same file is being uploading from another tab. - When an upload from 1 tab finishes, the GUI on the other tab does not remove the completed item. User either have to refresh or click Cancel. Clicking Cancel results in the 404 backend error. This should be avoided. ## Approach - Added tab synchronization and locking by passing the "locked" and "removed" information through `localStorage`. ## Other considered approaches - Wallet sync -- but decided not to pollute the wallet. - 3rd-party redux tab syncing -- but decided it's not worth adding another module for 1 usage. * Upload: check if locked before confirming delete ## Reproduce Have 2 tabs + paused upload Open "cancel" dialog in one of the tabs. Continue upload in other tab Confirm cancellation in first tab Upload disappears from both tabs, but based on network traffic the upload keeps happening. (If upload finishes the claim seems to get created)
2021-12-07 15:48:09 +01:00
if (!locked) {
if (status === 'notify') {
return (
<Button
button="link"
label={__('Remove')}
onClick={() => {
doOpenModal(MODALS.CONFIRM, {
title: __('Remove entry?'),
body: (
<>
<p>
{__('The file was successfully uploaded, but we could not retrieve the confirmation status.')}
</p>
<p>
{__(
'Wait 5-10 minutes, then refresh and check the Uploads list and Wallet transactions before attempting to re-upload.'
)}
</p>
<p className="section__subtitle">
{__('This entry can be safely removed if the transaction is visible in those pages.')}
</p>
<div className="help--warning">
<p>{__('Press OK to clear this entry from the "Currently Uploading" list.')}</p>
</div>
</>
),
onConfirm: (closeModal) => {
doUpdateUploadRemove(params.guid);
closeModal();
},
});
}}
/>
);
}
Upload: tab sync and various fixes (#428) * Upload: fix redux key clash ## Issue `params` is the "final" value that will be passed to the SDK and `channel` is not a valid argument (it should be `channel_name`). Also, it seems like we only pass the channel ID now and skip the channel name entirely. For the anonymous case, a clash will still happen when since the channel part is hardcoded to `anonymous`. ## Approach Generate a guid in `params` and use that as the key to handle all the cases above. We couldn't use the `uploadUrl` because v1 doesn't have it. The old formula is retained to allow users to retry or cancel their existing uploads one last time (otherwise it will persist forever). The next upload will be using the new key. * Upload: add tab-locking ## Issue - The previous code does detect uploads from multiple tabs, but it was done by handling the CONFLICT error message from the backend. At certain corner-cases, this does not work well. A better way is to not allow resumption while the same file is being uploading from another tab. - When an upload from 1 tab finishes, the GUI on the other tab does not remove the completed item. User either have to refresh or click Cancel. Clicking Cancel results in the 404 backend error. This should be avoided. ## Approach - Added tab synchronization and locking by passing the "locked" and "removed" information through `localStorage`. ## Other considered approaches - Wallet sync -- but decided not to pollute the wallet. - 3rd-party redux tab syncing -- but decided it's not worth adding another module for 1 usage. * Upload: check if locked before confirming delete ## Reproduce Have 2 tabs + paused upload Open "cancel" dialog in one of the tabs. Continue upload in other tab Confirm cancellation in first tab Upload disappears from both tabs, but based on network traffic the upload keeps happening. (If upload finishes the claim seems to get created)
2021-12-07 15:48:09 +01:00
return <Button label={__('Cancel')} button="link" onClick={handleCancel} />;
}
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
}
function getFileSelector() {
return (
<div className="claim-preview--padded">
<FileSelector
label={__('File')}
onFileChosen={handleFileChange}
// https://stackoverflow.com/questions/19107685/safari-input-type-file-accept-video-ignores-mp4-files
accept={'video/mp4,video/x-m4v,video/*,audio/*'}
placeholder={__('Select the file to resume upload...')}
/>
</div>
);
}
function getProgressBar() {
return (
<>
<div className="claim-upload__progress--label">lbry://{params.name}</div>
<div className={'claim-upload__progress--outer card--inline'}>
<div className={'claim-upload__progress--inner'} style={{ width: `${progress}%` }}>
2021-11-22 09:06:28 +01:00
<span className="claim-upload__progress--inner-text">{resolveProgressStr()}</span>
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
</div>
</div>
</>
);
}
React.useEffect(() => {
if (locked && showFileSelector) {
setShowFileSelector(false);
}
}, [locked, showFileSelector]);
return (
<li className={'web-upload-item claim-preview claim-preview--inactive card--inline'}>
2020-01-06 19:32:35 +01:00
<FileThumbnail thumbnail={params.thumbnail_url} />
<div className={'claim-preview-metadata'}>
<div className="claim-preview-info">
2020-01-30 23:25:15 +01:00
<div className="claim-preview__title">{params.title}</div>
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
<div className="card__actions--inline">
{getRetryButton()}
{getCancelButton()}
</div>
</div>
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
{showFileSelector && getFileSelector()}
{!showFileSelector && getProgressBar()}
</div>
</li>
);
}