Individualios programinės įrangos kūrimas. Trumpa istorija apie prekės ženklo bangas

Sprendimų pasiūlymai

Pradėjome nuo paprasto SVG objekto, kuris buvo animuojamas naudojant įvairias bibliotekas. Kadangi viename puslapyje norėjome turėti 3 objektus, rezultatas nebuvo toks džiuginantis. Visos animacijos buvo tiesiog lėtos - visus vieno SVG objekto kelius reikėjo atnaujinti per labai trumpą laiką, todėl visas puslapis buvo lėtas kaip sraigė. Teko atsisakyti sprendimo su grynuoju SVG, įterptu į dokumentą. Tai paliko mus su dviem kitais sprendimais, iš kurių galite rinktis.

Svetainė vaizdo įrašas elementas buvo antroji galimybė. Pradėjome nuo dviejų problemų:

- permatomas fonas, kurio negalima naudoti su populiariausiais vaizdo įrašų formatais, pvz., .mp4 arba .webm,

- reagavimo sparta, o tai buvo tikra problema, nes vaizdo įrašai nėra keičiamo dydžio.
​
Nusprendėme palikti šį sprendimą atsargai - “jei nerasime nieko kito, pasirinksime šį”.

Paskutinė galimybė buvo naudoti drobė su WebGL atvaizdavimas. Tai buvo toks neįprastas variantas, nes turėjome patys sukurti visą atvaizdavimo mechaniką. Taip buvo todėl, kad morfinės bangos, kurias turėjome, buvo nestandartinės - tai privertė mus sukurti nestandartinį sprendimą Ir tai buvo variantas, kuriuo norėjome vadovautis ir į kurį tikrai sutelkėme dėmesį.

Sprendimo architektūra

Pradėkime nuo nulio. Kokią medžiagą turėjome naudoti šioms bangoms sukurti? Idėja buvo tokia, kad visos bangos - tai 1×1 dydžio SVG failas ir tam tikri keliai, išdėstyti aplink šią sritį. Šio SVG animacija buvo kuriama tam tikromis būsenų formomis prie šio failo. Taigi, visos animacijos buvo pateikiamos kaip failų rinkinys, kuriame buvo formos judėjimo etapai.

Giliau pažvelkite, kas yra būsenos - visi keliai yra tik tam tikras masyvas su konkrečiomis reikšmėmis, išdėstytomis tam tikra tvarka. Keičiant šias reikšmes konkrečiose šio masyvo pozicijose, keičiasi forma konkrečiose jo dalyse. Galime tai supaprastinti pateikdami tokį pavyzdį:


1 būsena: [1, 50, 25, 40, 100]
2 būsena: [0, 75, -20, 5, 120]
3 būsena: [5, 0, -100, 80, 90]


Taigi galime daryti prielaidą, kad norimą atvaizduoti figūrą sudaro masyvas su 5 elementais, kurie tam tikrais laikotarpiais keičiasi tiesiniu palengvinimu. Kai animacija baigia paskutinį etapą, ji vėl pradedama nuo pirmojo, kad susidarytų begalinės animacijos įspūdis.

Bet... palaukite - kas tiksliai yra aukščiau pateiktas masyvas? Kaip minėjau, tai kelias, atsakingas už konkrečios formos atvaizdavimą. Visa magija yra įtraukta į d SVG kelio savybė. Šioje savybėje yra “komandų” rinkinys, skirtas figūrai nupiešti, ir kiekviena komanda turi tam tikrus argumentus. Minėtą masyvą sudaro visos šioms komandoms priskirtos reikšmės (argumentai).

Vienintelis skirtumas tarp šių “būsenos failų” buvo konkrečių komandų reikšmės, nes komandų eiliškumas buvo toks pat. Taigi visa magija buvo susijusi su visų reikšmių gavimu ir jų animavimu.

Vedlys vadinamas fizika

Ankstesnėje pastraipoje minėjau, kad vienintelis stebuklingas objekto animavimo būdas - sukurti perėjimus tarp visų formos etapų. Kyla klausimas - kaip tai padaryti naudojant drobę?
​
Funkcija, kad visi, kurie dirbo su drobė turėtų žinoti, yra requestAnimationFrame. Jei tai matote pirmą kartą, nuoširdžiai tikiu, kad turėtumėte pradėti nuo to, kad perskaitytumėte tai. Taigi, mus domina šios funkcijos argumentas - DOMHighResTimeStamp. Tai atrodo tikrai bauginančiai, tačiau praktiškai tai nėra taip sunku suprasti. Galima sakyti, kad tai yra laiko žymė, rodanti laiką, praėjusį nuo pirmojo atvaizdavimo.

Gerai, bet ką galime su tuo padaryti? Kaip requestAnimationFrame funkcija turėtų būti iškviečiama rekursyviai, galime pasiekti laiko deltą tarp jos iškvietimų. Ir štai čia jau mokslas! ⚛️ (gerai, gal ir ne raketų mokslas... kol kas )
​
Fizika mus moko, kad atstumo delta yra lygi laiko deltai, padaugintai iš greičio. Mūsų atveju greitis yra pastovus, nes norime pasiekti galutinį tašką per tam tikrą laiką. Taigi, pažvelkime, kaip tai galime pavaizduoti su pirmiau pateiktomis būsenomis:

