摘要：我們通過(guò)對(duì)我們應(yīng)用程序的每個(gè)部分進(jìn)行單元測(cè)試來(lái)實(shí)現(xiàn)這一點(diǎn)，同時(shí)遵循一個(gè)標(biāo)準(zhǔn)。它幫助你單元測(cè)試，動(dòng)作和集成容器。當(dāng)在組件庫(kù)中使用庫(kù)函數(shù)時(shí)，它應(yīng)該是純函數(shù)。

工作草案-版本0.2.0

這是一個(gè)Mantra草案規(guī)范，一個(gè)由Kadira創(chuàng)建的Meteor的應(yīng)用程序架構(gòu)。 它幫助開(kāi)發(fā)人員構(gòu)建可維護(hù)的，面向未來(lái)的Meteor應(yīng)用程序。

The MIT License (MIT)

Copyright (c) 2016 Kadira Inc.

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

轉(zhuǎn)載我的翻譯也要署名哦~

(這兒有個(gè)目錄，可我不想寫啦，在我的博客中目錄會(huì)自動(dòng)生成哦~)

Mantra是Meteor的應(yīng)用程序架構(gòu)。 有了Mantra，我們?cè)噲D實(shí)現(xiàn)以下兩個(gè)主要目標(biāo)。
1.可維護(hù)性
可維護(hù)性是與大型團(tuán)隊(duì)合作的關(guān)鍵因素。 我們通過(guò)對(duì)我們應(yīng)用程序的每個(gè)部分進(jìn)行單元測(cè)試來(lái)實(shí)現(xiàn)這一點(diǎn)，同時(shí)遵循一個(gè)標(biāo)準(zhǔn)。 這樣很容易讓新手加入團(tuán)隊(duì)。
2.未來(lái)證明(Future Proof)
JavaScript就像是一個(gè)充滿選擇的土地。 我們對(duì)每個(gè)問(wèn)題有不止一個(gè)最佳解決方案。 現(xiàn)在很難說(shuō)什么是最好的解決方案，未來(lái)會(huì)有什么變化。
Mantra依賴一套將持續(xù)很長(zhǎng)時(shí)間的核心原則，我們?cè)试S其他人根據(jù)需要進(jìn)行更改。

它有一個(gè)現(xiàn)代的，基于React的UI組件層。

它有一個(gè)在你的應(yīng)用程序中定義業(yè)務(wù)邏輯的地方， 我們稱之為 動(dòng)作(action)。

Mantra本身不提供狀態(tài)管理，但它允許你使用各種各樣的狀態(tài)管理器，包括Meteor / Tracker，Redux，Rx.js Observable，Promise和幾乎任何其他的狀態(tài)管理器。

它有一種通過(guò)組合容器(containers)將狀態(tài)(states)和動(dòng)作(action)集成到UI組件中的方法。

它允許你依賴注入。

它幫助你單元測(cè)試UI，動(dòng)作和集成（容器）。

它對(duì)目錄布局，文件命名和其他內(nèi)容都有一些標(biāo)準(zhǔn)。

它不是一個(gè)應(yīng)用程序平臺(tái)，應(yīng)用程序平臺(tái)專注于應(yīng)用打包，傳輸，部署等任務(wù)。Mantra使用Meteor作為應(yīng)用程序平臺(tái)。

它不是一個(gè)樣板，即使我們有著同樣的目錄結(jié)構(gòu)。

它不是一個(gè)代碼生成器，我們可能會(huì)有一個(gè)代碼生成工具(譯者注:已經(jīng)有了，詳見(jiàn)mantra-cli)，但這并不是Mantra的核心部分

它是一套如何構(gòu)建Meteor應(yīng)用程序的標(biāo)準(zhǔn)。

它還帶有一套已經(jīng)被整理過(guò)的且被維護(hù)著的庫(kù)，幫助你在Meteor上實(shí)現(xiàn)Mantra。

Mantra是一個(gè)應(yīng)用程序架構(gòu)。 會(huì)有很多人使用Mantra，包括應(yīng)用程序開(kāi)發(fā)人員，工具創(chuàng)建者，教程作者和項(xiàng)目經(jīng)理，所以擁有一個(gè)每個(gè)人都遵循的標(biāo)準(zhǔn)是非常重要的。 這就是為什么要規(guī)范。

