През последните няколко години се наблюдава драстично увеличаване на броя на наличните JavaScript рамки. Като се започне от изпитания AngularJS до резултатите от рамки, които излизат всеки месец, можете да избирате от впечатляващо разнообразие. Тази, която привлече вниманието ми преди няколко години, е рамка, наречена Meteor. За разлика от повечето рамки, Meteor се стреми да бъде цялостна платформа за разработка на приложения на JavaScript. За тези, които са нови за Meteor, ви препоръчвам да го проверите техния уебсайт . Тази статия няма да бъде въведение в Meteor. Вместо това ще проучим няколко прости начина за въвеждане на структура в проектите на Meteor.

Ръководство за разработчици за подобряване на структурата на проектите в метеорната рамка Tweet

Едно от големите предимства на Meteor е, че е много лесно да се прототипират сложни JavaScript приложения с него. Тъй като Meteor е хибрид от предни крайни шаблони и рендериране, съчетани с Node-базиран сървър, взаимодействащ с MongoDB (единно решение), по-голямата част от първоначалната настройка, необходима за създаването на пълно стек уеб приложение, вече е направена за вас. Лекотата на развитие, която това осигурява, може да бъде капан. Лесно е да изпаднете в лоши практики и да завършите с бъркотия от неструктуриран код, когато създавате приложение на Meteor. Имам няколко предложения как това може да се избегне.

Скеле: Управляема йерархия на директории в Метеор

Първо, важно е да поддържате препоръчителната структура на папките, когато изграждате приложението си. Meteor ви позволява да поставяте файлове навсякъде в папката на проекта по подразбиране - дори можете да имате целия си код в един файл, ако желаете. Въпреки че това може да работи за хакатонен проект, сложността, породена от обичайните, мащабируеми приложения на ниво производство, е трудна за управление без звукова структура.

За да разрешите този проблем, препоръчвам да проверите npm пакета на Chris Mather желязо . Пакетът има разнообразни опции за конфигуриране, така че ще бъде трудно да се опише тук, но като цяло той изгражда структурата на проекта, която ще изглежда по следния начин:

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

За някои проекти обаче структурата на папки и файлове като тази може да бъде прекалено голяма. Не всеки проект ще трябва да има това фино ниво на организация, с разделяне на колекции, методи и публикуване на код на сървъра. За тези, които нямат прекалено голям проект или просто не искат да се налага да инсталират и научат друг npm пакет, препоръчвам тази основна структура на папките:

Ключовите елементи са публична папка, която съдържа файлове като вашия Favicon и други статични активи, както и клиентски, общи и сървърни папки. Клиентската и сървърната папки трябва (разбира се) да съдържат код, който се изпълнява съответно на клиента и сървъра. Общата папка съдържа код, който трябва да бъде достъпен както за клиента, така и за сървъра. Пример за това е кодът на схемата, който ще обсъдим след малко.

Има два начина за извършване на най-ниското ниво на организация: единият е по тип файл, а вторият е по функция. Организация по тип файл означава, че във вашата папка клиент / шаблони, например, ще имате три папки - една за JavaScript файлове, една за CSS и една за HTML. Папката HTML ще съдържа всички ваши HTML файлове с шаблони, например Login.html, Main.html и т.н. Папките JavaScript и CSS ще съдържат съответно файлове с шаблони от техния тип. Организация по функция, от друга страна, означава организиране чрез концепцията, която файловете въплъщават. Например в клиент / шаблони щях да имам папка „Вход“, с всички JavaScript, CSS и HTML файлове, свързани с процеса на влизане в приложението. Предпочитам организацията по функции, тъй като ви позволява да сте по-ясни къде можете да намерите определени файлове или парчета код. Това обаче не е чисто черно-бяло и повечето хора и екипи удрят върху някаква комбинация от тези методи, за да структурират своите файлове и папки.

Схема: Вашето приложение се нуждае, дори ако вашата база данни не го прави

Вторият вид структура, която бих искал да обсъдя, е свързана с базата данни. Тази статия предполага, че използвате MongoDB. Ако не сте, понятията вероятно ще продължат да се прилагат, но спецификата няма. Тези, които използват MongoDB, знаят, че това позволява начинът, по който съхраняваме данните си, да бъде неструктуриран. Тъй като MongoDB е база данни на NoSQL за съхраняване на документи, няма фиксирана схема за какъвто и да е „тип“ данни. Тази свобода означава, че не е нужно да се притеснявате, че всички обекти са стандартизирани в някаква твърда форма, всъщност всички данни на приложението ви могат да бъдат хвърлени в една колекция, ако желаете. Що се отнася обаче до създаването на приложения с високо качество, това всъщност не е толкова желателно. За да управляваме това и да добавяме полезни функции като валидиране на заявки за запис, можем да се обърнем към два прекрасни пакета Meteor: SimpleSchema на Aldeed’s и Collection2.

