Ghidul dezvoltatorului pentru îmbunătățirea structurii proiectului în aplicațiile Meteor

În ultimii câțiva ani, a existat o creștere dramatică a numărului de cadre JavaScript disponibile. De la AngularJS încercat și adevărat la numărul de cadre care apar în fiecare lună, există o diversitate impresionantă din care să alegeți. Unul care mi-a atras atenția în urmă cu câțiva ani este un cadru numit Meteor. Spre deosebire de majoritatea cadrelor, Meteor își propune să fie o platformă completă pentru dezvoltarea aplicației JavaScript. Pentru cei care sunt noi la Meteor, vă încurajez să îl verificați pe site-ul lor. Acest articol nu va fi o introducere în Meteor. În schimb, vom explora câteva modalități simple de a introduce structura în proiectele Meteor.

Unul dintre marile beneficii ale Meteor este că este foarte ușor să prototipați rapid aplicații JavaScript complexe cu acesta. Deoarece Meteor este un hibrid de șabloane și randare front-end cuplat cu un server bazat pe Node care interacționează cu MongoDB (o soluție unificată), cea mai mare parte a configurației inițiale necesare pentru crearea unei aplicații web full-stack este deja făcută pentru tine. Cu toate acestea, ușurința de dezvoltare pe care aceasta o oferă poate fi o capcană. Este ușor să cazi în practici proaste și să ajungi cu un amestec de cod nestructurat atunci când construiești o aplicație Meteor. Am câteva sugestii despre cum poate fi evitat acest lucru.

Scaffolding: ierarhie de directoare gestionabilă în Meteor

În primul rând, este important să mențineți structura de foldere recomandată atunci când vă construiți aplicația. Meteor vă permite să plasați fișiere oriunde în folderul proiectului în mod implicit - puteți chiar să aveți tot codul într-un singur fișier, dacă doriți. Deși acest lucru ar putea funcționa pentru un proiect hackathon, complexitatea pe care o implică aplicațiile obișnuite la nivel de producție, scalabile, este greu de gestionat fără o structură solidă.

Pentru a rezolva această problemă, vă recomand să verificați pachetul de călcat npm al lui Chris Mather. Pachetul are o varietate de opțiuni de configurare, așa că va fi greu de descris aici, dar, în general, construiește o structură de proiect care va arăta cam așa:

 my-app/ |- .iron/ |- config.json |- bin/ |- build/ |- config/ |- development/ |- env.sh |- settings.json |- app/ |- client/ |- collections/ |- lib/ |- stylesheets/ |- templates/ |- head.html |- lib/ |- collections/ |- controllers/ |- methods.js |- routes.js |- packages/ |- private/ |- public/ |- server/ |- collections/ |- lib |- methods.js |- publish.js |- bootstrap.js

Cu toate acestea, pentru unele proiecte, o structură de foldere și fișiere ca aceasta poate fi exagerată. Nu orice proiect va trebui să aibă acest nivel de organizare fin, cu separații pentru colecții, metode și cod de publicare pe server. Pentru cei care nu au un proiect prea mare sau pur și simplu nu doresc să instaleze și să învețe un alt pachet npm, recomand această structură de bază de foldere:

Elementele cheie sunt un folder public care conține fișiere precum faviconul dvs. și alte elemente statice, precum și folderele client, comune și server. Dosarele client și server ar trebui (desigur) să conțină cod care este executat pe client și, respectiv, pe server. Folderul comun conține cod care trebuie să fie accesibil atât pentru client, cât și pentru server. Un exemplu în acest sens este codul Schema, despre care vom discuta mai târziu.

Există două moduri de a realiza cel mai scăzut nivel de organizare: unul este după tipul de fișier, iar al doilea este după funcție. Organizarea după tip de fișier înseamnă că în folderul client/șabloane, de exemplu, veți avea trei foldere - unul pentru fișierele JavaScript, unul pentru CSS și unul pentru HTML. Dosarul HTML va conține toate fișierele HTML șablon, de exemplu Login.html, Main.html și așa mai departe. Dosarele JavaScript și CSS vor conține fișiere șablon de tipul lor. Organizarea după funcție, pe de altă parte, înseamnă organizarea după conceptul pe care îl întruchipează fișierele. De exemplu, în client/șabloane, aș avea un folder „Login”, cu toate fișierele JavaScript, CSS și HTML asociate cu procesul de conectare al aplicației. Prefer organizarea după funcție, deoarece vă permite să fiți mai clar unde puteți găsi anumite fișiere sau bucăți de cod. Cu toate acestea, nu este pur și simplu alb-negru, iar majoritatea indivizilor și echipelor folosesc un amestec de aceste metode pentru a-și structura fișierele și folderele.

Schemă: aplicația dvs. are nevoie de ea chiar dacă baza de date nu are

Al doilea tip de structură pe care aș dori să-l discut este asociat cu baza de date. Acest articol presupune că utilizați MongoDB. Dacă nu ești, conceptele se vor aplica probabil în continuare, dar specificul nu se va aplica. Cei care folosesc MongoDB știu că permite nestructurarea modului în care stocăm datele noastre. Deoarece MongoDB este o bază de date NoSQL de depozit de documente, nu există nicio schemă fixă ​​pentru orice „tip” de date. Această libertate înseamnă că nu trebuie să vă faceți griji pentru a vă asigura că toate obiectele sunt standardizate într-o formă rigidă, de fapt, toate datele aplicației dvs. ar putea fi aruncate într-o singură colecție dacă doriți. Cu toate acestea, atunci când vine vorba de realizarea de aplicații de calitate de producție, acest lucru nu este chiar la fel de dorit. Pentru a gestiona acest lucru și pentru a adăuga funcții utile, cum ar fi validarea cererilor de scriere, putem apela la două pachete minunate Meteor: SimpleSchema și Collection2 ale Aldeed.