雖然本規(guī)范是以一種簡(jiǎn)單易懂的語(yǔ)句編寫的。 但是，如果你對(duì)以下領(lǐng)域有充分的了解，你讀起來(lái)可能會(huì)感到流暢。

ES2015

React

React Containers

Meteor基礎(chǔ)（Pub / Sub，Tracker，ReactiveDict等）

請(qǐng)參閱附錄A以了解有關(guān)上述領(lǐng)域的更多信息

以下是Mantra的核心組件及其組織方式：

Mantra特別注重你的應(yīng)用程序的客戶端。 Mantra不會(huì)將客戶端和服務(wù)端代碼混合在一起;相反，它建議代碼共享。原因是：

客戶端是你應(yīng)該付出很多努力的地方。它是你的代碼庫(kù)中最大的一部分。服務(wù)器端代碼庫(kù)相對(duì)更容易組織和管理。

客戶端應(yīng)用程序?qū)⑹褂胹chema與服務(wù)器交互。客戶端應(yīng)用程序不應(yīng)該關(guān)心服務(wù)端如何實(shí)現(xiàn)的。
Mantra不支持Universal Apps這個(gè)觀點(diǎn)。它鼓勵(lì)不同的平臺(tái)不同的應(yīng)用程序并在其之間代碼共享。通常有一個(gè)服務(wù)器與幾個(gè)客戶端應(yīng)用程序之間交互。

基于上述觀點(diǎn)，將客戶端和服務(wù)端代碼混合在一起并不是一個(gè)好主意。
當(dāng)我們?cè)诒疽?guī)范中進(jìn)一步討論Mantra時(shí)，它將指的是你應(yīng)用程序的客戶端。

然而，大多數(shù)應(yīng)用程序?qū)⒕哂蟹?wù)器端組件。因此，我們還提供一個(gè)服務(wù)器端的目錄布局。有關(guān)詳情，請(qǐng)參閱附錄B。

我們依賴ES2015及其模塊的很多新特性，因此，為了使用Mantra，你需要使用Meteor 1.3，它附帶了ES2015模塊。

我們使用React作為Mantra中的UI（表示）層。
UI組件不應(yīng)該知道關(guān)于應(yīng)用程序的其余部分的任何內(nèi)容，并且不應(yīng)該讀取或修改應(yīng)用程序的狀態(tài)。 用于渲染UI組件的數(shù)據(jù)和事件處理程序應(yīng)通過(guò)props從容器傳遞或作為動(dòng)作(action)從其內(nèi)部的事件處理程序中傳遞。 有時(shí)需要在UI組件內(nèi)使用臨時(shí)局部狀態(tài)，但該狀態(tài)不應(yīng)在其自身組件外引用。
在編寫UI組件時(shí)，你可以將任意React組件引入程序，包括

在應(yīng)用程序中定義的其他UI組件。

來(lái)自NPM的UI組件（如material-ui）。

應(yīng)用中的任何容器（我們稍后會(huì)討論這個(gè)問(wèn)題）。
還可以導(dǎo)入任何庫(kù)函數(shù)并在UI組件中使用它們。 你可以直接從NPM模塊引入，但不能從任何Meteor軟件包引入。 這些函數(shù)應(yīng)該是純函數(shù)。

這里是一個(gè)簡(jiǎn)單的UI組件：

import React from "react";

const PostList = ({posts}) => (
  

    

      {posts.map(post => (
        

          {post.title}
        
      ))}
    
  
);

export default PostList;

動(dòng)作是你在app中寫業(yè)務(wù)邏輯的地方，它們包括:

驗(yàn)證

State 管理

與遠(yuǎn)程數(shù)據(jù)源的交互
一個(gè)動(dòng)作是一個(gè)簡(jiǎn)單的函數(shù)，它的第一個(gè)參數(shù)是整個(gè)應(yīng)用的Context，其他參數(shù)通常來(lái)自函數(shù)調(diào)用時(shí)。

