Even if you invoke them in a Promise, they're still callbacks because you expect them as arguments.
My argument is that they should not be there at all since the native .then() covers all the cases. Now you have onEndSave/onAfterSave/onError/then/catch instead of just then/catch.
Also the onBeforeSave/onStartSave callbacks are one step away from adding onBeforeStartSave, onAfterStartSave, onBeforeAfterStartSave. Why do you have two callbacks for the same event?
Do you see the problem this approach? Your API is unnecessarily wide and that makes it harder for everybody involved: harder for you to cover all the possible events and harder for the next developer to make sense of all the possible+identical ways to do one thing.
[comment deleted]bfred.it 2958 days ago. link 1 point ▲▼
Way too many callbacks.
This should be a one-shot function like https://github.com/rndme/download that saves the file on the spot. Its post-callbacks should just be set as .then(done, errored), not passed as an option. Its before-callbacks should not be callbacks, but just functions that the user calls before `save()`
The whole thing is a bit enterprisey, including shortcut functions that are only used once, that let you write
createBlob(data, type);
instead of
new window.Blob([data], {type});
Also .abort() doesn't really stop anything since onSave is essentially called in the frame and it doesn't abort the only asynchonous function: `saveWithFileReader`
I wrote this library in a way to leave the original video API intact, so once the <video> is "enabled" you can just call its methods and listen to its events like you normally would.