Considerații importante atunci când se creează aplicații web pentru o singură pagină

Aplicațiile web pe o singură pagină - sau SPA-urile, așa cum se face referire la acestea - devin rapid standardul de facto pentru dezvoltarea aplicațiilor web. Faptul că o mare parte din aplicație rulează într-o singură pagină web o face foarte interesantă și atrăgătoare, iar creșterea accelerată a capacităților browserului ne împinge mai aproape de zi, când toate aplicațiile rulează în întregime în browser.

Din punct de vedere tehnic, majoritatea paginilor web sunt deja APS; este complexitatea unei pagini care diferențiază a pagină web de la aplicație web. După părerea mea, o pagină devine o aplicație atunci când încorporați fluxuri de lucru, operațiuni CRUD și gestionarea statului în jurul anumitor sarcini. Lucrați cu o SPA atunci când fiecare dintre aceste sarcini are loc pe aceeași pagină (folosind AJAX pentru comunicarea client / server, desigur).

Să începem cu această înțelegere comună și să ne aruncăm cu vederea în unele dintre cele mai importante lucruri care ar trebui luate în considerare atunci când construim SPA-uri.


Există numeroase puncte de luat în considerare înainte de a construi o nouă aplicație; pentru a face lucrurile să se înrăutățească, peisajul expansiv de dezvoltare web poate fi intimidant de la bun început. Am fost în acele pantofi tulburi, dar, din fericire, ultimii ani au adus un consens cu privire la instrumentele și tehnicile care fac experiența dezvoltării aplicațiilor cât mai plăcută și mai productivă posibil.

Cele mai multe aplicații sunt compuse atât din partea clientului, cât și din partea serverului; deși acest articol se concentrează în cea mai mare parte pe partea client-parte a unei aplicații, voi oferi câteva indicii de server-side spre sfârșitul acestui articol.

Există o combinație colorată de tehnologii pe partea clientului, precum și câteva biblioteci și practici care permit o experiență productivă de dezvoltare a aplicațiilor. Acest lucru poate fi rezumat folosind următorul cuvânt nor.

Voi extinde în fiecare dintre punctele de mai sus în secțiunile următoare.


Alegerea unui cadru de aplicare

Există o abundență de cadre pentru a alege de la. Iată doar câteva dintre cele mai populare:

  • șira spinării
  • CanJS
  • SpineJS
  • BatmanJS
  • EmberJS
  • AngularJS
  • Meteor

Alegerea unui cadru este cu ușurință una dintre cele mai importante alegeri pe care le veți face pentru aplicația dvs. Desigur, veți dori să alegeți cel mai bun cadru pentru echipa și aplicația dvs. Fiecare dintre cadrele de mai sus încorporează modelul de design MVC (într-o formă sau alta). Ca atare, este destul de obișnuit să se facă referire la acestea ca cadre MVC. Dacă trebuia să ordonăm aceste cadre pe o scară de complexitate, curba de învățare și setul de funcții, de la stanga la dreapta, ar putea să arate:

Deși diferiți în ceea ce privește implementarea și nivelul de sofisticare, toate cadrele menționate mai sus oferă câteva abstracții comune, cum ar fi:

Privind doar în ultimii cinci ani, a existat o creștere explozivă în biblioteci, instrumente și practici.

  • Model: un wrapper în jurul unei structuri de date JSON cu suport pentru proprietarii / proprietarii de proprietăți și notificarea schimbării proprietății.
  • Colectie: o colecție de modele. Oferă notificări atunci când un model este adăugat, eliminat sau modificat în colecție.
  • Evenimente: un model standard pentru abonarea la și publicarea notificărilor.
  • Vedere: Un obiect de suport pentru un fragment DOM cu suport pentru ascultarea evenimentelor DOM relative la fragmentul DOM. Vizualizarea are acces la instanța corespunzătoare a modelului. În unele cadre, există și a Controlor care orchestrează schimbările între Vizualizare și Model.
  • Routing: Navigarea în cadrul unei aplicații prin adrese URL. Se referă la API-ul istoricului browserului.
  • sincronizaţi: Modificări persistente ale modelului prin intermediul apelurilor Ajax.

Cadrele mai avansate, cum ar fi CanJS, BatmanJS, EmberJS și AngularJS, extind aceste caracteristici de bază, oferind suport pentru șabloane automate de legare a datelor și de client. Șabloanele sunt legate de date și păstrează sincronizarea cu orice modificări ale modelului. Dacă vă decideți să alegeți un cadru avansat, cu siguranță veți obține o mulțime de caracteristici extra-box, dar vă așteaptă, de asemenea, să vă construiți aplicația într-un anumit mod.

Dintre toate cadrele listate anterior, Meteor este singurul cadru full-stack. Acesta oferă instrumente nu doar pentru dezvoltarea de la nivelul clientului, ci vă oferă, de asemenea, o piesă de server, prin intermediul NodeJS, și o sincronizare de tip end-to-end, prin MongoDB. Acest lucru înseamnă că, atunci când salvați un model pe client, acesta persistă în mod automat în MongoDB. Aceasta este o opțiune fantastică, dacă rulați un backend de nod și utilizați MongoDB pentru persistență.

Pe baza complexității aplicației dvs., trebuie să alegeți cadrul care vă face cel mai productiv. Cu siguranță va exista o curbă de învățare, dar aceasta este o taxă unică pe care o plătiți pentru dezvoltarea expresiei. Asigurați-vă că ați scos ceva timp pentru a evalua aceste cadre, pe baza unui caz reprezentativ de utilizare.

Notă: Dacă doriți să aflați mai multe despre aceste cadre de la creatorii lor, ascultați aceste videoclipuri de la ThroneJS.


Șabloane de pe partea clientului

Cele mai populare sisteme de template-uri bazate pe JavaScript sunt șabloanele Underscore și Handlebars.

Unele dintre cadrele avansate din secțiunea anterioară oferă sisteme de template-uri încorporate.

De exemplu, EmberJS are suport integrat pentru Handlebars. Cu toate acestea, trebuie să luați în considerare un motor templating dacă decideți să utilizați un cadru slab, cum ar fi Backbone. Underscore este un excelent punct de plecare, dacă aveți cerințe templice limitate. În caz contrar, Handlebars funcționează excelent pentru proiecte mai avansate. De asemenea, oferă multe caracteristici încorporate pentru șabloane mai expresive.

Dacă descoperiți că aveți nevoie de un număr mare de șabloane de pe partea clientului, puteți salva un timp de calcul prin precompilarea șabloanelor de pe server. Precompilarea vă oferă funcții simple JavaScript pe care le invocați pentru a îmbunătăți timpul de încărcare al paginii. Handlebars sprijină pre-compilare, făcând să merite timpul și efortul de a explora pe deplin.

Utilizatorii ExpressJS pot utiliza chiar același motor templating pe client ca și pe server, oferindu-vă avantajul de a vă împărtăși șabloanele între client și server.


Dezvoltarea modulară

Utilizarea unui preprocesor necesită un pas suplimentar în procesul dvs. de construire.

Codul JavaScript este adăugat în mod tradițional în pagină, prin intermediul >

Cod