注意: 在動(dòng)作中，你所做的一切都應(yīng)是基于應(yīng)用的Context傳遞給動(dòng)作的其他參數(shù)。你不能引用任何ES2015的modules 除了庫(kù)以外。還應(yīng)避免在動(dòng)作中使用全局變量。

這是一個(gè)動(dòng)作:

export default{
    create({Meteor,LocalState,FlowRouter},title,content){
        if(!title||!content){
            return LocalState.set("SAVING_ERROR","Title & Content are required!");
        }
    }
    LocalState.set("SAVING_ERROR",null);
    //這里調(diào)用“config/method_stubs”中的一個(gè)method
    //這是我們?nèi)绾巫鲅舆t補(bǔ)償
    Meteor.call("posts.create", id, title, content, (err) => {
      if (err) {
        return LocalState.set("SAVING_ERROR", err.message);
      }
    });
    FlowRouter.go(`/post/${id}`);

    clearErrors({LocalState}){
        return     LocalState.set("SAVING_ERROR", null);
    }

};

在app中，我們需要處理不同種類的狀態(tài)。我們可以把他們分為兩類。

本地狀態(tài) - 從來(lái)不會(huì)同步到遠(yuǎn)程服務(wù)器的狀態(tài)(錯(cuò)誤，驗(yàn)證信息，當(dāng)前的頁(yè)面)

遠(yuǎn)程狀態(tài) - 這是通常從遠(yuǎn)程服務(wù)器獲取并與其同步的state。
我們有不同的解決方案來(lái)管理我們app中的states，包括:

Meteor/MiniMongo (遠(yuǎn)程狀態(tài))

Tracker/ReactiveDict (本地狀態(tài))

FlowRouter (本地狀態(tài))

Redux (本地狀態(tài))

GraphQL (遠(yuǎn)程狀態(tài))

Falcor (遠(yuǎn)程狀態(tài))
這就是JavaScript社區(qū)一直在創(chuàng)新的地方。因此，Mantra在涉及到狀態(tài)管理時(shí)是靈活的。你可以使用任何你想使用的。

舉個(gè)例子，你可以在你的應(yīng)用啟動(dòng)時(shí)使用以下?tīng)顟B(tài):

Meteor/MiniMongo (遠(yuǎn)程狀態(tài))

Tracker/ReactiveDict (本地狀態(tài))

FlowRouter (本地狀態(tài))
之后你也可以換用其他解決方案。

注意: Mantra在管理狀態(tài)時(shí)有一些強(qiáng)制規(guī)則

所有的狀態(tài)的寫操作都要在其對(duì)應(yīng)的動(dòng)作中完成。

你既可以在動(dòng)作中讀取狀態(tài)也可以在容器中讀取狀態(tài)。

不允許直接在UI 組件中讀寫狀態(tài)，UI 組件不應(yīng)該知道任何應(yīng)用程序中的狀態(tài)。

下面的鏈接是一些關(guān)于狀態(tài)的使用例子
Reading from local state – inside a container
Writing into local state – inside an action
Reading from a remote state – inside a container

容器是Mantra的集合層，他們執(zhí)行這些操作:

使用狀態(tài)來(lái)修改變量，并通過(guò)props將它們傳遞到UI組件。

將動(dòng)作(action)傳遞到UI組件中。

將應(yīng)用Context中的項(xiàng)目傳遞到UI組件中
容器是一個(gè)React component。

容器使用react‐komposer，它支持不同的數(shù)據(jù)源，包括 Meteor/Tracker, Promises, Rx.js Observable,和幾乎所有其他的數(shù)據(jù)源。

通常情況下，在容器中需要些下面這些函數(shù):

composer函數(shù)用來(lái)從狀態(tài)管理中獲取數(shù)據(jù)。

mapper函數(shù)從依賴注入層獲取數(shù)據(jù)。
創(chuàng)建容器的一些規(guī)則:

單個(gè)文件中應(yīng)該只有一個(gè)容器，并且這個(gè)容器必須是默認(rèn)引出的(default export)

composer函數(shù)和mapper函數(shù)必須從容器模塊引出(exported)

