邏輯管理：解決方案（二） - 組裝原子和原子共存，共建上層輸出邏輯

時間 2019-11-06

標籤邏輯管理解決方案組裝原子共存共建上層輸出简体版

原文原文鏈接

###同步更新博客園、知乎、知乎專欄前端

閱讀tips

此文章是一個連續探索關於程序中的邏輯的如何管理的系列，在JavaScript中落地實踐，理論上思想適用任何語言，建議從頭看：vue

1. 邏輯管理 - 關於前端邏輯管理的設計和實現react

概念解釋

在新迭代以前，解釋下以前博客中所說的一些概念，由於在內部分享的時候，也讓不少人去疑惑。git

關於原子邏輯概念

以前的理解是抽象到沒法再繼續分割的程度的叫原子邏輯，在實施以後發現，當你真正細分到那個程度的時候，會帶來不少問題：github

是否真正須要細分到那麼細節？
理想化的實踐會不會帶來更高的成本？
解決方案的使用者是否更方便？
...

針對這個問題，思考了好久，太理想化的東西，願景是好的，可是真正落地的時候，會發現有不少的坑須要本身去踩。因此原子邏輯的概念須要進行變動。ajax

過去：~~將原子拆分到沒法拆分的步驟，保證一個方法或者屬性只作一件事或者只表明一個屬性~~
如今：內部造成邏輯閉環，或依賴更低維度的邏輯造成閉環，爲組裝提供邏輯服務能力的稱爲原子邏輯npm

關於該開源項目究竟是作什麼的？

首先肯定一點，該項目 不是教使用者去怎麼抽象咱們項目/業務中的邏輯，由於每一個人的思惟和角度不同，抽象的顆粒度也不一致。該項目只是 作一個解決方案，對邏輯的一個統籌管理，組裝生產，以及最後的結果管理。這樣就能夠對散落在整個鏈路的邏輯作強制管控，全部的邏輯從這裏出發，而後組裝，最後提供服務，一層層邏輯的流轉鏈路，清晰明瞭。架構

現實項目：接手了不少項目，最大的痛點就是 全部邏輯沒有管理而失控，畢竟失控就意味着，它將終究會在「巨石應用」的路上越走越近。框架

組裝原子的設計

在上一篇初步的探討中遺留了一個問題：組裝原子如何和原子共存，共建上層輸出邏輯？測試

什麼是組裝原子？

依賴更低層的原子，組裝而成，造成閉環，對外提供原子服務的，稱之爲組裝原子

真實案例

完成簡單的功能：前端請求增長mock能力。能夠直接clone下demo，安裝好依賴後，經過npm run start進行配合閱讀

設計圖

原子類管理

不依賴外部自閉環的邏輯 ==> config配置、mock數據
依賴自閉環邏輯造成閉環的邏輯 ==> request模塊

組裝類管理

對外依賴request，組裝出測試代碼。

代碼工程結構

one目錄：config.js 和 mock.js

export default {
  name: 'config',
  assembly: {
    // 請求配置
    requestConfig:{
      testData:{
        url: 'https://xxxx.com/get',
        mock: true
      }
    }
  }
}
複製代碼

export default {
  name: 'mock',
  assembly: {
    testData: '我是mock獲取的數據'
  }
}
複製代碼

two目錄：request.js

import ajax from 'ajax-js'

/*
* do something
*   請求配置，timeout，header，error等等
* */

export default {
  name: 'request',
  extend: ['mock', 'config'],
  assembly: {
    get(name) {
      // 判斷配置文件中是否存在請求配置
      if (this.requestConfig[name]) {
        // 判斷是否開啓mock
        if (this.requestConfig[name].mock) {
          // 獲取mock中的邏輯
          return Promise.resolve(this[name])
        } else {
          // 不開啓mock，發送真實請求
          return ajax.get(this.requestConfig[name].url)
        }
      } else {
        console.error('未檢測到合法請求，請覈對配置文件')
      }
    }
  }
}
複製代碼

package目錄：index.js -組裝

export default {
  name: 'testFile',
  extends: ['request'],
  through: false,
  assembly: {
    testRequestFun() {
      this.get('testData')
        .then(x => {
          console.warn('測試mock功能結果：', x)
        })
    }
  }
}
複製代碼

index.js - 注入配置

import {injection, getMateriel} from '@fines/factory-js'

import config from './atom/one/config'
import mock from './atom/one/mock'
import request from './atom/two/request'

import test from './package/index'

injection({
  atom: [
    [config, mock],
    [request]
  ],
  package: [test]
})

export default getMateriel('testFile')
複製代碼

測試代碼

import mockDemo from './mockDemo'

// 測試組裝原子請求
mockDemo.testRequestFun('testData')
複製代碼

測試結果

整個邏輯的數據流向以下圖

這樣一層一層的單向數據流的好處概括以下

邏輯數據流動方向能夠跟蹤，流動單一，追查問題的時候能夠更快捷。
每一個邏輯的管理（好比，config、mock、request等）就是對邏輯的切片，在當前的切片裏能夠作替換、灰度等等。
抽象和概括思惟的加強，如何去抽象，如何去依賴設計，以達到最契合當前項目的架構。
助力邏輯管理更加方便和統籌，對「巨石應用」說不。

更豐富能力

到這裏，有人確定會問，那若是我有依賴第二層邏輯的原子作服務的原子呢，是否支持更高或無限層次的依賴原子呢？固然支持！

下面就是底層實現的設計思路：

設計之初就依據無限層原子依賴服務進行設計的。

設計思路圖左邊，對於組裝原子的執行順序就是，先從最底層自閉環的原子開始注入系統，而後依賴一級的開始組裝注入原子系統，依次類推，最終到更高維度。

整個組裝的裝載設計流程是圖的右邊：

首先第一層是可注入原子，直接注入系統
其次第二級別的組裝原子依賴第一層的原子，在生產系統中進行裝配組裝。
產出可注入系統的原子，注入到原子系統中
更高維度的依次類推，對已注入原子系統的原子可支配使用，依賴原子造成本身的閉環，而後對外提供服務。

注意：組裝原子可以使用extend進行原子調用，可是不會進行through進行透傳所繼承的原子的，由於自己組裝完了你們都在原子系統中。

迭代變動

injection原子注入參數變動

// 老方法
injection({
  atom: [atom1, atom2],
  package: [package1, package2]
})

// 新方法
injection({
  atom: [
    [config, mock],
    [request]
  ],
  package: [test]
})
複製代碼

總結

其實爲request增長mock功能，這個需求能夠將配置和mock數據都放到一個js裏，這樣的話，這個request的就造成了自閉環的最基礎的原子。可是本章節的demo的設計，將mock的數據和配置文件單獨拆開了。

這就是這個解決方案的能力：本解決方案，只是爲邏輯的管理提供了一個解決方案，並不會教你怎麼去抽象你的邏輯。

其次，基於js的設計，脫離了任何前端的框架（vue，react，angular等），你能夠集成到任何框架裏面。後面咱們本身摸索，會提供一個合理的插件。

合理提醒

該解決方案正在連續設計中，還沒產出正式方案，還會有變更，若是你們感興趣能夠本身非核心項目使用。若是你認爲該方案確實值得一試，也可使用，可是開發中必須 鎖版本，這樣爲了防止版本升級影響當前存量的項目。若是你要手動升級版本，可能須要付出升級成本，若是有任何問題或者疑問能夠直接給我發郵件 gerry.zhong@outlook.com，你們一塊兒交流。