Logic management: solutions (a) - on the design and implementation of front-end logic management

Qieru Si test sites

Component-based, can solve a set of reusable functions, we can use the open-source general public components, can also be special for our business scenario, precipitated in line with the business component of their business;

Engineered to address the controllable and normative functions, we can use some open source such as scaffolding vue-cli, create-react-app, etc., or the company's own internal precipitation internal scaffolding solution;

But who is going to solve scattered in the various modules and engineering logic? How to avoid hard-code programming, reduce maintenance and cost of the latter logic, etc., it is also a point to consider.

 

Observation Code

First, from an objective point of view to analyze this Code , review of this code, you can see a lot of problems, such as:

• • Check the configuration parameters and the type of configuration at the beginning of the code accounts for a significant part, if you can pull away to maintain the profile management go?
  • Are tools tools can be reconstructed, a lot of different types of tools polymerization of helpers, whether the latter will continue to grow bloated, can be summarized by classification, management tools and more clarity
  • tools of internal tools, can be split into only one thing and one thing more than something together to complete the way?
  • Too long function, is it possible to split, and enhance readability requirements?
  • Other methods are many ways to rely on their own objects, complex transfer the entire link, pull a launch body.
  • The ability to divide the code is not clear, GM and non-GM not clearly defined
  • External exposure capability of the code is relatively high repetition
  • ......

This was originally written code also conducted a simple classification, a little plain sense of logic management. But we can look at our own true for the production of the company's projects, more than maintenance, collaborative development, business growth, etc., in the end has been completely uncontrollable, not daring to move a logical move, only daring patch, more and more bloated . Here is our internal project for before I make a small piece of analysis, these are real code is almost everyone's, is a sore point of our existence. 

• • Individual time handler, whether detached to the common logic, based on the properties of the prototype chain, will cover the prototype chain pollution and other properties
  • Business interaction design function, whether packaged into a separate function?
  • Enumeration pulled unified management?
  • Request pulled unified management?
  • Conversion data assignment process?
  • Copy assembly complex, abstract to function, improve readability? Reduce the complexity?
  • Multiple logic to determine whether the simplified expression? Decomposition of complex conditions, the merger is consistent behavior?
  • ....

 

The front end of the business to do what?

Based on previous analysis of the code, the accumulation of a lot of problems, indicating that this is really our pain points. Then these pain points in the final analysis is what we do cause? The front end of the business in the end to do something what aspects?

1. 1. Acquiring business data (data acquired under the business rules)
   2. The data processing (subdivided conversion, formatting, and the like check)
   3. Business judgment (for the business scene, what to do at each scene)
   4. Business data submission (recording business rules output data)
   5. Business interactive features (in business rules need to how to do, how to do the function)
   6. Presentations (in business scenarios show a reasonable form of business)
   7. ...... (being only think of these areas, if any omissions please add)

Above, including almost everything in the front-end business, we need to do, but for all of our logic.

 

Deep thinking logic

We need these logical concoction of what we need to accomplish, in fact, observe every small business code, are from the most simple logic rules a bar, step by step transfer to the final result that we need, just as we do Like thinking brain map, a process node is a little logic. Start a service, to the end of a business, it is minimized by each logical points.

so, we can not stand a global point of view of the entire business, can break the flow of each node atom as a minimum, all the business logic, from the smallest atoms are assembled one by one, so that, we will be able to focus more on minimal logic. Any business we do is put together by the atom. So that you can go to hold live from any logical basis, regardless of the complexity and simplicity.

We can also refer, or other back-end in Java language, initially designed to be ideal. They all hope that my world is the real world, are the smallest particles to assemble the world I want to design. So a class on behalf of a class of things, a function on behalf of one thing. No matter how you play above, I can support you to assemble the world you want, any complex thing you have to do. Therefore, this is actually a logical processing, the smallest particles labeled any logic, by stitching, assembly, any business logic to support upper layer.

 

So after, imagine the following scene:

• • Only interested in atomic logic, to enrich atomic logic
  • Business logic, business rules to adapt to any atom on the logic provided by the assembly to output any service code
  • The business rules change, a small change, a direct replacement for a logical node, replace the socket. Changes, reassemble another line of business.
  • The entire data stream clear traceability link
  • ...

 

Ideal design architecture diagram

 

Simple to explore design ideas

Logic atom: base object class manages all implanted atoms

Combinational logic: Inheritance atoms, in combination, the output

External interface: parsing the configuration, call the atomic and portfolio management class, throw production results

 