composer函數(shù)只能使用props傳遞變量

mapper函數(shù)必須是純函數(shù)(Pure function)

注意:如果需要傳遞應(yīng)用Context給一個(gè)組件，請(qǐng)使用mapper函數(shù)函數(shù)通過(guò)props傳遞。

這是一個(gè)容器的例子:

import PostList from "../components/postlist.jsx";
import {useDeps, composeWithTracker, composeAll} from "mantra-core";

export const composer = ({context}, onData) => {
  const {Meteor, Collections} = context();
  if (Meteor.subscribe("posts.list").ready()) {
    const posts = Collections.Posts.find().fetch();
    onData(null, {posts});
  }
};

export default composeAll(
  composeWithTracker(composer),
  useDeps()
)(PostList);

應(yīng)用Context可用于所有操作和容器，因此這是應(yīng)用程序中共享變量的地方，他們包括:

Meteor namespace

Meteor Collections

本地狀態(tài)

FlowRouter

其他Meteor包

Redux Stores

Rest Clients

DDP Clients
這是一個(gè)簡(jiǎn)單的應(yīng)用Context的例子:

import * as Collections from "/lib/collections";
import {Meteor} from "meteor/meteor";
import {FlowRouter} from "meteor/kadira:flow-router";
import {ReactiveDict} from "meteor/reactive-dict";
import {Tracker} from "meteor/tracker";

export default function () {
  return {
    Meteor,
    FlowRouter,
    Collections,
    LocalState: new ReactiveDict(),
    Tracker
  };
}

Mantra使用依賴注入來(lái)隔離應(yīng)用程序的不同部分，包括UI組件和動(dòng)作(actions)。

我們使用一個(gè)名為react-simple-di的項(xiàng)目，它在后臺(tái)使用React Context。 它同時(shí)接受應(yīng)用Context和動(dòng)作(action)作為依賴。

一旦配置，應(yīng)用程序Context會(huì)注入到每一個(gè)action中，它是action的第一個(gè)參數(shù)，因此你不需要手動(dòng)傳遞應(yīng)用Context。

應(yīng)用程序Context也可以在容器中訪問(wèn)。

2.8.1 配置依賴注入

依賴關(guān)系將注入到應(yīng)用程序的頂級(jí)組件中，通常是一個(gè)布局組件，你可以在你的路由中注入，看一下這個(gè)例子:

import React from "react";
export default function (injectDeps) {
  //這是注入部分:
  const MainLayoutCtx = injectDeps(MainLayout);

  // 路由相關(guān)代碼
  //......
}

注意:當(dāng)我們提到組件時(shí)，會(huì)同時(shí)包含容器(containers)和UI組件(UI components)

我們通常使用路由去掛載組件到UI，這可以有多種解決方案(比如Flow Router和React Router)

路由只是一個(gè)工具，它在Mantra中的唯一功能就是將組件掛載到UI上。

看一下使用FlowRouter當(dāng)做路由的例子:

import React from "react";
import {FlowRouter} from "meteor/kadira:flow-router";
import {mount} from "react-mounter";

import MainLayout from "/client/modules/core/components/main_layout.jsx";
import PostList from "/client/modules/core/containers/postlist";

export default function (injectDeps) {
  const MainLayoutCtx = injectDeps(MainLayout);

  FlowRouter.route("/", {
    name: "posts.list",
    action() {
      mount(MainLayoutCtx, {
        content: () => ()
      });
    }
  });
}

注意:如果你需要根據(jù)某些條件重定向（例如用戶未被授權(quán)），請(qǐng)使用action來(lái)代替像FlowRouter的triggersEnter這樣的路由選項(xiàng)。 從組件或容器的composer函數(shù)調(diào)用action。

每個(gè)應(yīng)用程序都有一些實(shí)用的功能去完成不同的任務(wù)，你也可以通過(guò)NPM獲取它們。這些庫(kù)將引出(export)函數(shù)。所以，你可以在應(yīng)用程序的任何位置引用他們，包括動(dòng)作，組件和容器。

當(dāng)在組件庫(kù)中使用庫(kù)函數(shù)時(shí)，它應(yīng)該是純函數(shù)。

