细节齐全的 SOA —— hooks 组件或可尝试-一一网

SOA —— 面向服务架构是一种组件封装方式，本质上是对 功能单元的拆分，这一点与传统组件只拆分视图和内部逻辑（无法高效调用外部状态逻辑）的方式不同

而 React 如果要想实现 SOA，就需要从 Context 这一结构入手，因为控制反转（依赖注入）是实现高效 SOA 的前提

React 的 Context 直接说是依赖注入不严谨，因为依赖注入很多时候是面向对象的概念，而 React 的语境很多都是基于函数式的，这一点其实应该批评 React，一方面放 useRef 出来，搞很重数据驱动，一方面又提倡函数式，这样会给社区的学习生产带来很大的误导，不过矫枉必须过正，教育社区的作用也是很大的

首先，我们要明白一个非常重要的概念 —— 状态逻辑 （stateful logic）

英文原文知道，这个词中，状态逻辑两个词不是并列关系，完整表述应该是 —— “有状态的逻辑”，即状态 + 状态化事件 + 响应式流（effect -> setState -> effect …）

状态管理 -> 状态逻辑管理

我们来看看 React 官方的表述：

截屏2021-06-01 上午10.47.28.png

截屏2021-06-01 上午10.50.32.png

注意，在 Hooks 语境下，不止状态可以方便地进行传递，整个逻辑也可以

那怎么才能让逻辑也畅通无阻地进行传递呢？（不依赖丑陋的高阶组件和本不应该用在此处的render props）

Context 提供了无需层层传递即可进行状态分发的方案，配合其他 hooks api，可以有效解决组件无法高效调用外部状态逻辑的缺陷

Context + useContext

// 声明上下文
const SomeLogicContext = createContext({a:'',b:'',()=>{}})

// 声明服务（共享热插拔逻辑代码）
function SomeLogic(propA,propB){
   const [a,setA] = useState('')
   const [b,setB] = useState('')
   useEffect(()=>{
     setA(propA)
   },[propA])
   useEffect(()=>{
     setB(propB)
   },[propB])
   const setAB = useCallback((_a,_b)=>{
      setA(_a)
      setB(_b)
   },[])
   return {
     a,
     b,
     setAB
   }
}

// 声明Provider
function SomeComponent(){
  // 初始化
  const someLogic = useSomeLogic('','')
  // provide
  return <SomeLogicContext.Provider value={someLogic}>
    /** 子孙组件共享 someLogic **/
  </SomeLogicContext.Provider>
}

// 子孙组件使用
function SomeChild(){
  const someLogic = useContext(SomeLogicContext)
  // ...
}
复制代码

这样，你就不需要再使用复杂丑陋且功能缺失的方案来将逻辑跨组件了，真正实现了高内低耦

然而，这是很基础的部分，讨论远没有真正结束，因为这是函数式SOA方案，并非面向对象中 —— 我拿到实例化对象引用了！我实现了控制反转！我实现了 SOA！—— 这么简单

不变的 Context

Context 的行为和 Props 非常相似，比如返回结果如果是对象的话，会进行 Objectis 比对，保证不变性

表面看上去没什么问题，但是，如果你在注入部分试用了 setAB 函数作为参数（谁会傻到有 useContext 还用 props 传函数？因为社区第三方组件不是用 context 写得，所以你避免不了传 props）

 <SomeLogicContext.Provider value={someLogic}>
    /** 子孙组件共享 someLogic **/
    /** 对不起，虽然你只有无依赖 callback setAB **/
    /** 但是只要 someLogic 返回值有一个变化，你都得重绘vm（重新调用 SomeChild 组件函数） **/
    <SomeChild onChange={setAB}/>
  </SomeLogicContext.Provider>
复制代码

这就是 React 官方所说的 —— 避免向下传递回调

不可能！绝对不可能！既然已经给了状态逻辑复用，不向下传递回调还玩个屁！

React 给的方案，是用 useReducer + dispatch，state 分开 provide，且不说丑陋不丑陋，useReducer 根本就不应该用在这种地方

出现这种问题，其实也是 React 想要给使用者减负，原因很简单，它将 context,props,state 变化，一定会返回新的 jsx 当做 React 组件的默认逻辑

不过应该这样看么？

新版函数式组件，只要 props，context 发生改变，就会重新运行函数，这个逻辑无可厚非，但是相关变量不加控制，直接放置在 jsx 中，并直接返回，是函数式组件的默认行为么？

不是！

既然承认不加 useMemo 或者 effect 新 state ，变更得不到约束，甚至不惰性初始化，性能将会被拖累

为什么会想当然认为 jsx 应该直接返回，子组件 props 的参数应该直接传递呢？

 <SomeLogicContext.Provider value={someLogic}>
    /** 子孙组件共享 someLogic **/
    { useMemo(()=>(<SomeChild onChange={setAB}/>),[setAB])
  </SomeLogicContext.Provider>
复制代码

写在 return 里面的东西，和写在函数体里面的东西，在调度方面，并没有什么区别

所谓不要把 useMemo 当成语义上的保证的意思是，在依赖项改变才进行计算这句话的意思不对，useMemo 只是在 memorzied state 上添加了一个新值，并让这个新值跟随 state 的调度进行调度而已（依赖被传递），至于这个调度到底是不是同步一致的，react 现在也不保证，并不影响你用在调度处理这种地方

也就是说，useMemo 并不是性能优化 api，而是个调度控制 api（没有性能需要你优化，而是 context，props state 改变必刷新这个逻辑有问题）

但是，聪明的朋友们马上反应过来，react 默认组件返回值刷新频率的原因在哪里了

可读性！ —— 是高内低耦了，但是 jsx 不是稀碎了么？

没错，但是出现这个问题的原因是什么？

函数式组件新身份

函数式组件只是提供 jsx 式视图调用接口

换句话说，react 应用中的组件，只是视图，而 hooks 状态逻辑，才是真组件（功能单元），类似这种：

// 在这里进行组装
function ViewComponent(){
    const controlButton = useControlButton()
    const childCompo = useChildCompo()

    return <div>
      {controlButton}
      {childCompo}
      /** 其他纯组件 **/
      <Pure/>
    <div/>
}

// 组件视图也是 hooks
function useControlButton(){
   const [label,setLabel] = useState('button lable')
   return useMemo(()=>(<button>{label}</button>),[label])
}
复制代码