Tijekom posljednjih nekoliko godina zabilježen je dramatičan porast broja dostupnih JavaScript okvira. U rasponu od provjerenog AngularJS-a do rezultata okvira koji izlaze svakog mjeseca, postoji impresivna raznolikost koju možete odabrati. Ono što mi je privuklo pažnju prije nekoliko godina je okvir nazvan Meteor. Za razliku od većine okvira, Meteor želi biti cjelovita platforma za razvoj JavaScript aplikacija. Za one koji su novi u Meteoru, savjetujem vam da to provjerite dalje njihovu web stranicu . Ovaj članak neće biti uvod u Meteor. Umjesto toga, istražit ćemo nekoliko jednostavnih načina za uvođenje strukture u Meteor projekte.

Vodič za programere za poboljšanje strukture projekta u okviru Meteor Cvrkut

Jedna od velikih blagodati Meteora je što je vrlo brzo s njim prototipirati složene JavaScript programe. Budući da je Meteor hibrid prednjeg predloška i prikazivanja, zajedno s Node poslužiteljem koji komunicira s MongoDB-om (objedinjeno rješenje), većina početnih postavki potrebnih za stvaranje web-aplikacije s punim hrpom već je napravljena za vas. Međutim, lakoća razvoja koju ovo pruža može biti zamka. Lako je upasti u loše prakse i završiti s gomilom nestrukturiranog koda prilikom izrade Meteor aplikacije. Imam nekoliko prijedloga kako se to može izbjeći.

Skele: Upravljiva hijerarhija direktorija u Meteoru

Prvo, važno je održavati preporučenu strukturu mapa prilikom izrade aplikacije. Meteor vam omogućuje da prema zadanim postavkama smjestite datoteke bilo gdje unutar mape projekta - ako želite, možete čak i imati sav svoj kôd u jednoj datoteci. Iako bi ovo moglo raditi za projekt hackathona, složenošću koja nastaje zbog uobičajenih skalabilnih aplikacija na razini proizvodnje teško je upravljati bez zvučne strukture.

Kako bih riješio ovaj problem, preporučujem provjeru npm paketa Chrisa Mathera željezo . Paket ima razne mogućnosti konfiguracije, pa će ga ovdje biti teško opisati, ali općenito izrađuje strukturu projekta koja će izgledati otprilike ovako:

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

Međutim, za neke projekte struktura mapa i datoteka može biti pretjerana. Neće svaki projekt morati imati ovu fino definiranu razinu organizacije, s razdvajanjem zbirki, metoda i objavljivanja koda na poslužitelju. Za one koji nemaju prevelik projekt ili jednostavno ne žele instalirati i naučiti drugi npm paket, preporučujem ovu osnovnu strukturu mape:

Ključni elementi su javna mapa koja sadrži datoteke kao što su vaša favicon i druga statička sredstva te klijentske, zajedničke i poslužiteljske mape. Klijentske i poslužiteljske mape trebale bi (naravno) sadržavati kod koji se izvršava na klijentu i na poslužitelju. Uobičajena mapa sadrži kôd koji mora biti dostupan i klijentu i poslužitelju. Primjer za to je kod sheme, o kojem ćemo malo raspraviti.

Postoje dva načina za izvođenje najniže razine organizacije: jedan je prema vrsti datoteke, a drugi prema funkciji. Organizacija prema vrsti datoteke znači da ćete, na primjer, u mapi klijenta / predloga imati tri mape - jednu za JavaScript datoteke, jednu za CSS i jednu za HTML. Mapa HTML sadržavat će sve vaše HTML datoteke s predlošcima, na primjer Login.html, Main.html itd. Mapa JavaScript i CSS sadržavat će datoteke predloška svoje vrste. S druge strane, organizacija prema funkciji znači organiziranje prema konceptu koji datoteke utjelovljuju. Na primjer, u klijentu / predlošcima imao bih mapu 'Prijava', sa svim JavaScript, CSS i HTML datotekama povezanim s postupkom prijave aplikacije. Preferiram organizaciju prema funkciji jer vam omogućuje jasnije pronalaženje određenih datoteka ili dijelova koda. Međutim, to nije čisto crno-bijelo, a većina pojedinaca i timova pogađa neku mješavinu ovih metoda kako bi strukturirala svoje datoteke i mape.

Shema: vaša aplikacija to treba čak i ako vaša baza podataka ne

Druga vrsta strukture o kojoj bih želio razgovarati povezana je s bazom podataka. Ovaj članak pretpostavlja da upotrebljavate MongoDB. Ako niste, koncepti će se vjerojatno i dalje primjenjivati, ali specifičnosti neće. Oni koji koriste MongoDB znaju da to omogućuje nestrukturiranje načina na koji pohranjujemo naše podatke. Budući da je MongoDB baza podataka NoSQL-a za pohranu dokumenata, ne postoji fiksna shema za bilo koju 'vrstu' podataka. Ova sloboda znači da ne morate brinuti hoćete li osigurati da su svi objekti standardizirani u neki kruti oblik, zapravo, svi podaci vaše aplikacije mogu se po želji ubaciti u jednu zbirku. Međutim, što se tiče izrade aplikacija kvalitetne produkcije, ovo zapravo nije toliko poželjno. Kako bismo upravljali ovim i dodali korisne značajke poput provjere valjanosti zahtjeva za pisanje, možemo se obratiti dvama divnim Meteor paketima: Aldeedovom SimpleSchema i Collection2.