The idea is as follows:

 

Base class design code

// 原子管理类，管理所有原子逻辑
class Atom {

  /*
  * 注入原子逻辑，以属性的方式管理
  *   objArr： 原子逻辑数组
  * */
  setBasics(objArr) {
    objArr.forEach(x => {
      this[x.name] = x.assembly
    })
  }

  /*
  * 生产组装类所需要的原子
  *   param
  *     useBasics：组装类，所需要继承的原子
  *       支持type： String - 指定一个、Array - 指定多个、无（undefined）- 所有
  *
  *   return
  *     output：生产出的原子逻辑
  * */
  machiningBasics(useBasics) {
    let output = {}
    if (useBasics) {
      if (Array.isArray(useBasics)) {
        useBasics.forEach(x => {
          Object.assign(output, this[x])
        })
      } else {
        Object.assign(output, this[useBasics])
      }
    } else {
      Object.keys(this).forEach(x => {
        Object.assign(output, this[x])
      })
    }
    return output
  }
}

export default Atom

基类，作为最底层的基础模块，管理所有原子，供上层业务逻辑继承和调用，去组装自己的业务逻辑。该类内部抛出2个方法如下：

setBasics

作为对原子逻辑的注入。可以持续去丰富底层的原子逻辑（后期是否支持动态注入，再考虑）；

machiningBasics

提供给组装类继承原子的逻辑，输出所需要的底层基础，供上游拼装

 

组装类设计代码

// 因ES6不支持私有属性，所以将私有属性放到外层

/*
* 生产组装对象，并注入指定作用域
*   param -
*
*   return
*     Temporary：组装对象
*
* */
function makeObject() {
  function Temporary(assembly) {
    for (let key in assembly) {
      this[key] = assembly[key].bind(this)
    }
  }

  return Temporary
}

/*
* 组装中是否透传原子方法
*   param
*     Temporary：组装对象
*     config： 组装的配置
*
*   return
*     output：输出最终逻辑
* */
function isThrough(Temporary, config) {
  // 根据配置，实例化对象
  let temp = new Temporary(config.assembly)
  let output = {}
  for (let key in temp) {
    // 是否开启配置
    if (config.through  === false) {
      // 是否是自身属性
      if (temp.hasOwnProperty(key)) {
        output[key] = temp[key]
      }
    } else {
      output[key] = temp[key]
    }
  }
  return output
}

// 组装类，管理组装和输出。
class Package {

  /*
  * 注入组装配置
  *   param
  *     config：组装配置
  *     prototype：组装所依赖的原子属性
  *
  *   return  生产完成的对象
  * */
  setPackage(config, prototype) {
    let temp = makeObject(config)
    temp.prototype = prototype
    return isThrough(temp, config)
  }

}

export default Package

组装类，通过一系列的原子逻辑组装成一条条所需要的业务逻辑。整体步骤为：生产出组装的对象，通过原型继承装配原子，对外暴露组装结果。就跟工厂一样，生产目标，生产原料，生产产物。组装类对内部抛出一个方法：

setPackage

根据提供的配置文件以及所需继承的原子，组装出一类业务逻辑。

 

index入口设计

import Atom from './atom/index'
import Package from './package/index'

// 实例化原子和组装类
const _atom = new Atom()
const _package = new Package()

// 生产原子缓存
let _globalCache = {}

/*
* 对外暴露，注入配置依赖，生产组装
*   param
*     param： 配置参数
* */
export const injection = function (param) {
  _atom.setBasics(param.atom)

  param.package.forEach(x => {
    let prototype = _atom.machiningBasics(x.extends)
    // 缓存组装
    _globalCache[x.name] = _package.setPackage(x, prototype)
  })
}

/*
* 对外暴露，获取生产完成的组装对象
*   param
*     param：获取的目标
*       type：String - 指定一个、Array - 指定多个、 无（undefined） - 全部
*
*   return
*     output：生产结束的对象
* */
export const getMateriel = function (param) {
  let output = {}
  if (param) {
    if (Array.isArray(param)) {
      return param.forEach(x => {
        output[x] = _globalCache[x]
      })
    } else {
      output = _globalCache[param]
    }
  } else {
    output = _globalCache
  }
  return output
}

对外的入口，主要功能为解析配置，组装配置，输出组装结果供使用3大功能。

injection

标准对外入口，进行逻辑管理的初始化，该方法将所有的原子逻辑注入到原子类里，再通过组装配置，从原子类获取到每个组装对象所需要继承的原子供组装使用，最后将组装好的逻辑全局存到一个全局的缓存里。

