摘要：場景為了更清晰的安排年前年后的工作和值班，現在要對過年期間人員請假的情況進行統計，并且進行一個簡單的管理。我們現在來訂閱一個名為的事件，用來表示表格中需要展示每條數據。

React 導讀（一）
React 導讀（二）

在之前 2 篇文章中中學習到了寫第一個 Web 組件以及常用的生命周期函數的使用，這篇文章將繼續之前的目錄，開始新的知識點補充：

[x] React 如何編寫 Hello World!

[x] React 中三個最基礎、最重要的東西

[x] React 中的 JSX

[x] 你的第一個 Web 組件

[x] React 中最開始需要關注的生命周期

[x] React 一個組件集合的簡單交互

[x] React 開始一個項目的一點建議

[ ] React 簡單的項目結構組織

這篇文章主要會介紹第6、7的知識點。

為什么要將6、7合在一起寫呢？不是因為想偷懶...其實是脫離一個場景和合適的開始去規劃組件等設計都是不合理的，多多少少都有點交集，所以將這 2 點融合在一起是更利于學習和理解的，到這里就已經不是太基礎的內容了，基本上代碼量會有所提高，但是分析依然會很細致。

這里用一個簡單的表格的添加、刪除、編輯、搜索四個功能來作為實例吧。
因為這應該是日常開發過程中遇到過程最多的，我將參考 bootstrap-table 的方式來開發一個簡單的表格組件和約定配置來做，感覺比較自由，如果你動手能力好且業務稍大和復雜可以參考 antd 設計規范來實現，目前市面上應該螞蟻這套用的比較多，但是這并不意味著我們就一定是按照他來做，實際項目不復雜的情況是可以使用更簡單的方式。

做這個開始之前，首先要假設一點場景和基本需求，這樣才能帶著去思考如何實現以及更接近需求目標。

(1) 場景

為了更清晰的安排年前年后的工作和值班，現在要對過年期間人員請假的情況進行統計，并且進行一個簡單的管理。

(2) 功能性需求

添加員工的請假信息

展示添加的員工請假的列表

能夠對信息進行修改

能夠刪除添加的信息，由于不可恢復，所以需要一個提示

能夠根據員工的名字進行搜索

簡單描述了一下，其實就之前說的幾個功能。

最后做出來的效果如下(=.=沒有設計，對齊就行哈)：

看之前可以下載源代碼對照著看，不過代碼可能會不斷修改 BUG，哈哈~有 BUG 不要虛，沒有 BUG 我們可能就失業了。
源碼-GitHub

(3) 準備工作

整理需要用到的技術

開發要用的基礎 UI 組件

看下 bootstrap-table 的基本設計

搭建項目目錄

1. 需要用到的技術
需要用到的技術：React/ES6, CSS 即可

2. 基礎 UI 組件
根據我們這里的功能來看，我們只需要下面這幾個基礎組件即可：
Button, Dialog, Input, Table, Radio

在這個例子項目里面，組件的劃分結構如下：

為什么要這樣劃分呢？

基礎組件：其實這個是每一個項目都需要的，如果說太小的項目不需要其實大多數是考慮掉了項目的迭代周期的考量以及以后代碼的可復用性，顧名思義，基礎組件就是你要在以后的組件編寫過程中需要依賴的最基礎的組件，基本是只負責 UI 層面的職責，當然你還能夠再剝離，這里就不太展開了，知道這一層是為了以后寫組件能夠有自己的基礎組件即可。

業務組件、模塊組件：在我們開發好基礎組件過后，其實這些基礎組件是不具備任何業務價值的，比如有了業務設計稿后，我們需要針對業務然后編寫業務中公用的組件或者封裝使用操作2次的組件代碼，形成一個可復用的業務組件或者業務模塊類型的組件。比如我這里會將每個模塊用到的模塊標題封裝成一個 ModTitle 組件，這樣以后修改這里樣式的時候全部就在一個地方修改，或者在業務系統上會有 Layout 相關的布局組件需求，再比如系統中表格整個一塊的需求，包含搜索、頭部操作按鈕、數據展示表格，這三者能夠進行一個通用性的封裝來形成業務模塊上的表格使用組件，增加編寫模塊的效率，當然這里我并沒有封裝，因為封裝和重構并不是軟件初始開發更應該注重的，而是遇到第二次的時候再反過來思考如何避免重復或者讓組件內部封裝。

展示組件、容器組件：這一層就是網上流行的展示型組件、容器組件的一層，我這里劃分主要是跟具體業務功能有關系的一層。由于我這里沒有 react-router，所以復雜度會低一些，后面有時間也可以介紹。

3. bootstrap-table 生成表格的方式

可以查看 github-bootstrap-table 的使用例子來看下使用方式，這里我用它做例子并不是說此庫完全好或者不好，而是以前項目用了 bootstrap-table 然后就模仿了 columns 配置的方式，對于它 API 設計的其他部分暫時沒采用。
表格組件其實是管理類系統很核心的部分，一是用的多，二是本身也比較復雜，封裝太死缺少靈活性，封裝太簡單缺少效率，種類也比較多。大體上我會采用字段進行配置的方式，具體看后面的代碼和分析。

