逻辑管理：解决方案（二） - 组装原子和原子共存，共建上层输出逻辑

###同步更新 博客园、知乎、知乎专栏

阅读tips

此文章是一个连续探索关于程序中的逻辑的如何管理的系列，在JavaScript中落地实践，理论上思想适用任何语言，建议从头看：

1. 逻辑管理 - 关于前端逻辑管理的设计和实现

概念解释

在新迭代以前，解释下以前博客中所说的一些概念，由于在内部分享的时候，也让不少人去疑惑。

关于原子逻辑概念

以前的理解是抽象到没法再继续分割的程度的叫原子逻辑，在实施以后发现，当你真正细分到那个程度的时候，会带来不少问题：

1. 是否真正须要细分到那么细节？
2. 理想化的实践会不会带来更高的成本？
3. 解决方案的使用者是否更方便？
4. ...

针对这个问题，思考了好久，太理想化的东西，愿景是好的，可是真正落地的时候，会发现有不少的坑须要本身去踩。因此原子逻辑的概念须要进行变动。

过去：将原子拆分到没法拆分的步骤，保证一个方法或者属性只作一件事或者只表明一个属性
如今：内部造成逻辑闭环，或依赖更低维度的逻辑造成闭环，为组装提供逻辑服务能力的称为原子逻辑

关于该开源项目究竟是作什么的？

首先肯定一点，该项目 不是教使用者去怎么抽象咱们项目/业务中的逻辑，由于每一个人的思惟和角度不同，抽象的颗粒度也不一致。该项目只是 作一个解决方案，对逻辑的一个统筹管理，组装生产，以及最后的结果管理。这样就能够对散落在整个链路的逻辑作强制管控，全部的逻辑从这里出发，而后组装，最后提供服务，一层层逻辑的流转链路，清晰明了。

现实项目：接手了不少项目，最大的痛点就是 全部逻辑没有管理而失控，毕竟失控就意味着，它将终究会在「 巨石应用 」的路上越走越近。

组装原子的设计

在上一篇初步的探讨中遗留了一个问题：组装原子如何和原子共存，共建上层输出逻辑？

什么是组装原子？

依赖更低层的原子，组装而成，造成闭环，对外提供原子服务的，称之为组装原子

真实案例

完成简单的功能：前端请求增长mock能力。能够直接clone下demo，安装好依赖后，经过npm run start进行配合阅读

设计图

原子类管理

1. 不依赖外部自闭环的逻辑 ==> config配置、mock数据

2. 依赖自闭环逻辑造成闭环的逻辑 ==> request模块

组装类管理

1. 对外依赖request，组装出测试代码。

代码工程结构

-mockDemo
  |-atom    --原子管理目录
    |-one   --不依赖外部的自闭环原子逻辑
    |-two   --依赖基础自闭环原子造成闭环的原子逻辑
  |-package   --组装逻辑目录
  |-index    --配置注入入口

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')
复制代码

测试结果

整个逻辑的数据流向以下图

这样一层一层的单向数据流的好处概括以下

1. 逻辑数据流动方向能够跟踪，流动单一，追查问题的时候能够更快捷。

2. 每一个逻辑的管理（好比，config、mock、request等）就是对逻辑的切片，在当前的切片里能够作替换、灰度等等。

3. 抽象和概括思惟的加强，如何去抽象，如何去依赖设计，以达到最契合当前项目的架构。

4. 助力逻辑管理更加方便和统筹，对「 巨石应用 」说不。

更丰富能力

到这里，有人确定会问，那若是我有依赖第二层逻辑的原子作服务的原子呢，是否支持更高或无限层次的依赖原子呢？固然支持！

下面就是底层实现的设计思路：

设计之初就依据无限层原子依赖服务进行设计的。

设计思路图左边，对于组装原子的执行顺序就是，先从最底层自闭环的原子开始注入系统，而后依赖一级的开始组装注入原子系统，依次类推，最终到更高维度。

整个组装的装载设计流程是图的右边：

1. 首先第一层是可注入原子，直接注入系统
2. 其次第二级别的组装原子依赖第一层的原子，在生产系统中进行装配组装。
3. 产出可注入系统的原子，注入到原子系统中
4. 更高维度的依次类推，对已注入原子系统的原子可支配使用，依赖原子造成本身的闭环，而后对外提供服务。

注意：组装原子可以使用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，你们一块儿交流。

github

项目地址：github.com/GerryIsWarr…

demo地址：github.com/GerryIsWarr…

点个star，👍一下做者，继续为更美好前端作努力

npm

npm地址：www.npmjs.com/package/@fi…

当前包版本：0.0.7

下期迭代

1. 原子逻辑中相同name处理。
2. 在组装逻辑中，透传更细颗粒度的原子逻辑，而不透传一整个原子的逻辑。
3. Vue插件使用。
4. 完善文档体系和教程

后记

我可能没有那么大的能量去推进前端这个大浪潮的前进，可是我愿意贡献本身微薄的一份力量，作点对前端有价值的东西，让前端变得更加美好，这就是个人小愿望，一直砥砺前行着。

固然，若是有须要，我也能够帮你推荐一些公司的职位，好比：饿了么，阿里，阅文，字节，小红书，B站，拼多多，哈啰，虎扑，美团，携程等等，坐标上海。若有须要，带上你的简历和指望公司职位，发到个人邮箱：gerry.zhong@outlook.com。职位不限技术，各类均可以，我能够帮你去咨询。

毕竟生活不易，特别在外拼的，能帮就帮一把。