Пакетът SimpleSchema, както подсказва името, ви позволява да проверявате реактивно обектите в приложението си. Вижте документи на GitHub . The Колекция2 пакетира bootstraps на SimpleSchema и ви позволява да въведете правилни схеми в колекциите на Meteor. Това, което позволява, е автоматично валидиране на клиентски и сървърни заявки за запис във всяка колекция с прикрепена към нея схема. И двата пакета са много дълбоки и могат да се персонализират, така че е трудно да ги разберете напълно в няколко параграфа. По-скоро ви препоръчвам да разгледате подробните readmes, които Aldeed е съставил за спецификата. Просто ще говоря за това как получих стойност от тези пакети. Едно от най-добрите неща, които те активираха, беше валидиране на въвеждането на формуляра на потребителя. Това е полезно за валидиране на потребителски документи на Meteor (от пакета Accounts). По подразбиране потребителите на Meteor имат изненадващо сложна неявна схема. Ето снимка на част от него от кода, която Aldeed беше така любезен да предостави:

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

Това е просто схемата за обекта на потребителския профил. Опитът за валидиране на целия потребителски обект би бил бъркотия без специален пакет като SimpleSchema. Въпреки че всички тези полета изглеждат незадължителни на снимката, ако искате правилно валидирана потребителска схема, те вероятно няма да бъдат и неща като „Schema.UserCountry“ всъщност пренасочват към други схеми за проверка. Като прикачите тази схема към потребителския обект и я интегрирате реактивно към нашите формуляри, може би с пакет като Aldeed’s AutoForm , можем да постигнем фина степен на контрол върху това, което прави и какво не прави в нашите бази данни, спестявайки време и усилия с концептуален модел на това как се обработват данните в нашето приложение, който може да бъде посочен и обсъден при конкретни условия.

Роли: За 401 и 403-те

Последното предложение, което имам за структуриране и подобряване на проект на Meteor, е Alanning’s Опаковка от роли . Това е система за оторизация за Meteor и ви позволява да проверите нивата на достъп на потребителите за която и да е част от вашето уеб приложение. Разрешенията са прикрепени към потребителския профил под формата на низове, които по-късно се потвърждават или обезсилват, когато потребителят се опита да осъществи достъп до каквито и да било методи на Meteor или данни, публикувани на клиента. Например:

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

Въпреки че ядрото на системата е относително проста, тя позволява сложни и фино разрешени разрешения за всяка част от вашето приложение. Тъй като всички роли се съхраняват като низове, можете да настроите система, която е толкова дълбока, колкото искате - „admin“, „admin.division1.manage“, „admin.division1.manage.group2“ и т.н.

Проблемът със свободата, която позволява този пакет, е, че може да бъде трудно да се проследи една силно гранулирана система от роли. Пакетът предлага функции като „getAllRoles“, която, както подсказва името, извлича всички роли, които сте създали, но от вас зависи да следите какво е тяхното значение и кога дадена роля трябва използван. А за тези, които са любопитни каква е разликата между „роли“ и „разрешения“, за целите на този пакет те по същество не се различават.

Обобщавайки

За съжаление, поради широчината на статията (всеки от пакетите, споменати тук, заслужава свой собствен урок), не беше възможно да се влезе в подробности за даден конкретен пакет, но се надявам да хвърля светлина върху това как можете да работите за „стандартизиран ” Метеор приложението, за което можете да сте сигурни, ще работи добре в производството и в мащаб. Ако търсите повече информация, разгледайте връзките, които публикувах, и разгледайте още едно нещо, което не стигна до тази статия, но е полезно да бъде в приложението на Meteor: Пакет Restivus , което ви позволява лесно да изложите REST API за вашето приложение.

Като отказ от отговорност, аз не съм автор на нито един от тези пакети и се извинявам, ако съм представил погрешно някоя от характеристиките или целите на който и да е пакет. Благодаря ви за четенето и се надявам тази статия да ви е от полза. Чувствайте се свободни да се свържете с мен, ако имате въпроси, или оставете коментар по-долу.

Свързани: Урок за Meteor: Изграждане на уеб приложения в реално време с Meteor