測(cè)試是Mantra的一個(gè)核心部分，Mantra幫助你測(cè)試應(yīng)用程序的每一個(gè)部分。我們強(qiáng)制執(zhí)行這些規(guī)則有助于你編寫測(cè)試程序。你可以使用熟悉的工具，如Mocha，Chai和Sinon來(lái)進(jìn)行測(cè)試。

使用Mantra，你可以在應(yīng)用程序中單元測(cè)試以下三個(gè)核心部分:

UI組件 - Example

Actions - Example

Container composers 和 mappers部分 - Example

2.11.1 UI測(cè)試

我們使用enzyme為UI進(jìn)行測(cè)試，點(diǎn)擊這里看一些簡(jiǎn)單的測(cè)試用例。

Mantra遵循模塊化架構(gòu)。 除了“應(yīng)用程序Context”之外，Mantra的所有組件都應(yīng)駐留在模塊中。

你可以創(chuàng)建很多很多的模塊，并通過(guò)imports使它們建立聯(lián)系。

2.12.1 應(yīng)用程序Context和模塊的關(guān)系

應(yīng)用程序Context是應(yīng)用程序的核心。 它需要在不屬于任何模塊的地方定義。 所有模塊可以作為依賴關(guān)系訪問(wèn)應(yīng)用程序Context，模塊不應(yīng)更新應(yīng)用程序Context。

2.12.2 模塊的定義

Mantra模塊可以包含定義它的主文件文件。 它暴露動(dòng)作，路由和接受context的函數(shù)。 通常是 index.js 文件。

一個(gè)簡(jiǎn)單的模塊定義像這樣:

export default {
  // 可選的
  load(context, actions) {
    // 做一些模塊的初始化工作
  },
  // 可選的
  actions: {
    myNamespace: {
      doSomething: (context, arg1) => {}
    }
  },
  // 可選的
  routes(injectDeps) {
    const InjectedComp = injectDeps(MyComp);
    // 加載路由并將"被注入的組件"顯示在屏幕上。
  }
};

2.12.3 隱式模塊

如果一個(gè)模塊沒(méi)有任何action和路由，或者不需要任何初始化，那么可以避免使用定義文件。這種隱式模塊可能包含以下內(nèi)容:

UI組件

容器

庫(kù)

2.12.4 模塊容器和UI組件的關(guān)系

模塊容器和UI組件應(yīng)能夠通過(guò)ES2015模塊引入(imported)。

2.12.5 模塊動(dòng)作

模塊可以通過(guò)命名空間暴露動(dòng)作。 這些命名空間對(duì)于應(yīng)用程序是全局的，模塊應(yīng)該保證它們是唯一的。 一個(gè)模塊可以暴露多個(gè)命名空間。

最后，來(lái)自每個(gè)模塊的所有這些命名空間都被合并，并且可以在action和容器內(nèi)訪問(wèn)。

2.12.6 路由

你可以使用任意的路由庫(kù)進(jìn)行路由。如果需要，也可以在多個(gè)模塊中使用路由定義。

2.12.7 核心模塊

Mantra是100％模塊化的，應(yīng)用程序中應(yīng)至少有一個(gè)模塊， 我們稱之為核心模塊。 它只是一個(gè)簡(jiǎn)單的模塊，但你需要在任何其他模塊之前加載它。 這個(gè)模塊最好放在下面這些地方：

核心路由

應(yīng)用配置

通用庫(kù)

通用動(dòng)作
和其他特定的應(yīng)用代碼中。

根據(jù)應(yīng)用程序，有多種方式組織模塊，詳見(jiàn)附錄C

2.12.8 子模塊

在一個(gè)模塊中，不能 包含子模塊。這是為防止不必要的復(fù)雜性而做出的決定。 否則，編寫多層嵌套模塊是會(huì)很難管理。

使用Mantra，我們希望我們的應(yīng)用是可與預(yù)測(cè)的。因此，你的應(yīng)用只能有一個(gè)入口點(diǎn)，它就是client/main.js。

它將初始化應(yīng)用程序Context并加載應(yīng)用程序中的所有模塊。 這里有一個(gè)client / main.js文件示例：

