Jakie są dobre abstrakcje dla złożonych animacji?

W opisywanym problemie istnieje pojęcie stanu systemu . Animacje są stanowe, a zatem każda ich kompozycja jest tak samo stanowa, a prawdopodobnie nawet bardziej.

Przeczytaj Ten artykuł wyjaśniający, jak zastosować FSM do zaimplementowania niestandardowej podpowiedzi w JavaScript:

Ten przykład może wydawać się nieco zawiły, ale robi zilustruj punkt: maszyna skończonych Stanów zmusza cię do myślenia jakie stany są możliwe, jakie przejścia między nimi są ważne, kiedy powinny być wyzwalane i jaki kod powinien być wykonany, gdy są .

Ponieważ artykuł IBM zabrania używania jego próbki kodu , zachęcam do przeczytania artykułu Bena Nadela, który używa FSM do implementacji rozwijanego widżetu menu.

Ben pisze:

I ' ve seen the way that Finite State Maszyny mogą podjąć duże, złożone zadania i rozbić je na mniejsze, znacznie łatwiejsze do opanowania Stany. Próbowałem nawet zastosować ten rodzaj mentalności do bindowania i rozłączania procedur obsługi zdarzeń w JavaScript . Ale, teraz, że jestem coraz bardziej komfortowe z maszyn stanowych i, w szczególności, przejścia stanu, Chciałem Spróbować i zastosować ten sposób myślenia do spójnego interfejsu użytkownika (UI) widget.

Oto nieco rozebrana Wersja jego kodu:

var inDefault = {
    description: "I am the state in which only the menu header appears.",
    setup: function() {
       dom.menu.mouseenter(inHover.gotoState);
    },    
    teardown: function() {
         dom.menu.unbind("mouseenter");
    }
};

var inHover = {
    description: "I am the state in which the user has moused-over the header of the menu, but the menu has now shown yet.",
    setup: function() {
        dom.menu.addClass("menuInHover");
        dom.menu.mouseleave(inDefault.gotoState);
        dom.header.click(
            function(event) {
                event.preventDefault();
                gotoState(inActive); 
            }
       );    
    },
    teardown: function() {
        dom.menu.removeClass("menuInHover");
        dom.menu.unbind("mouseleave");
        dom.header.unbind("click"); 
    }    
};

var inActive = {
     description: "I am the state in which the user has clicked on the menu and the menu items have been shown. At this point, menu items can be clicked for fun and profit.",

    setup: function() {
        dom.menu.addClass("menuInActive");
        dom.stage.mousedown(
            function(event) {
                var target = $(event.target);
                if (!target.closest("div.menu").length) {
                    gotoState(inDefault); 
                } 
            }
       );
       dom.header.click(
            function(event) {
                event.preventDefault();
                 gotoState(inHover);

            }
       );
       dom.items.delegate(
            "li.item",
            "click",
            function(event) {
                console.log(
                    "Clicked:",
                    $.trim($(this).text())
               );

            }
       );
    },    
    teardown: function() {
        dom.menu.removeClass("menuInActive"); 
        dom.stage.unbind("mousedown", inDefault.gotoState);
        dom.header.unbind("click"); 
        dom.items.undelegate("li.item", "click");
    }
};

Uwaga to procedury obsługi zdarzeń są związane podczas wprowadzania stanu i niezwiązane podczas opuszczania tego stanu.

Największą zaletą FSMs w rozwiązaniu tego problemu jest to, że sprawiają, że stan jest jawny.

Podczas gdy każda animacja może przyczynić się do stanu obejmującego system, Twój system nigdy nie może być w dwóch stanach naraz lub w ogóle, a debugowanie staje się niemal trywialne, ponieważ zawsze możesz zobaczyć, w jakim stanie system (lub każdy podsystem) jest, biorąc pod uwagę twój stan design ma sens.

Ponadto, zmuszając cię do jawnego projektowania Stanów, użycie FSMs wyklucza możliwość, że nie myślisz o konkretnej kombinacji stanu/działań. Nie ma "niezdefiniowanego zachowania", ponieważ każde przejście jest jawne i jest częścią twojego projektu FSM.

Jeśli przeczytałeś tak daleko, być może zainteresują cię dodatkowe animacje (another intro ). Są teraz domyślne w systemie iOS 8 i zostały poparte przez Kevina Doughty już od kilku lat.

Jest to inne podejście, w którym zachowując stan systemu, zezwalasz na aktywację kilku (nawet przeciwnych) animacji w tym samym czasie. To może dać ci szalone Wyniki , ale to ciekawa koncepcja.

Główną ideą jest unikanie definiowania animacji jako czegoś przechodzącego od wartości bezwzględnej A do wartości bezwzględnej B, a zamiast tego definiowanie animacji jako względem ich wartości końcowej(każda animacja przechodzi od-Delta do 0). To pozwala na płynne łączenie kilku animacji poprzez sumowanie ich wartości względnych w każdym punkcie czasu i unikanie skoków spowodowanych odwróceniem lub anulowaniem:

_{(źródło: ronnqvi.st)}

Dla barebone Framework-agnostyczny przykład animacji addytywnych, sprawdź moduł alexkuz addytywnej animacji ( demo).

Jeśli czytałeś tak daleko, musisz być naprawdę zainteresowany animacjami! Obecnie jestem zaintrygowany podejściem react-state-stream . Proponuje wyrażanie animacji jako leniwych sekwencji Stanów. Otwiera to wiele możliwości, takich jak wyrażanie nieskończonych animacji, stopniowe dodawanie i usuwanie przekształceń z animacji itp.

Jeśli chcesz przeczytać jeden artykuł o animacji, proponuję, aby myśli o animacji autor: Cheng Lou.