Refactor upload queue actions

[swissspidy]

Generating subtitles & optimizing an existing image are very similar in that ideally we add an item to the queue without having a file at the beginning. The file only exists after generating the subtitles or after downloading the original file.

How can this be better implemented? If the file is in the queue ASAP, then buttons can be disabled in the UI and actions be cancelled again by the user.

Maybe such actions can be passed as a callback which then is awaited in the prepareItem step or so

[swissspidy]

Actually there is a huge opportunity to make the media store more modular and reduce repetition.

Sinilar to the multiple transcode steps, every action could be refactored to be such a step. From the download of the original file to poster generation, resizing and compressing to eventual upload.

Instead of start & finish actions and numerous „-ing“ status, there is just a „currentOperation“ field that indicates the current operation in the „queue“ of an item‘s operations.

When adding a new item, how is this list determined?

Can operations/steps be „registered“ to make the store more extensible and testable?

Or how to disable the sibscribe() calls during tests?

[swissspidy]

Or how to disable the sibscribe() calls during tests?

Maybe using some sort of recursion... addItem() could call processItem() right away (to do the first operation), which then continues to call itself until the upload finishes..

[swissspidy]

Generating subtitles & optimizing an existing image are very similar in that ideally we add an item to the queue without having a file at the beginning. If the "file" is in the queue ASAP, then buttons can be disabled in the UI and actions be cancelled again by the user.

Relevant for these actions specifically:

• addItemFromUrl
• muteExistingVideo
• addSubtitlesForExistingVideo
• optimizeExistingItem

They all use fetchRemoteFile. By adding the item to the queue without a file first, an AbortController can be passed to fetchRemoteFile, allowing to cancel that remote fetch early. That would be nice, as the fetch could potentially be slow.

On the other hand, this will add some complexity though, and perhaps make it tricky to add types since item.file doesn't always exist.