import {createApp} from "mantra-core";
import {initContext} from "./configs/context";

// 模塊
import coreModule from "./modules/core";
import commentsModule from "./modules/comments";

// 初始化 context
const context = initContext();

// 創(chuàng)建 app
const app = createApp(context);
app.loadModule(coreModule);
app.loadModule(commentsModule);
app.init();

在Mantra中，我們強(qiáng)制使用一個(gè)公共目錄結(jié)構(gòu)。 這是任何應(yīng)用程序的可維護(hù)性的核心部分。

在本節(jié)中，我們只討論客戶端目錄布局。 要了解如何組織服務(wù)器端目錄布局，請(qǐng)參閱附錄B。

所有與Mantra相關(guān)的代碼都保留在應(yīng)用程序的client目錄中。 在內(nèi)部，通常有兩個(gè)目錄和一個(gè)JavaScript文件。 他們是：

* configs
* modules
* main.js

讓我們?cè)敿?xì)分析下他們中的每一個(gè)。

3.1.1 configs

此目錄包含應(yīng)用程序中的根級(jí)別配置。 通常，這是一個(gè)放置所有模塊通用的應(yīng)用程序范圍的全局配置的地方。
此目錄中的所有JavaScript文件都應(yīng)使用默認(rèn)引出函數(shù)(default export function)，該功能可啟動(dòng)某些任務(wù)，并在需要時(shí)返回。

注意:我們通常將應(yīng)用Context放置在這里的context.js中。

3.1.2 modules

此目錄包含應(yīng)用程序中的一個(gè)或多個(gè)模塊（在自己的目錄中）。 這里至少應(yīng)該有一個(gè)模塊，它通常被稱為core。
在modules目錄中，通常有這些內(nèi)容:

* actions
* components
* configs
* containers
* libs
* routes.jsx
* index.js

讓我們學(xué)習(xí)更多關(guān)于這個(gè)目錄下的目錄和文件。

3.1.2.1 actions

此目錄包含模塊中的所有action。 這里有一個(gè)目錄布局的示例：

* posts.js
* index.js
* tests
    - posts.js

posts.js是一個(gè)ES2015模塊，它引出具有action的JavaScript對(duì)象。 例如，下面是一個(gè)簡(jiǎn)單的action模塊：

export default {
  create({Meteor, LocalState, FlowRouter}, title, content) {
    //...
  },

  clearErrors({LocalState}) {
    //...
  }
};

然后，在index.js中，我們引入所有action模塊并聚合所有action。 我們給每個(gè)模塊一個(gè)命名空間。

import posts from "./posts";

export default {
  posts
};

在上面的例子中，我們給posts.js這個(gè)action模塊一個(gè)命名空間posts。

注意:這些命名空間在應(yīng)用程序中應(yīng)該是唯一的。 這是模塊的責(zé)任。

在tests目錄中，我們使用action的名稱為每個(gè)action模塊編寫測(cè)試。 請(qǐng)參閱附錄D以了解有關(guān)測(cè)試文件命名約定的更多信息。

點(diǎn)擊這里查看action的目錄布局

3.1.2.2 components

Components包含模塊化UI組件。 它的目錄布局如下：

* main_layout.jsx
* post.jsx
* style.css
* tests
  - main_layout.js
  - post.js

在這個(gè)目錄下所有的.jsx文件都必須默認(rèn)引出。他們必須是一個(gè)React類。

你可以編寫與這些React組件相關(guān)的CSS文件，Meteor將為你綁定它們。
就像在actions中，這里也有一個(gè)tests目錄。請(qǐng)參閱附錄D以了解有關(guān)測(cè)試文件命名約定的更多信息。

點(diǎn)擊這里查看components的目錄布局

3.1.2.3 containers

此目錄包含一組.js文件，每個(gè)文件表示一個(gè)容器。 每個(gè)文件應(yīng)該作為React Container類默認(rèn)引出。

這是一個(gè)通常的目錄布局:

* post.js
* postlist.js
* tests
    - post.js
    - postlist.js