Pachetul SimpleSchema, așa cum sugerează și numele, vă permite să validați în mod reactiv obiectele din aplicația dvs. Consultați documentele de pe GitHub. Pachetul Collection2 pornește de pe SimpleSchema și vă permite să aduceți scheme adecvate colecțiilor Meteor. Ceea ce permite acest lucru este validarea automată a cererilor de scriere pe partea de client și server la orice colecție cu o schemă atașată. Ambele pachete sunt foarte profunde și personalizabile, așa că este greu să le înțelegem complet în câteva paragrafe. Mai degrabă, vă recomand să vă uitați la readmes-urile detaliate pe care Aldeed le-a compilat pentru detalii. Voi vorbi pur și simplu despre cum am obținut valoare din aceste pachete. Unul dintre cele mai bune lucruri pe care le-au activat a fost validarea introducerii formularului de către utilizator. Acest lucru este util pentru validarea documentelor Meteor User (din pachetul Conturi). În mod implicit, utilizatorii Meteor au o schemă implicită surprinzător de complexă. Iată o imagine a unei părți din codul pe care Aldeed a fost atât de amabil să-l pună la dispoziție:

 Schema.UserProfile = new SimpleSchema({ firstName: { type: String, optional: true }, lastName: { type: String, optional: true }, birthday: { type: Date, optional: true }, gender: { type: String, allowedValues: ['Male', 'Female'], optional: true }, organization : { type: String, optional: true }, website: { type: String, regEx: SimpleSchema.RegEx.Url, optional: true }, bio: { type: String, optional: true }, country: { type: Schema.UserCountry, optional: true } });

Aceasta este pur și simplu schema pentru obiectul de profil al utilizatorului. Încercarea de a valida tot obiectul User ar fi o mizerie fără un pachet special creat, cum ar fi SimpleSchema . În timp ce toate aceste câmpuri apar opționale în imagine, dacă doriți o schemă de utilizator validată corespunzător, probabil că nu ar fi, iar lucruri precum „Schema.UserCountry” redirecționează de fapt către alte scheme pentru validare. Atașând această schemă la obiectul Utilizator și integrând aceasta în mod reactiv în formularele noastre, poate cu un pachet precum AutoForm de la Aldeed, putem obține un grad fin de control asupra a ceea ce face și ce nu face în bazele noastre de date, economisind timp și efort cu un model conceptual al modului în care datele sunt gestionate în aplicația noastră, care poate fi indicat și discutat în termeni concreti.

Roluri: Pentru 401 și 403

Ultima sugestie pe care o am pentru structurarea și îmbunătățirea unui proiect Meteor este pachetul Roles al lui Alanning. Acesta este un sistem de autorizare pentru Meteor și vă permite să verificați nivelurile de acces ale utilizatorilor pentru orice parte a aplicației dvs. web. Permisiunile sunt atașate profilului de utilizator sub formă de șiruri care sunt ulterior validate sau invalidate atunci când utilizatorul încearcă să acceseze orice metode sau date Meteor publicate clientului. De exemplu:

 if (Roles.userIsInRole(Meteor.userId(), "admin")) { tabsArr.push({ name: "Users", slug: "users" }); }

Deși nucleul sistemului este relativ simplu, acesta permite permisiuni complexe și detaliate pentru orice parte a aplicației dvs. Deoarece toate rolurile sunt stocate ca șiruri de caractere, puteți configura un sistem cât de profund doriți - „admin”, „admin.division1.manage”, „admin.division1.manage.group2” și așa mai departe.

Problema cu libertatea pe care o oferă acest pachet este că poate fi greu să urmăriți un sistem de roluri foarte granular. Pachetul oferă funcții precum „getAllRoles” care, după cum sugerează și numele, preia toate rolurile pe care le-ați creat, dar depinde de dvs. să urmăriți care sunt semnificațiile lor și când ar trebui să fie un anumit rol. fi folosit. Și pentru cei care sunt curioși care este diferența dintre „roluri” și „permisiuni”, în scopul acestui pachet, acestea nu sunt în esență diferite.

Încheierea

Din păcate, din cauza amplorii articolului (fiecare dintre pachetele menționate aici merită propriul său tutorial) nu a fost posibil să intru în detaliu despre niciun pachet anume, dar sper că am aruncat puțină lumină asupra modului în care puteți lucra la un „standardizat”. ” Aplicația Meteor în care poți fi sigur că va funcționa bine în producție și la scară. Dacă sunteți în căutarea mai multor informații, consultați linkurile pe care le-am postat și aruncați o privire la încă un lucru care nu a ajuns la acest articol, dar este util să aveți într-o aplicație Meteor: pachetul Restivus, care vă permite pentru a expune cu ușurință un API REST pentru aplicația dvs.

Ca declinare a răspunderii, nu sunt autorul niciunuia dintre aceste pachete și îmi cer scuze dacă am denaturat vreuna dintre caracteristicile sau scopurile oricărui pachet. Vă mulțumesc că ați citit și sper că acest articol v-a fost de folos. Nu ezitați să mă contactați pentru orice întrebări pe care le aveți sau lăsați un comentariu mai jos.