4. 項目的目錄規劃
上面介紹了一些概念性的東西，那么項目主要的目錄多帶帶提一下，這里的項目目錄不適合大型項目，但是需要一個這個過程，來理解每一項的意思以及為什么我們還需要其他技術來解決你遇到的問題，堆技術的做法是不可取的，至少在不瘋狂 KPI 模式的情況下。

├── public
│?? ├── favicon.ico
│?? ├── index.html
│?? └── manifest.json
├── server // 網站后端的目錄，這里我們不需要關系
├── src // 前端的源代碼目錄
│?? ├── App.js // App 的入口組件
│?? ├── apis // API 請求層的相關文件，Ajax 的方法也是需要適配的，比如常見的攔截器做法
│?? ├── app.css
│?? ├── assets // 一些靜態資源
│?? ├── components // 包含了業務組件、模塊組件、展示組件，這里項目較小的時候不需要劃分太細，但是要有這樣的分層來組織代碼
│?? ├── containers // 容器組件，主要的副作用等邏輯組件，基本上是數據初始化、維護一個較頂層的數據入口
│?? ├── index.css
│?? ├── index.js // 網站的入口 JS 文件，主要是負責組件掛載到 DOM，或者你也可以做一些全局注入的一些操作
│?? ├── normalize.css
│?? ├── registerServiceWorker.js
│?? ├── smarty // 基礎組件的目錄，這里我叫它 smarty，命名空間使用 st-，這個隨你高興
│?? ├── stores // 數據操作的主要聚焦地方，每一個 Store 都能是一個事件訂閱者，用于連接 React View 組件
│?? └── utils // 一些工具輔助函數，目前我這里沒有使用，真實項目肯定會用上的

(4) 開始思考要如何開始寫代碼

需要一個 React 的容器組件來渲染我想要的一個功能模塊；

功能模塊的數據需要一個地方進行管理。

要解決第一個問題，假設我們的容器組件叫 EmployeeManage，那么在最外層的 App 組件中應該聲明要渲染它，代碼就會是這樣：

class App extends Component {
    render() {
        return (
            

                
            
        );
    }
}

好了，假設這樣會出現最初的那個效果圖的樣子，那么數據并不想寫的太過于零散，所以我定義了一個 Store 類進行管理，為什么是類呢？現在不是流行 Redux 之類函數式的么？一是在最開始學習的時候增加太多技術棧心累，二是不一定要用 Redux 我們才能寫好 React，三是感覺也不太必要就我們目前的需求來看，四是我就想最初簡簡單單的。
但是現在我們是數據驅動方式的編程，數據變了來通知 React 的 state 變了然后 React 去幫我們做視圖的更新，所以，我們的 Store 得是一個基于事件的類，要有事件應該有的特征：監聽。所以最后我需要一個 EmployeeStore：

// 用下自帶的，你也可以自己實現一個簡單的
import EventEmitter from "events";
import assign from "object-assign";

const state = {};

const EmployeeStore = assign({}, EventEmitter.prototype, {
    // 把容器組件的 this.state 在這里管理
    getState() {
        return state;
    }
});

原始是原始了一點，但是應該很好理解，那就是我的 EmployeeStore 擁有了 EventEmitter.prototype 的東西，比如常用的 on(), off(), emit() 等方法來實現事件特性。
然后我們需要把 EmployeeManage 和 EmployeeStore 連接起來，最簡單的連接像這樣子：

class EmployeeManage extends React.Component {
    constructor() {
        super();
        // 看這里
        this.state = EmployeeStore.getState();
    }
}

連接了這個基礎的東西，我們的 EmployeeStore 不是還可以訂閱事件么？然后數據修改了我們就觸發一下訂閱的事件去告訴 EmployeeManage 然后通過 this.setState 去更新視圖即可，整個關系如下：

看圖可能就更直觀的知道數據和組件之間的關系了，用過 Flux 可能可以發現還比較像，但是這是兩個不同的理念，我這里只是一個最基礎的事件系統，所以會特別簡單。

我們現在來訂閱一個名為 updateList 的事件，用來表示表格中需要展示每條數據。我們需要在 EmployeeManage 中加入下面的代碼：

componentDidMount() {
    EmployeeStore.on("updateList", this.handleUpdateList);
}

componentWillUnMount() {
    EmployeeStore.off("updateList", this.handleUpdateList);
}
    
handleUpdateList(list) {
    this.setState(prevState => {
        return {
            list: list,
        };
    });
}

這三個方法能跟上面的圖對應一下，就對應上了 EmployeeManage 和 Component，那么我們的 Store 需要怎么做呢？

getList() {
    // API 請求列表數據的方法，返回一個 Promise
    EmployeeApi.get().then(result => {
        if(result.status === 200) {
            // 剛好，就通知了 EmployeeManage 說我數據獲取成功了，可以更新視圖了
            this.emit("updateList", result.data);
        }
    });
},

以上就完成了連接工作了，基本上剩下的就是碼代碼，往上累積功能。
先寫到這里吧，太長看著也累，分一下章節吧~其實架子已經差不多了，剩下的就是寫功能點了。如果覺得看文章太慢可以直接看源碼可能會更快更直接一點，沒有數據層，其實并不是太好，先理解視圖和關系吧。