Kuidas luua React abil A + progressiivne veebirakendus

Progressiivsete veebirakenduste (PWA) üle on praegu palju elevust, kuna brauseritarnijad (sh Safari) lisavad teenindustöötajaid ja muid progressiivsete täiustuste API-sid. Mis aga muudab veebirakenduse progressiivseks?

Google määratleb PWA kogemustena, milles on ühendatud veebi ja rakenduste parimad küljed. Need peaksid olema:

  • Kiire - reageerige kiiresti kasutaja suhtlusele
  • Integreeritud - kasutaja ei pea brauseri kaudu minema
  • Usaldusväärne - laadige kohe, isegi võrguühenduseta oleku korral
  • Kaasamine - hoidke kasutaja tagasi tulemist suurepärase UX-iga

See kõik on suurepärane, kuid ebamäärane. Google pakub ka käepärast progressiivse veebirakenduse kontrollnimekirja, kuid isegi siis puudub lõplik vastus selle kohta, mis on PWA ja mis teeb sellest suurepärase.

Baasjoone PWA

Kõige elementaarsemal tasemel määratletakse PWA tehniliste omaduste järgi, mis võimaldavad brauseril tuvastada, et sait vastab teatud kriteeriumidele ja on väärt avaekraanile lisamist. Kui kriteeriumid on täidetud, kuvatakse viip „Lisa avaekraanile“.

Näide Lisa avaekraanile ribareklaam

Kolm kuldreeglit, mille abil riba „App Install” kuvatakse, on järgmised:

  1. Rakendus peab pärinema turvalisest päritolust
    Seega tuleb seda edastada SSL / HTTPS-i kaudu.
  2. Rakendus peab olema võrguühenduseta laaditud
    See peaks toimima võrguühenduseta (isegi kui ainult kohandatud võrguühenduseta leht või põhiline vahemällu salvestamine). See tähendab installeeritavat teenindustöötajat.
  3. Rakendus peab viitama veebirakenduse manifestile
    Teie rakendust kirjeldav lihtne JSON-fail.

Selle funktsiooni lisamine oma olemasolevale veebirakendusele on suhteliselt triviaalne ülesanne ja tehniliselt on teil PWA. Kahjuks ei pruugi see tingimata vastata kiire, integreeritud, usaldusväärse ja kaasahaarava määratlusele. Kui kasutate oma rakendust Google'i kontrollnimekirja või Google'i majaka auditi tööriista kaudu, leiate tõenäoliselt tohutu hulga probleeme.

Kui teil on serveriga renteeritud veebisait, siis on sel hetkel selge, et teil on probleeme nende probleemide loendi parandamisega, millest majakas teile teatab. Kui kasutaja veebirakenduses serverit renderdab, siis nuppu, kui kasutaja koputab nuppu või linki, tuleb oodata praegusest ekraanist, enne kui järsku hüppab täiesti uuele sisukorrale. See on PWA jaoks vastuvõetamatu, kuna see reedab ideed, et rakendus ise töötab seadmes lokaalselt.

Kui soovite tõesti muuta oma veebirakenduse PWA-ks, peate nihutama energiabilansi serverist renderdatud veebirakendusest kliendi muudetud veebirakendusele. Lühidalt on vaja uut rakenduse arhitektuuri.

Rakenduse kest

Rakenduse kesta muster kordab loodusliku rakenduse arhitektuuri, pakkudes tõhusalt koodipaketti, mis on sarnane sellele, mida te oma rakenduse poest App Store'ist alla laadiksite.

Peamine erinevus on see, et selle paketi peab teenindustöötaja alla laadima, kui kasutaja esimest korda rakendust külastab, mitte kaudselt rakenduste poest. See tähendab, et teie PWA peab olema kiire. Tegelikult väga kiiresti, kuna te ei soovi, et kasutajad vaataksid tühja ekraani 5–10 sekundit, samal ajal kui teie PWA laadib köögivalamu alla just esimese ekraani kuvamiseks.

Rakenduse kest peaks sisaldama skeleti UI-d ja rakenduse toimimiseks vajalikke põhikomponente. Üldiselt vastutab marsruutimise eest, kuid see ei tohiks sisaldada andmeid.

Rakenduse kooremuster

Olekute laadimine

Kui teil on App Shell, kus andmed on esitlusest eraldi ja klient vastutab kasutajaliidese renderdamise eest, muutub laadimisolekute mõiste loomulikuks kujundusmustriks.

Kui URL-i taotletakse, saab klient esmalt laadida laadimisoleku, mis laaditakse kohe, kuna see on osa rakenduse kestast. Samal ajal esitab klient andmete hankimise päringu, kui klient saab pärast selle saamist valmis ekraani ja asendab laadimisoleku.

Olekute laadimine

Lõpptulemus on kasutajale palju parem kogemus kui lingi vajutamine, lehel viibimine 3–4 sekundit, valge välklambi nägemine ja lehe renderdamine aeglaselt, nagu see oleks serveris veebirakenduses.

Koodi poolitamine