這個(gè)目錄下也有一個(gè)tests目錄。請(qǐng)參閱附錄D以了解有關(guān)測(cè)試文件命名約定的更多信息。
點(diǎn)擊這里查看containers的目錄布局

3.1.2.4 configs

這個(gè)目錄包含應(yīng)用中模塊層次的配置。

此目錄中的所有JavaScript文件必須引出一個(gè)默認(rèn)函數(shù)，該函數(shù)可啟動(dòng)任何任務(wù)，并在需要時(shí)返回一些內(nèi)容。 該函數(shù)可以接受“應(yīng)用程序Context”作為第一個(gè)參數(shù)。

這是一個(gè)簡(jiǎn)單的config文件:

export default function (context) {
  // do something
}

這些設(shè)置可以在加載這個(gè)模塊時(shí)被引用和調(diào)用。

注意:通常，這是我們保存用于樂(lè)觀更新的Meteor方法存根的地方。

點(diǎn)擊這里查看configs的目錄布局

3.1.2.5 libs

此目錄包含一組有效引出函數(shù)的JavaScript文件（.js或.jsx）。 這也被稱為庫(kù)。 您可以在tests的子目錄中編寫庫(kù)的測(cè)試。

3.1.2.6 routes.jsx

這是包含模塊的路由定義的文件。 它有一個(gè)默認(rèn)引出，它是一個(gè)函數(shù)。 下面是一個(gè)典型的路由定義：

import React from "react";
import {FlowRouter} from "meteor/kadira:flow-router";
import {mount} from "react-mounter";

import MainLayout from "/client/modules/core/components/main_layout.jsx";
import PostList from "/client/modules/core/containers/postlist";

export default function (injectDeps) {
  const MainLayoutCtx = injectDeps(MainLayout);

  FlowRouter.route("/", {
    name: "posts.list",
    action() {
      mount(MainLayoutCtx, {
        content: () => ()
      });
    }
  });
}

如上所示，在加載模塊時(shí)，將使用一個(gè)名為injectDeps的函數(shù)來(lái)調(diào)用此默認(rèn)引出，injectDeps函數(shù)可以將依賴項(xiàng)注入到React組件(或容器)中。

3.1.2.7 index.js

這是模塊的定義文件(主文件)。如果不需要執(zhí)行以下任務(wù)則不需要此文件:

加載路由

定義action

在加載模塊時(shí)運(yùn)行配置
這是一個(gè)典型的模塊定義文件:

import methodStubs from "./configs/method_stubs";
import actions from "./actions";
import routes from "./routes.jsx";

export default {
  routes,
  actions,
  load(context) {
    methodStubs(context);
  }
};

在模塊定義中，當(dāng)模塊加載時(shí)，會(huì)調(diào)用.load()方法，所以，這里是調(diào)用配置的地方。

3.1.3main.js

這是Mantra應(yīng)用程序的入口點(diǎn)。 它初始化應(yīng)用程序Context并加載模塊。 因此，它使用一個(gè)名為mantra-core的實(shí)用程序庫(kù)。

這是一個(gè)簡(jiǎn)單的main.js文件的例子:

import {createApp} from "mantra-core";
import initContext from "./configs/context";

// 模塊
import coreModule from "./modules/core";
import commentsModule from "./modules/comments";

// 初始化 context
const context = initContext();

// 創(chuàng)建應(yīng)用(app)
const app = createApp(context);
app.loadModule(coreModule);
app.loadModule(commentsModule);
app.init();

Mantra是一個(gè)草稿，將有缺失的部分和我們可以做的改進(jìn)。 我們已經(jīng)確定以下功能對(duì)Mantra很重要，他們將在不久的將來(lái)可用。
(懶得翻了 過(guò)過(guò)再更~)

It’s extremely possible to do SSR with Mantra. We are trying to do this in a tool‐agnostic manner, but the reference implementation will be based on FlowRouter SSR.

We could distribute Mantra modules via NPM. Once we do that, we could do reuse a lot of code between apps and organizations.

It’s better to have a standard for styling UI components.

It’s better to have a standard for writing test cases.

Sometimes, we can use reuse composers for the same function in many places. We need to find a pattern for doing that.