-
Notifications
You must be signed in to change notification settings - Fork 489
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: use direct links to download all files #1894
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Re 1 – see inline comment
Re 2 – ok to remove the dowload-file.js
, do you have something more in mind?
dabaee3
to
7ddf870
Compare
The TARs are a thing on the gateway now: ipfs/kubo#9029 This PR can be unblocked and worked on 😃 |
License: MIT Signed-off-by: Henrique Dias <hacdias@gmail.com>
I decided to revitalise this PR since we now have TAR response formats on our gateway (ipfs/kubo#9029). That lets us download directories directly from the gateway without the need to use the API v0 POST method. Therefore, we do not need to keep anything in memory and it is all streamed to the user. This allows to massively simplify the code, removing a lot of old bits that are no longer relevant 🪩 This can be tested with Kubo from master, and with 0.17.0 RC-1. I'll mark this as ready for review as its been open for many months, but it's finally possible to review and test this PR. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm, small UX question below
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The changes look okay, but we're removing some functionality: progress updates and download aborting. Is that intended, or am I missing something?
Note: I do agree that this is a significant improvement, and resolves #1887 but I'm wondering if there is a way we can keep the ability to cancel a download, or display download progress. Fine with a separate issue for those items
src/files/FilesPage.js
Outdated
const url = await doFilesDownloadLink(files) | ||
const link = document.createElement('a') | ||
link.href = url | ||
link.click() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
non-blocking Q: instead of creating an element and then programmatically clicking on it can we have the thing the users click have the appropriate URL?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note: I do agree that this is a significant improvement, and resolves #1887 but I'm wondering if there is a way we can keep the ability to cancel a download, or display download progress. Fine with a separate issue for those items
Downloads will be handled by the browser UI. The user can just cancel it through the browser UI. We only had the option to cancel and display progress on the Web UI itself because we were storing every single byte of data in-memory before downloading.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
non-blocking Q: instead of creating an element and then programmatically clicking on it can we have the thing the users click have the appropriate URL?
Yes and no. If you select multiple files, what link do you put? You can't as we calculate the CID dynamically. Then we'd need different behaviour according to the number of files selected and that's a bit of a hassle. Let's keep it like this to be uniform with the CAR downloading behaviour.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can't we just redirect the users to download? it will prompt the user to download and not go away from current page too?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@whizzzkid I changed to window.location.href = url
. However, it has the same behaviour in my browser as clicking a link. Because clicking a link just leads to redirection. I'm interested in knowing what is happening in your browser, because I can't understand. I'll post a video here in a bit (see #1894 (comment)).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
non-blocking nits
src/files/FilesPage.js
Outdated
const url = await doFilesDownloadLink(files) | ||
const link = document.createElement('a') | ||
link.href = url | ||
link.click() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can't we just redirect the users to download? it will prompt the user to download and not go away from current page too?
render () { | ||
const { t, tReady, animateOnStart, count, size, unselect, remove, share, setPinning, download, downloadProgress, rename, inspect, className, style, isMfs, ...props } = this.props | ||
const { t, tReady, animateOnStart, count, size, unselect, remove, share, setPinning, download, rename, inspect, className, style, isMfs, ...props } = this.props |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we sort these alphabetically?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unless you know how to do it automatically, please don't make me do it 😅
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
eslint can do it automatically, we should not be forcing devs to do code style management
@SgtPooki @whizzzkid I addressed most of your comments (see replies). This is the behaviour of the current PR: cast.mp4 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks a ton for remembering this PR and coming back to close it out @hacdias !
Do we expect any issues with how this will work within electron? |
I think it should be fine. We already had download links we this behaviour before and they were not a problem. |
## [2.21.0](v2.20.0...v2.21.0) (2022-12-09) CID `bafybeiequgo72mrvuml56j4gk7crewig5bavumrrzhkqbim6b3s2yqi7ty` --- ### Features * use direct links to download all files ([#1894](#1894)) ([d1bcbbf](d1bcbbf)) ### Bug Fixes * support /quic-v1 ([#2073](#2073)) ([04eb7b3](04eb7b3)) ### Trivial Changes * bump playwright deps ([#2066](#2066)) ([f138960](f138960)) * **ci:** fix flaky unit test ([#2068](#2068)) ([bd038cd](bd038cd)), closes [/github.com//issues/2065#issuecomment-1315933342](https://github.com/ipfs//github.com/ipfs/ipfs-webui/issues/2065/issues/issuecomment-1315933342) * Pull transifex translations ([#2069](#2069)) ([36f3641](36f3641)) * revert [#2032](#2032) ([#2064](#2064)) ([9473d7d](9473d7d)), closes [/github.com//pull/2032#issuecomment-1278928440](https://github.com/ipfs//github.com/ipfs/ipfs-webui/pull/2032/issues/issuecomment-1278928440)
🎉 This PR is included in version 2.21.0 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
This closes #1887 by using the gateway URLs to download the files. There's two things to mention:
download
attribute, but it seems to still use the nameget.tar.gz
sadly. Any suggestions?License: MIT
Signed-off-by: Henrique Dias hacdias@gmail.com