getMateriel

对外输出生产完成的组装逻辑，暴露出组装结束的结果，可获取所有组装结果，也可单独或者批量获取结果

 

使用格式规定 

默认注入配置（injection方法）

/*
*  injection方法注入对象的格式
*   atom：     所有的原子逻辑
*   package：  组装原子的逻辑
*/
{
  atom: ['原子逻辑1', '原子逻辑2'],
  package: ['组装逻辑1', '组装逻辑2']
}

 

原子逻辑文件格式

/*
*   该格式为原子逻辑的标准格式
*     name：       原子类的名称
*     assembly：   原子的方法存放的对象
*/
export default {
  name: '原子的名称',
  assembly: {
    // 原子逻辑所对外提供的方法
    sendRequest() {
      // do something
    }
  }
}

 

组装逻辑文件格式

/*
*   该格式为组装逻辑的标准格式
*     name：       组装类的名称
*     extends：    组装类需要继承的原子
*     through：    是否透传原子类内部的信息
*     assembly：   原子的方法存放的对象
*/
export default {
  name: '组装类名称',
  extends: '继承原子',      // 支持字符串（单原子）、无（默认继承所有原子）、数组（指定多个原子）
  assembly: {
    // 组装逻辑对外产出的方法，可直接this.来调用继承原子的方法
    getAtom1Promise() {
      // do something...
    }
  }
}

 

DEMO展示

目录格式

-src

  |-atom                // 存放原子逻辑的地方

  |-package          //  存放组装逻辑的地方

  |-index.js           //  入口文件

 

原子逻辑（atom）

export default {
  name: 'atom1',
  assembly: {
    sendRequest() {
      return new Promise((res, rej) => {
        setTimeout(function () {
          res([1, 2, 3])
        }, 3000)
      })
    }
  }
}

export default {
  name: 'atom2',
  assembly: {
    judgeArray(data) {
      return Array.isArray(data)
    }
  }
}

 

组装逻辑（package）

export default {
  name: 'package1',
  extends: 'atom1',
  assembly: {
    getAtom1Promise() {
      this.sendRequest()
        .then(x => {
          console.warn('使用成功', x)
        })
    }
  }
}

export default {
  name: 'package2',
  through: false,
  assembly: {
    packageLogin() {
      this.sendRequest()
        .then(x => {
          console.warn('判断是否是数组：', this.judgeArray(x))
        })
    }
  }
}

 

入口注入（index）

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

import atom1 from './atom/atom1'
import atom2 from './atom/atom2'
import package1 from './package/package1'
import package2 from './package/package2'

injection({
  atom: [atom1, atom2],
  package: [package1, package2]
})

console.warn('组装成功：', getMateriel())

// 测试package1方法
getMateriel('package1').getAtom1Promise()

// 测试package2方法
getMateriel('package2').packageLogin()

 

测试结果

 

 

npm发布

包名

@fines/factory-js

安装

npm i @fines/factory-js

注明

fines registered as a new organization, there will write some more good things, after all can become better code will be released to the package below (more important package name is no longer available, but the organization can be unlimited)

 

github hosting

address

https://github.com/GerryIsWarrior/factory-js      feel there is a point of reference value can star, it is being used to step inside the pit

Issues

https://github.com/GerryIsWarrior/factory-js/issues

demo Institute Add

https://github.com/GerryIsWarrior/factory-js/tree/master/demo

PS: Direct npm run start   directly run up test

 

postscript

Done before the relevant exploration and logical thinking in the field of management, as follows:

1. 1. Thinking of writing better code controlled
   2. Explore the development and design of complex front-end business

Groping on the basis of previous, more in-depth thinking before the final output of this logic solutions, for your reference, the latter will continue to improve the program.

 

Some say the community, this is not your front-end do not you live, do this doing? After hearing these words, always felt a little awkward.

In my opinion, each of us is an architect, constantly in architecture own code. He kept going the way of the world of perception, self-awareness. We are not perfect, there are good and bad. To discover their pain points, pain points to be analyzed, to think, to find out the root causes of the final, and then go to think about how to solve this pain point, try, explore, failure, initial success, and then continue. So along the way, convinced that eventually harvest. mutual encouragement!

 

 

The second half direction

 

How to assemble atoms and atoms coexist, to build the upper output logic?

Because some general method by atomic logic composed of atoms can be used as the basis to continue to use, and how to inject the next administration as a research subject.