Kuinka valitsin animaatiokirjaston pasianssipelilleni

Animaatiokirjastoille on tarjolla runsaasti sekä CSS- että JavaScript-kirjastoja. Itse asiassa niin paljon, että oikean valitseminen projektiisi voi tuntua mahdottomalta. Juuri tämän tilanteen kohtasin, kun päätin rakentaa online-pasianssipeli. Tiesin tarvitsevani animaatiokirjaston, mutta mikä oli oikea valinta?

Tässä artikkelissa käyn läpi, mitä huomioita tein, mitä pitää ottaa huomioon, ja esittelen sinulle joitain suosituimmista saatavilla olevista kirjastoista. Käyn kanssasi läpi joitain tosielämän esimerkkejä havainnollistaakseni pointtejani, ja toivottavasti olet lopulta paremmin varusteltu kuin minä, kun minun piti valita animaatiokirjasto.

Kilometrimääräsi näillä neuvoilla voi tietysti vaihdella. Kaikki, mitä jaan täällä, liittyy tiettyyn asiaan, jonka halusin rakentaa. Projektillasi voi olla täysin erilaiset vaatimukset ja prioriteetit, ja se on OK. Mielestäni tässä on tärkeää saada ensikäden selvitys ajattelee kuin etupään kehittäjä tietyllä tavoitteella.

Siitä puheen ollen, pidän itseäni etupään kehittäjänä, mutta taustani on suunnittelultaan erittäin raskas. Joten tiedän koodin, mutta en siinä määrin kuin joku, joka on JavaScript-insinööri. Halusin vain selventää asian, koska kokemus voi varmasti vaikuttaa lopulliseen päätökseen.

Tässä on tavoite

Ennen kuin ryhdymme mihinkään päätöksentekoon, katsotaanpa, millaisia ​​animaatioita minun piti tehdä tässä CSS-Tricks-versiossa pelistä:

Aika söpöä, eikö? Näissä animaatioissa ei ole mitään aivan triviaalia. Paljon tapahtuu - joskus samanaikaisesti - ja paljon orkestroitavaa. Lisäksi suurin osa animaatioista käynnistyy käyttäjien vuorovaikutuksesta. Joten minulle jäi muutama prioriteetti päätökseni suhteen:

• Tasaiset animaatiot: Animaatioiden käyttötavalla voi olla suuri vaikutus siihen, toimivatko ne sujuvasti vai näyttävätkö ne hieman katkonaisia.
• Suorituskyky: Minkä tahansa kirjaston ottaminen käyttöön lisää painoarvoa projektille, ja halusin pelini olevan mahdollisimman laiha.
• Mukavuus: Halusin mukavan, puhtaan syntaksin, joka helpottaa animaatioiden kirjoittamista ja hallintaa. Vaihtaisin jopa hieman ylimääräistä käyttömukavuutta pieneen suorituskykykustannuksiin, jos sen avulla voin kirjoittaa parempaa, paremmin ylläpidettävää koodia. Tämä taas lupaa hyvää suunnittelijaksi kehittyneelle kehittäjälle.
• Selaimen tuki: Tietenkin halusin pelini toimivan millä tahansa nykyaikaisella selaimella käyttämällä jonkinlaista progressiivista parannusta estääkseni vanhojen selaimien täysin umpeutumisen. Lisäksi halusin ehdottomasti tulevaisuudensuojaa.

Sen otin mukaani etsiessäni oikeaa työkalua tähän työhön.

Valinta CSS:n tai JavaScriptin välillä animaatiokirjastot

Ensimmäinen asia, jonka mietin valittaessani animaatiokirjastoa, oli valitako CSS- vai JavaScript-pohjainen kirjasto. On paljon upeita CSS-kirjastoja, monet heistä suoriutuivat erinomaisesti, mikä oli minulle tärkeä prioriteetti. Halusin tehdä raskaita animaatioita, kuten kykyä järjestellä animaatioita ja saada takaisinsoittoja animaation valmistuttua. Tämä kaikki on täysin mahdollista puhtaalla CSS:llä – silti se on paljon vähemmän sujuvaa kuin mitä useimmat JavaScript-kirjastot tarjoavat.

Katsotaanpa, miltä yksinkertainen sekvensoitu animaatio näyttää CSS:ssä ja verrataan sitä jQueryyn, jossa on runsaasti sisäänrakennettuja animaatioapuohjelmia:

Animaatiot näyttävät samalta, mutta ne luodaan eri tavalla. CSS-animaatiota varten meidän on ensin määritettävä avainkehysanimaatio CSS:ssämme ja liitettävä se luokkaan:

.card.move {
  animation : move 2s;
}

@keyframes move {
  0% { left: 0 }
  50% { left: 100px }
  100% { left: 0 }
}

Suoritamme sitten animaation JavaScriptillä ja kuuntelemme elementin CSS-soittoa:

var cardElement = document.getElementsByClassName("card")[0];
var statusElement = document.getElementsByClassName("status")[0];

cardElement.classList.add("move");
statusElement.innerHTML = "Animating"

var animationEndCallback = function() {
  cardElement.classList.remove("move");
  statusElement.innerHTML = "Inactive"
}

cardElement.addEventListener("webkitAnimationEnd", animationEndCallback);
cardElement.addEventListener("oAnimationEnd", animationEndCallback); 
cardElement.addEventListener("antionend", animationEndCallback);

Asioiden tapahtuminen eri paikoissa saattaa olla hyvä näin yksinkertaisessa esimerkissä, mutta siitä voi tulla hyvin hämmentävää, kun asiat muuttuvat hieman monimutkaisemmiksi. 

Vertaa tätä siihen, miten animaatio tehdään jQuerylla:

$(".status").text("Animating")
$( ".card" ).animate({
  left: "100px"
}, 1000);
$( ".card" ).animate({
  left: 0
}, 1000, function() {
  $(".status").text("Inactive")
});

Täällä kaikki tapahtuu samassa paikassa, mikä yksinkertaistaa asioita, jos animaatiot monimutkaistuvat tulevaisuudessa.

Vaikuttaa selvältä, että JavaScript-kirjasto oli oikea tapa edetä, mutta mikä oli oikea valinta Solitaire-pelilleni? Tarkoitan, jQuery on hieno ja käytössä vielä nykyäänkin, mutta se ei ole asia, johon en halua ripustaa hattuani. JavaScript-animaatiokirjastoja on paljon, joten halusin harkita jotain, joka on rakennettu erityisesti käsittelemään sellaisia ​​raskaita animaatioita, joita ajattelin.

JavaScript-animaatiokirjaston valitseminen

Minulle kävi nopeasti selväksi, että JavaScript-animaatiokirjastoista ja -kirjastoista ei ole puutetta uusia, jännittäviä teknologioita. Niillä kaikilla on etuja ja haittoja, joten käydään läpi joitakin niistä, joita harkitsin ja miksi.

- Web Animations API on yksi tällainen tapaus, joka saattaa korvata monet JavaScript-animaatiokirjastot tulevaisuudessa. Sen avulla voit luoda monimutkaisia ​​porrastettuja animaatioita lataamatta ulkoisia kirjastoja ja samalla suorituskyvyllä kuin CSS-animaatiot. Ainoa haittapuoli on se kaikki selaimet eivät vielä tue sitä. 

- <canvas> elementti tarjoaa toisen jännittävän mahdollisuuden. Siinä voimme animoida asioita JavaScriptillä, kuten tekisimme DOM:lla, mutta animaatio renderöidään rasterina, mikä tarkoittaa, että voimme tehdä joitain korkean suorituskyvyn animaatioita. Ainoa haittapuoli on, että canvas-elementti renderöidään olennaisesti kuvana DOM:ssa, joten jos etsimme pikselin täydellisyyttä, meillä saattaa olla onnea. Suunnittelun kanssa täysin sopusoinnussa olevana tämä oli minulle murros.

Tarvitsin jotain testattua, joten tiesin, että minun on luultavasti käytettävä jotakin monista JavaScript-kirjastoista. Aloin katsoa kirjastoja ja rajasin valintani Anime.js ja GSAP. He molemmat näyttivät käsittelevän monimutkaisia ​​animaatioita hyvin ja heillä oli erinomaiset muistiinpanot suorituskyvystä. Anime on hyvin hoidettu kirjasto, jossa on yli 42.000 XNUMX tähteä GitHubissa, kun taas GSAP on erittäin suosittu, taisteluissa testattu kirjasto, jossa on kukoistava yhteisö.

Aktiivinen yhteisö oli minulle kriittistä, koska tarvitsin paikan, josta pyytää apua, enkä halunnut käyttää kirjastoa, joka saattaa myöhemmin hylätä. Pidin tätä osana mukavuusvaatimuksiani.

Animaatioiden ja takaisinsoittojen järjestys

Kun valintani oli rajattu, seuraava askel oli toteuttaa monimutkainen animaatio käyttämällä kahta kirjastoani. Toistuva animaatio pasianssipelissä on kortti, joka liikkuu jonnekin ja sitten kääntyy ympäri, joten katsotaan miltä se näyttää:

