改進 Meteor 應用程序中項目結構的開發人員指南

在過去的幾年裡，可用的 JavaScript 框架的數量急劇增加。 從久經考驗的 AngularJS 到每月發布的大量框架，有令人印象深刻的多樣性可供選擇。 幾年前引起我注意的是一個名為 Meteor 的框架。 與大多數框架不同，Meteor 旨在成為 JavaScript 應用程序開發的完整平台。 對於那些不熟悉 Meteor 的人，我鼓勵您在他們的網站上查看。 本文不會是 Meteor 的介紹。 相反，我們將探索一些在 Meteor 項目中引入結構的簡單方法。

Meteor 的一大好處是可以很容易地用它來快速製作複雜的 JavaScript 應用程序原型。 因為 Meteor 是前端模板和渲染的混合體，再加上與 MongoDB 交互的基於節點的服務器（一個統一的解決方案），所以創建全棧 Web 應用程序所需的大部分初始設置已經為您完成。 但是，這提供的開發便利性可能是一個陷阱。 在構建 Meteor 應用程序時，很容易陷入不良實踐並最終得到一堆亂七八糟的非結構化代碼。 對於如何避免這種情況，我有一些建議。

腳手架：Meteor 中的可管理目錄層次結構

首先，在構建應用程序時保持推薦的文件夾結構很重要。 默認情況下，Meteor 允許您將文件放置在項目文件夾中的任何位置 - 如果您願意，您甚至可以將所有代碼放在一個文件中。 雖然這可能適用於黑客馬拉松項目，但如果沒有健全的結構，通常生產級、可擴展的應用程序所產生的複雜性很難管理。

為了解決這個問題，我建議查看 Chris Mather 的 npm 包 Iron。 該包具有多種配置選項，因此很難在此處描述，但通常它構建的項目結構如下所示：

 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 包的人，我推薦這個基本的文件夾結構：

關鍵元素是一個公用文件夾，其中包含您的網站圖標和其他靜態資產等文件，以及客戶端、公共和服務器文件夾。 客戶端和服務器文件夾（當然）應該包含分別在客戶端和服務器上執行的代碼。 公共文件夾包含客戶端和服務器都必須可以訪問的代碼。 Schema 代碼就是一個例子，我們稍後會討論。

有兩種方法可以進行最低級別的組織：一種是按文件類型，第二種是按功能。 按文件類型組織意味著在您的客戶端/模板文件夾中，例如，您將擁有三個文件夾 - 一個用於 JavaScript 文件，一個用於 CSS，一個用於 HTML。 HTML 文件夾將包含您的所有模板 HTML 文件，例如 Login.html、Main.html 等。 JavaScript 和 CSS 文件夾將分別包含其類型的模板文件。 另一方面，按功能組織意味著按文件所體現的概念進行組織。 例如，在客戶端/模板中，我將有一個“登錄”文件夾，其中包含與應用程序登錄過程相關的所有 JavaScript、CSS 和 HTML 文件。 我更喜歡按功能組織，因為它可以讓您更清楚地知道在哪裡可以找到某些文件或代碼片段。 然而，這並不是純粹的黑白，大多數個人和團隊都會嘗試混合使用這些方法來構建他們的文件和文件夾。

Schema：即使您的數據庫不需要，您的應用也需要它

我想討論的第二種結構與數據庫相關聯。 本文假設您使用的是 MongoDB。 如果你不是，這些概念可能仍然適用，但細節不會。 使用 MongoDB 的人知道，它允許我們存儲數據的方式是非結構化的。 由於 MongoDB 是一個 NoSQL 文檔存儲數據庫，因此對於任何“類型”的數據都沒有固定的模式。 這種自由意味著您不必擔心確保所有對像都標準化為某種嚴格的形式，事實上，如果您願意，您的應用程序的所有數據都可以放入單個集合中。 然而，當談到製作生產質量的應用程序時，這並不是那麼理想。 為了管理這一點並添加有用的功能，例如驗證寫入請求，我們可以求助於兩個出色的 Meteor 包：Aldeed 的 SimpleSchema 和 Collection2。

顧名思義，SimpleSchema 包允許您響應式地驗證應用程序中的對象。 查看 GitHub 上的文檔。 Collection2 包從 SimpleSchema 引導，並允許您將適當的模式帶入 Meteor 集合。 這可以自動驗證客戶端和服務器端對任何附加了模式的集合的寫入請求。 這兩個包都非常深入且可定制，因此很難在幾段中完全理解它們。 相反，我建議您查看 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 這樣的專用包，嘗試驗證所有 User 對象將是一團糟。 雖然所有這些字段在圖片中都是可選的，但如果您想要一個經過適當驗證的用戶模式，它們可能不會，並且諸如“Schema.UserCountry”之類的內容實際上會重定向到其他模式進行驗證。 通過將此模式附加到 User 對象並將其反應性地​​集成到我們的表單中，也許使用像 Aldeed 的 AutoForm 這樣的包，我們可以很好地控制哪些內容進入我們的數據庫，節省時間和精力在我們的應用程序中如何處理數據的概念模型，可以指出並以具體術語進行討論。

角色：適用於 401 和 403

我對構建和改進 Meteor 項目的最後建議是 Alanning 的 Roles 包。 這是 Meteor 的授權系統，它允許您檢查 Web 應用程序任何部分的用戶訪問級別。 權限以字符串的形式附加到用戶配置文件中，稍後當用戶嘗試訪問發佈到客戶端的任何 Meteor 方法或數據時，這些權限將被驗證或失效。 例如：

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

儘管系統的核心相對簡單，但它允許對應用程序的任何部分進行複雜且細粒度的權限。 由於所有角色都存儲為字符串，因此您可以設置一個任意深度的系統 - “admin”、“admin.division1.manage”、“admin.division1.manage.group2”等。

這個包允許的自由度的問題是很難跟踪高度精細的角色系統。 該包確實提供了諸如“getAllRoles”之類的功能，顧名思義，它檢索您創建的所有角色，但由您來跟踪它們的所有含義以及給定角色何時應該使用。 對於那些好奇“角色”和“權限”之間有什麼區別的人來說，就這個包的目的而言，它們本質上沒有什麼不同。

包起來

不幸的是，由於文章的廣度（這裡提到的每個包都應該有自己的教程），不可能詳細介紹任何特定的包，但我希望我能闡明你如何努力實現“標準化” 您可以放心的 Meteor 應用程序將在生產和規模化中運行良好。 如果您正在尋找更多信息，請查看我發布的鏈接並查看本文中沒有包含但在 Meteor 應用程序中有用的另一件事：Restivus 包，它允許您輕鬆為您的應用公開 REST API。

作為免責聲明，我不是任何這些軟件包的作者，如果我歪曲了任何軟件包的任何功能或目的，我深表歉意。 感謝您的閱讀，希望這篇文章對您有所幫助。 如有任何問題，請隨時與我聯繫，或在下方發表評論。