App Shelli muster käib käsikäes koodide jagamisega. Tavalises rakenduses React on teie kood ühendatud üheks JavaScripti failiks. PWA-s peame esimese ekraani võimalikult kiiresti laadima, nii et vajame väiksemat kogumit, samuti peame vahemaad iga marsruudi eraldi hoidma. Lühidalt öeldes peame oma JavaScripti tükeldama. Webpack võib selles aidata või võite kasutada midagi sellist, nagu näiteks Preact, mis pakub automaatset koodilõikust.

Rakenduse koorekoodiga, eraldatud ja sisust eraldatud, saate hakata teenustöötajaid täielikult ära kasutama. Varem ebapraktilisi funktsioone saab hõlpsalt pakkuda, näiteks:

  • Võrguühenduseta tugi
  • Vahemälueelne rakenduse kasutajaliides
  • Dünaamiliselt vahemälu võrgu andmed / varad

Töökastiga teenindajad

Nende funktsioonide rakendamiseks peate süvenema teenindusse. Teenindajaid on täiesti võimalik käsitsi kirjutada, kuid Google on Workboxi abil teie jaoks palju ära tõstnud.

Õnnelik vahend on kasutada pistikprogrammi InjectManifest koos WebPackiga. See võimaldab teil ühendada oma teenindaja koodi Workboxiga. Peaksite vähemalt rakendama:

  • Rakenduse kesta vahemällu salvestamine
  • Nõutavate andmete ja varade vahemälu vahemällu salvestamine

Teenindajaid saab teha veel palju, sealhulgas:

  • Tausta sünkroonimine
  • Tõuketeated
  • Võrguühenduseta Analytics

Teenuse Workbox töötajad on selle teema ise. Kui soovite rohkem teada saada, olen kirjutanud Preactiga eraldi artikli töölaua kohta.

PRPL muster

Teie rakendust tuleks nüüd kiiresti laadida. Sellel on rakenduse kest, koodide jagamine ja kõik see on teenindustöötaja vahemällu salvestatud. Tegelikult oleme juurutanud Google'i poolt PWA-le soovitatud PRPL-i mustri. PRPL keskendub rakenduste edastamise ja käivitamise toimivusele. See tähistab:

  • Lükake algse marsruudi jaoks kriitilised ressursid üle
  • Renderdage algne marsruut
  • Vahemälu järelejäänud marsruudid
  • Laisa laadige ja looge järelejäänud marsruudid nõudmise järgi

Ehkki see töötab HTTP / 1-s, on tõenäoline, et soovite uurida HTTP / 2-võimelist veebi. HTTP / 2 võimaldab mitmekordistatud allalaadimisi ühe ühenduse kaudu, nii et mitu väikest faili saab tõhusamalt alla laadida.

Serveripoolne renderdamine vs eel Renderdamine ja CDN

Võite serveripoolel renderdada esialgse marsruudi koos andmetega ja lasta kliendil seejärel renderdamise üle võtta. See võib anda algse kiiruse suurendamise, kuid selle konfigureerimine võib olla keeruline. Üldiselt ei ole ma fänn keerukuse tõttu, mida see koodipõhjale lisab.

Minu arvates on parem lahendus staatilise veebisaidi eelnevalt renderdamine ja selle hostimine HTTP / 2-võimelisel sisuedastusvõrgus (CDN), pakkudes uskumatut kiirust ja koodibaasi lihtsust. Boonusena vähendasite lihtsalt oma hostimise keerukust, kuna vajate ainult staatilist veebimajutust!

Eelrenderdamiseks on palju võimalusi, sealhulgas:

  • Täpsusta
  • Reageeri staatiliselt
  • Gatsby

Parima kiiruse saavutamiseks võite seejärel oma staatilise veebisaidi CDN-teenuse pakkuja, näiteks Netlify abil juurutada.

Tõmba otsad kokku

Kui käitate rakendust majaka kaudu, kasutades sellist arhitektuuri, peaksite saama palju parema punktisumma. Samuti märkate, kui kiire on teie rakendus ja see pakub suurepärast kasutajakogemust.

Progressiivsed veebirakendused on fantastiline pakkumine, mida on lihtsam luua kui juurutada kui natiivseid rakendusi, kuid suudavad pakkuda siiski palju kogemusi, mida kasutajad looduslike rakenduste puhul armastavad ja ootavad.

Safari PWA-le pakutava toe osas on endiselt küsimärke, kuid nad töötavad paljude üksuste kallal ja teenindustöötajad on saadaval iOS 11.3-s, nii et see tundub paljutõotav.

Kui soovite läbida veel ühe miili, on rakendamisel veel mitmeid täiendavaid API-sid (peame jällegi vaatama, mida Safari juurutab), mis pakuvad teie kasutajale veelgi paremaid kogemusi, sealhulgas:

  • Push Notifications API
  • Veebimaksete API
  • Volituste API

Nii palju kui ma armastan React Native'i ja see on paljudel juhtudel ikkagi parimaks võimaluseks kasutajakogemuse jaoks, investeerin isiklikult PWA-sse palju aega ja energiat, kuna usun, et neil on väga helge tulevik!

Minu nimi on Dave Hudson, olen tooteehituse UX-i pedant, kes juhib arendusmeeskondi ja kirjutab koodi.
Ma pean nõu Applification Ltd all ja olen kõigis asjades saadaval, reageerima, paindlik ja tootearendus!