Molemmat animaatiot näyttävät upeilta! Ne ovat sujuvat, ja molempien toteuttaminen oli melko yksinkertaista. Molemmissa kirjastoissa oli a aikajana-toiminto mikä teki sekvenssien luomisesta helppoa. Tältä toteutus näyttää AnimeJS:ssä:

var timeline = anime.timeline({
  begin: function() {
    $(".status").text("Animating")
  },
  complete: function() {
    $(".status").text("Inactive")
  }
});

timeline.add({
  targets: '.card',
  left: [0, 300],
  easing: 'easeInOutSine',
  duration: 500
}).add({
  targets: '.card .back',
  rotateY: [0, 90],
  easing: 'easeInSine',
  duration: 200
}).add({
  targets: '.card .front',
  rotateY: [-90, 0],
  easing: 'easeOutSine',
  duration: 200
})

Animea timeline() toiminto on sisäänrakennettu takaisinkutsuilla animaation alussa ja lopussa, ja sarjan luominen on yhtä helppoa kuin peräkkäisten animaatioiden liittäminen. Ensin siirrän korttia, sitten käännän takakuvaani 90 astetta, jotta se katoaa näkyvistä, ja sitten käännän etukuvaani 90 astetta, jotta se tulee näkyviin.

Sama toteutus GSAP:illa timeline() toiminto näyttää hyvin samanlaiselta:

var timeline = gsap.timeline({
  onStart: function() {
    $(".status").text("Animating")
  },
  onComplete: function() {
    $(".status").text("Inactive")
  }
});

timeline.fromTo(".card", {
  left: 0
}, {
  duration: 0.5,
  left: 300
}).fromTo(".card .back", {
  rotationY: 0
}, {
  rotationY: 90,
  ease: "power1.easeIn",
  duration: 0.2
}).fromTo(".card .front", {
  rotationY: -90
}, {
  rotationY: 0,
  ease: "power1.easeOut",
  duration: 0.2
})

Päätösaika

Suurin ero Animen ja GSAP:n välillä näyttää olevan syntaksi, jossa GSAP saattaa olla hieman monimutkaisempi. Olin jumissa kahdessa loistavassa kirjastossa, joilla oli hyvin samanlaiset toiminnot, jotka pystyivät käsittelemään monimutkaista animaatiota ja joilla oli kukoistava yhteisö. Näytti siltä, ​​että minulla oli tasapeli!

prioriteetti	Anime	GSAP
Sileät animaatiot	✅	✅
Suorituskyky	✅	✅
Mukavuus	✅	✅
Selaimen tuki	✅	✅

Joten mikä sai minut valitsemaan yhden kirjaston toisen sijaan?

Olin erittäin huolissani siitä, kuinka kirjasto toimisi paineen alla. Viiveiden animaatioiden käyttäminen Solitairen kaltaisessa pelissä voi vaikuttaa suuresti siihen, kuinka hauskaa pelin pelaaminen on. Tiesin, etten pystyisi näkemään täysin kirjaston toimintaa ennen pelin luomista. Onneksi GSAP oli tehnyt a stressitesti joka vertasi eri animaatiokirjastoja toisiinsa, mukaan lukien Anime.

Tätä tarkasteltaessa GSAP näytti varmasti ylivoimaiselta kirjastolta monimutkaisten animaatioiden käsittelyyn. GSAP antoi minulle yli 26 kuvaa sekunnissa raskaassa animaatiossa, jonka Anime pystyi ylittämään vain 19:llä. Luettuani GSAP:ista enemmän ja tutkittuani heidän foorumiaan kävi selväksi, että suorituskyky oli kavereille tärkein prioriteetti. GSAP:n takana.

Ja vaikka sekä GSAP että Anime ovat olleet olemassa jonkin aikaa, Animen repo on ollut jonkin verran lepotilassa pari vuotta, kun taas GSAP oli tehnyt sitoumuksia viimeisten parin kuukauden aikana.

Päädyin käyttämään GSAP:ia enkä ole katunut päätöstäni!

Entä sinä? Liittyykö tämä mitenkään siihen, miten arvioit ja vertaat etupään työkaluja? Onko sinulla muita prioriteetteja (esim. saavutettavuus jne.) tällaisessa projektissa? Vai onko sinulla projekti, jossa sinun piti rajata valintojasi useista eri vaihtoehdoista? Ole hyvä ja jaa kommentteihin, koska haluaisin tietää! 

Ja jos haluat nähdä, miltä se näyttää animoitaessa koko korttipakkaa, voit siirtyä sivustolleni ja pelata pasianssia. Pidä hauskaa!