Tarkime, kad norime pereiti iš vienos būsenos į kitą per tūkstantį milisekundžių, todėl greičio reikšmės bus tokios:


delta: [ -1, 25, -45, -35, 20]
greitis: [-1/1000, 25/1000, -45/1000, -35/1000, 20/1000]


Aukščiau pateiktas greitis rodo: kiekvieną milisekundę didinkime reikšmę -1/1000. Ir čia yra taškas, kuriame galime grįžti prie mūsų requestAnimationFrame ir laiko delta. Konkrečios padėties vertė, kurią norime padidinti, yra laiko delta, padauginta iš jos padėties greičio. Dar vienas dalykas, kurį galima pasiekti be problemų, - apriboti reikšmę taip, kad ji neviršytų būsenos, į kurią einama.
​
Pasibaigus perėjimui, kviečiame kitą ir t. t. Ir neatrodo, kad tai būtų taip sunku įgyvendinti, bet viena iš pagrindinių taisyklių programinės įrangos kūrimas yra nešvaistyti laiko dalykams, kurie jau yra įgyvendinti. Taigi - mes pasirinkome mažytė biblioteka kuri leidžia mums lengvai sukurti šiuos perėjimus.
​
Taip sukūrėme vieną animuotą bangą, kuri atrodo kaip gyva būtybė.

Keletas žodžių apie formų klonavimą

Kaip matote, The Codest prekės ženklo bangos nėra viena animacinė figūra. Jas sudaro daugybė vienodos formos, bet skirtingo dydžio ir padėties figūrų. Šiame žingsnyje trumpai apžvelgsime, kaip tokiu būdu dubliuoti.
​
Taigi, drobės kontekstas leidžia mums brėžinio mastelio sritis (galima sakyti, kad jis padaugina visus matmenis, perduodamus į drawable metodus, iš “k”, kur “k” yra mastelio koeficientas, pagal nutylėjimą nustatytas kaip “1”), padaryti drobė išversta, tai tarsi brėžinio srities atraminio taško keitimas. Šiais metodais taip pat galime šokinėti tarp šių būsenų: išsaugoti ir atkurti.
​
Šie metodai leidžia išsaugoti “nulinių modifikacijų” būseną ir tada atvaizduoti tam tikrą bangų skaičių cikle su tinkamai masteliu pakeistu ir išverstu audeklu. Iškart po to galime grįžti į išsaugotą būseną. Tai viskas apie figūrų klonavimą. Daug lengviau nei klonuoti avis, ar ne?

Vyšnia ant viršaus

Minėjau, kad vieną iš galimų sprendimų atmetėme dėl našumo. Galimybė su drobėmis yra gana greita, tačiau niekas nesakė, kad jos negalima optimizuoti dar labiau. Pradėkime nuo to, kad mums nelabai rūpi figūrų perėjimas, kai jos yra už naršyklės peržiūros srities ribų.
​
Yra dar viena naršyklė API kad programuotojai mylėjo - IntersectionObserver. Ji leidžia sekti konkrečius puslapio elementus ir tvarkyti įvykius, kurie inicijuojami, kai šie elementai pasirodo arba išnyksta iš peržiūros srities. Šiuo metu turime gana paprastą situaciją - sukurkime matomumo būseną, keiskime ją dėl IntersectionObserver įvykių tvarkytojų ir tiesiog įjunkime arba išjunkime atvaizdavimo sistemą konkrečioms figūroms. Ir... bumas, našumas labai pagerėjo! Atvaizduojame tik tuos dalykus, kurie matomi viewport'e.

Santrauka

Pasirinkti įgyvendinimo būdą dažnai būna sunku, ypač kai atrodo, kad turimos galimybės turi panašių privalumų ir trūkumų. Raktas į teisingą pasirinkimą - išanalizuoti kiekvieną iš jų ir atmesti tuos, kuriuos laikome mažiau naudingais. Ne viskas aišku - kai kuriems vieniems sprendimams reikia daugiau laiko nei kitiems, tačiau jie gali būti lengviau optimizuojami arba labiau pritaikomi.

Nors nauji JS bibliotekų atsiranda beveik kas minutę, yra dalykų, kurių jos negali išspręsti. Štai kodėl kiekvienas front-end inžinierius (ir ne tik jis) turėtų išmanyti naršyklės API, sekti technines naujienas ir kartais tiesiog pagalvoti: “Kaip atrodytų mano šios bibliotekos įgyvendinimas, jei man tektų tai daryti?”. Turėdami daugiau žinių apie naršykles, galime kurti tikrai įmantrius dalykus, priimti gerus sprendimus dėl naudojamų įrankių ir labiau pasitikėti savo kodas.

Skaityti daugiau:

- "Ruby 3.0". Ruby ir mažiau žinomi privatumo kontrolės metodai

- Užsičiaupk ir pasiimk pinigus #1: paslėptos išlaidos ir tikrasis produktų kūrimo proceso judrumas

- CTO iššūkiai - programinės įrangos produktų masto didinimas ir augimas