Hallo, danke an Martin und Rolf!
Ja, gut lesbarer und verständlicher Code ist Gold wert. Aber überlege dabei immer auch: Würde jemand anders den Code auch verstehen? Oder du selbst, wenn du das Projekt zwei Jahre später mal wieder anfassen musst?
Genau darum geht's auch irgendwie...
Nur mit "animationend" Listenern passiert eine ziemlich hässliche Callback Verschachtelung mit einer ungewollt erzwungenen Filetierung von vielleicht zusammengehörigem Code, nach dem Schema
// MMMMMMMMMH - CODESALAT! :P
function ueberDrueberFunction() {
function ersteFunktion() {
erstesElement.classList.remove("animation");
zweitesElement.addEventListener("animationend", zweiteFunktion);
zweitesElement.classList.add("animation");
// DO OTHER STUFF 1 ONLY WHEN FINISHED
}
function zweiteFunktion() {
zweitesElement.classList.remove("animation");
drittesElement.addEventListener("animationend", dritteFunktion);
drittesElement.classList.add("animation");
// DO OTHER STUFF 2 ONLY WHEN FINISHED
}
function dritteFunktion() {...}
erstesElement.addEventListener("animationend", ersteFunktion);
erstesElement.classList.add("animation");
}
(Ja, könnte man vielleicht mit bind refactoren, geschenkt)
...wohingegen mein Schema doch recht übersichtlich und gut leserlich bleibt (wenn man animationend mit einer Resolve Rückgabe verknüpft):
async function functionMitPromiseWennAnimationEnde(args) {
...
}
async function ueberDrueberFunction() {
await functionMitPromiseWennAnimationEnde({element: erstesElement, animation: "animation"});
// DO OTHER STUFF 1
await functionMitPromiseWennAnimationEnde({element: zweitesElement, animation: "animation"});
// DO OTHER STUFF 2
await functionMitPromiseWennAnimationEnde({element: drittesElement, animation: "animationAnders"});
// DO OTHER STUFF 3
}