feat: remove torrent immediately, but allow Undo

[dsernst]

What is the purpose of this pull request? (put an "X" next to item)

[ ] Documentation update [ ] Bug fix [x] New feature [ ] Other, please explain:

What changes did you make? (Give an overview)

This is a continuation of the work started in PR https://github.com/webtorrent/webtorrent-desktop/pull/1087 to replace the Remove a Torrent UI modal with a Snackbar style alert + option to Undo.

The 3 other methods of removing a torrent:

• Right click in list > Remove Data File
• Transfers menu > Remove All From List
• Transfers menu > Remove All Data Files

all continue to use the same modal as before (per discussion in https://github.com/webtorrent/webtorrent-desktop/issues/970).

Which issue (if any) does this pull request address?

https://github.com/webtorrent/webtorrent-desktop/issues/970, https://github.com/webtorrent/webtorrent-desktop/pull/1087 (abandoned PR)

👍 This is tested locally and works on my machine running OS X 10.14.6.

[dsernst]

From https://github.com/webtorrent/webtorrent-desktop/issues/970#issuecomment-249908009:

This PR doesn't add support for a Ctrl-Z style Undo hotkey.

I wanted to get something working out the door first, & don't think the hotkey ought to be a blocker.

[dsernst]

One important thing to note:

The Undo feature currently only works for magnet links, which doesn't include the Featured torrents on the WebTorrent Desktop homepage, so I don't know how to demo that properly.

✅ I confirmed that the Undo feature does work on a torrent with good magnet links.

• [ ] If someone can point me to a good public demo torrent w/ magnet support, I can make a quick gif demo of that to show it resuming etc.

Even better would be to fix this up so the Undo works for torrents added via a .torrent file.

I can work on that, but would appreciate a little advice on how best to approach.

Currently, the locally stored ${appConfig}/Torrents/ files are still being deleted immediately.

• So one solution is to simply delay deleting the .torrent files until after the Snackbar autohides itself after 5 seconds. That ought to work, but if the Application quits before the 5 second timer, the file may never get cleaned up, which doesn't seem great.

• A different solution is to remember how the torrent was added in first place, such as via pasting in a link like https://archive.org/download/art_of_war_librivox/art_of_war_librivox_archive.torrent. Then the Undo call could go try to add that way again. But as far as I could tell, these links aren't being stored within torrentSummary right now, just the path to the new local .torrent file.

[subins2000]

I tested this locally and the Undo option also worked for the Featured torrents in WebTorrent.

System: Ubuntu 18.04

[dsernst]

Fixed merge conflict

[dsernst]

Best path forward, per discussion in today's Webtorrent Maintainers call:

So one solution is to simply delay deleting the .torrent files until after the Snackbar autohides itself after 5 seconds. That ought to work, but if the Application quits before the 5 second timer, the file may never get cleaned up, which doesn't seem great.

We can add a flag like pendingDelete to the torrent. The UI will hide these items, so from the user's perspective it's been deleted. Then have a function like removePendingDeletes that goes through and actually deletes it from the state. That function can be called after the Undo's timer ends, as well as on app shutdown and app start (in case the app had crashed).

[github-actions[bot]]

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

[dsernst]

Yes it’s still relevant, if we want to simplify the UI (replace two click modal w/ one click undoable).

Nothing’s changed since my last comment.

• [x] This works great for .torrent files.
• [ ] Undo doesn’t work for magnet links yet. There is a relatively clear path forward.

I just haven’t taken the time to work on this lately, as I’ve been focused on other projects 😄

[github-actions[bot]]

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

[DiegoRBaquero]

@dsernst What's the path forward of with magnets, I'll take it on myself

[dsernst]

@dsernst What's the path forward of with magnets, I'll take it on myself

Awesome to hear. 🎉

Last I spoke about this w/ @feross, he liked this approach:

Best path forward, per discussion in today's Webtorrent Maintainers call:

So one solution is to simply delay deleting the .torrent files until after the Snackbar autohides itself after 5 seconds. That ought to work, but if the Application quits before the 5 second timer, the file may never get cleaned up, which doesn't seem great.

We can add a flag like pendingDelete to the torrent. The UI will hide these items, so from the user's perspective it's been deleted. Then have a function like removePendingDeletes that goes through and actually deletes it from the state. That function can be called after the Undo's timer ends, as well as on app shutdown and app start (in case the app had crashed).