Paket SimpleSchema, kao što i samo ime govori, omogućuje vam reaktivnu provjeru valjanosti objekata u vašoj aplikaciji. Pogledajte dokumente na GitHubu . The Zbirka2 spakirajte bootstrapove s SimpleScheme i omogućuje vam unošenje odgovarajućih shema u Meteor kolekcije. Ono što to omogućuje je automatska provjera valjanosti zahtjeva za pisanje na strani klijenta i poslužitelja u bilo koju kolekciju s priloženom shemom. Oba su paketa vrlo duboka i prilagodljiva, tako da ih je teško dati potpuno razumijevanje u nekoliko odlomaka. Umjesto toga, preporučujem vam da pogledate detaljne readmee koje je Aldeed sastavio radi pojedinosti. Jednostavno ću govoriti o tome kako sam izvukao vrijednost iz ovih paketa. Jedna od najboljih stvari koju su omogućili bila je provjera valjanosti unosa korisničkog obrasca. Ovo je korisno za provjeru valjanosti dokumenata Meteor korisnika (iz paketa Accounts). Korisnici Meteora prema zadanim postavkama imaju iznenađujuće složenu implicitnu shemu. Evo slike njegovog dijela iz koda koji je Aldeed bio tako ljubazan učiniti dostupnim:

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 } });

To je jednostavno shema za objekt korisničkog profila. Pokušaj provjere valjanosti svih korisničkih objekata bio bi nered bez namjenski izrađenog paketa kao što je SimpleSchema. Iako se sva ta polja na slici čine neobaveznima, ako želite pravilno provjerenu korisničku shemu, ona to vjerojatno ne bi bila, a stvari poput 'Schema.UserCountry' zapravo preusmjeravaju na druge sheme radi provjere valjanosti. Povezivanjem ove sheme s korisničkim objektom i reaktivnom integracijom u naše obrasce, možda s paketom poput Aldeedov automatski obrazac , možemo steći fini stupanj kontrole nad onim što u našu bazu podataka ulazi, a što ne, uštedom vremena i truda konceptualnim modelom postupanja s podacima u našoj aplikaciji na koji se može ukazati i raspravljati pod konkretnim uvjetima.

Uloge: Za 401. i 403. godine

Konačni prijedlog za strukturiranje i poboljšanje projekta Meteor je Alanningov Paket uloga . Ovo je sustav autorizacije za Meteor i omogućuje vam provjeru razina korisničkog pristupa za bilo koji dio vaše web aplikacije. Dozvole su pridružene korisničkom profilu u obliku nizova koji se kasnije provjeravaju ili poništavaju kada korisnik pokuša pristupiti bilo kojoj metodi Meteor ili podacima objavljenim na klijentu. Na primjer:

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

Iako je jezgra sustava relativno jednostavna, omogućuje složena i precizna dopuštenja za bilo koji dio vaše aplikacije. Budući da su sve uloge pohranjene kao nizovi, možete postaviti sustav koji je dubok koliko želite - 'admin', 'admin.division1.manage', 'admin.division1.manage.group2', i tako dalje.

Problem sa slobodom koju ovaj paket omogućuje je što je teško pratiti visoko granulirani sustav uloga. Paket pruža funkcije poput 'getAllRoles' koja, kao što i samo ime govori, dohvaća sve uloge koje ste stvorili, ali na vama je da pratite koja su njihova značenja i kada bi određena uloga trebala biti korišten. A za one koji su znatiželjni koja je razlika između 'uloga' i 'dozvola', za potrebe ovog paketa oni se u osnovi ne razlikuju.

Završavati

Nažalost, zbog širine članka (svaki od ovdje spomenutih paketa zaslužuje vlastiti vodič) nije bilo moguće detaljno raspravljati o bilo kojem određenom paketu, ali nadam se da ću rasvijetliti kako možete raditi na „standardiziranom ' Meteor za koju možete biti sigurni da će dobro funkcionirati u proizvodnji i na velikoj razini. Ako tražite više informacija, pogledajte veze koje sam objavio i pogledajte još jednu stvar koja nije došla do ovog članka, ali je korisno imati u aplikaciji Meteor: Restivus paket , koji vam omogućuje da lako izložite REST API za svoju aplikaciju.

Kao odricanje odgovornosti, nisam autor niti jednog od ovih paketa i ispričavam se ako sam pogrešno predstavio bilo koju značajku ili ciljeve bilo kojeg paketa. Hvala vam što ste pročitali i nadam se da vam je ovaj članak bio od koristi. Slobodno me kontaktirajte u vezi bilo kakvih pitanja ili ostavite komentar u nastavku.

Povezano: Vodič za Meteor: Izrada web aplikacija u stvarnom vremenu s Meteorom