摘要：類組件中的增加學(xué)習(xí)成本，類組件在基于現(xiàn)有工具的優(yōu)化上存在些許問(wèn)題。由于業(yè)務(wù)變動(dòng)，函數(shù)組件不得不改為類組件等等。那么可愛(ài)的各位看官，還不趕緊使用起來(lái)在線示例點(diǎn)我版本基礎(chǔ)入門項(xiàng)目錄像教程

model是需要精心的設(shè)計(jì)和合理的劃分的，這是我們之前開發(fā)大型的redux+react單頁(yè)面應(yīng)用，大家都認(rèn)同的真理，同樣的，在react-control-center+react的開發(fā)里也適用這條黃金規(guī)則，通常，我們?cè)诮拥叫枨螅ㄖ崎_發(fā)計(jì)劃的時(shí)候，會(huì)抽象出很多業(yè)務(wù)相關(guān)的關(guān)鍵詞，這些關(guān)鍵詞慢慢經(jīng)過(guò)進(jìn)一步整理，將成為我們劃分功能或者模塊的有效依據(jù)，這些模塊最終在前端這里會(huì)沉淀為model，每一個(gè)model定義了自己的state、reducer,當(dāng)然如果有需要，還可以為其定義computed、init，通過(guò)精心的目錄組織和規(guī)范的約定，視圖的渲染邏輯和我們書寫的業(yè)務(wù)邏輯被有效的解耦到component里和reducer里，這樣當(dāng)我們需要重構(gòu)UI組件，可以放心的對(duì)其重構(gòu)或者新增一個(gè)組件，復(fù)用相同的state和reducer
參考cc-antd-pro的劃分

|________layouts
|     |________BasicLayout.js
|     |________BasicLayout.less
|     |________BlankLayout.js
|     |________PageHeaderLayout.js
|     |________PageHeaderLayout.less
|     |________UserLayout.js
|     |________UserLayout.less
|________models
|     |________activities.js
|     |________chart.js
|     |________form.js
|     |________global.js
|     |________index.js
|     |________list.js
|     |________login.js
|     |________monitor.js
|     |________profile.js
|     |________project.js
|     |________register.js
|     |________rule.js
|     |________user.js

有一些狀態(tài)，我們開發(fā)的過(guò)程中，發(fā)現(xiàn)和視圖緊密相關(guān)，不同的組件在不同的生命周期階段，都需要使用他們或者感知到他們的變化，例如右上角用戶勾選的主題色，影響左下角一個(gè)抽屜的彈出策略或效果，這些狀態(tài)同樣需要交個(gè)狀態(tài)管理框架集中管理起來(lái)，所以我們也會(huì)這些需求設(shè)計(jì)相應(yīng)的model,這一類和主要業(yè)務(wù)邏輯不想管，但是我們依然需要精心管理起來(lái)的model，我們稱之為視圖型model.

通常，我們已開始精心設(shè)計(jì)好各種model后，開始信心滿滿的進(jìn)入開發(fā)流程，隨著功能迭代越來(lái)越塊，需求變動(dòng)越來(lái)頻繁，我們的model會(huì)不停的調(diào)整或者擴(kuò)展，按照class組件和function組件比例2：8開的原則，我們總是想抽出更多的function組件，class組件負(fù)責(zé)和和model打通，然后從model里拿到的數(shù)據(jù)層層派發(fā)它的所以孩子function組件里，但是function組件通常都不是只負(fù)責(zé)展示，還是有不少function組件需要修改model的state,所以我們?cè)?b>ant-design-pro里或者別的地方，依然會(huì)看到不少類似代碼

@connect(state => ({
  register: state.register,
}))
class Foo extends Component {
    render(){
        return (
            
        );
    }
}

const MyStatelessFoo = ({dispatch}){
    return 
whaterver
}

如果有function組件Foo1、Foo2、Foo3,Foo1嵌套了Foo2,Foo2嵌套了Foo3，看起來(lái)要一層一層傳遞下去了。
同時(shí)視圖組件調(diào)整的時(shí)間占比會(huì)遠(yuǎn)大于reducer函數(shù)的書寫，我們有時(shí)候?yàn)榱四莻€(gè)某個(gè)model的state,不停的傳遞下去或者慢慢的將某些比較重的function組件又提升為class組件

這里復(fù)制一段facebook引出hooks要解決的問(wèn)題所在之處

難以重用和共享組件中的與狀態(tài)相關(guān)的邏輯

邏輯復(fù)雜的組件難以開發(fā)與維護(hù)，當(dāng)我們的組件需要處理多個(gè)互不相關(guān)的 local state * 時(shí)，每個(gè)生命周期函數(shù)中可能會(huì)包含著各種互不相關(guān)的邏輯在里面。

類組件中的this增加學(xué)習(xí)成本，類組件在基于現(xiàn)有工具的優(yōu)化上存在些許問(wèn)題。

由于業(yè)務(wù)變動(dòng)，函數(shù)組件不得不改為類組件等等。

可是如果我們的function組件如果是需要共享或者修改model的state呢，有什么更優(yōu)雅的辦法解決嗎？

一個(gè)典型的CcFragment使用方式如下

import {CcFragment} from "react-control-center";

//在你的普通的react組件或者cc組件里，都可以寫如下代碼
  render() {
    

      another jsx content
      

      
        {
          ({ propState, setState, dispatch, emit, effect, xeffect, lazyEffect, lazyXeffect }) => (
            
 setState("foo", { name: "cool, I can change foo module name" })}>
              {/* 以上方法，你可以像在cc類組件一樣的使用它們，沒(méi)有區(qū)別 */}
              {propState.foo.name}
              {propState.bar.a}
              {propState.bar.alias_b}
            
          )
        }
      
    
  }

上面代碼里，CcFragment標(biāo)記一個(gè)ccKey，connect

cc默認(rèn)是會(huì)為所有CcFragment自動(dòng)生成ccKey的，但是我們推薦你書寫一個(gè)有意義的ccKey，因?yàn)?b>CcFragment允許無(wú)狀態(tài)組件直接使用setState, dispatch, emit, effect, xeffect, lazyEffect, lazyXeffect方法去修改狀態(tài)或者發(fā)起通知，這些函數(shù)的使用體驗(yàn)是和cc class一摸一樣，加上ccKey,你可以在你的中間件函數(shù)里看到某一次的狀態(tài)變化是由哪一個(gè)ccKey觸發(fā)的，這樣未來(lái)你可以在還在計(jì)劃開發(fā)中的cc-dev-tool里查看具體的狀態(tài)變遷歷史，當(dāng)然目前你需要查看狀態(tài)變化的話，可以寫一個(gè)簡(jiǎn)答的中間件函數(shù)來(lái)log

function myMiddleware(params, next) {
  //params 里你可以看到本次狀態(tài)變化提交的狀態(tài)是什么，由什么方法觸發(fā)，由那個(gè)ccKey的引用觸發(fā)等
  console.log("myMiddleware", params);
  next();
}

cc.startup({
  //...
  middlewares: [myMiddleware]
});

connect和cc.register、cc.connect一樣，表示該CcFragment關(guān)注那些模塊，哪些值的變化，上述示例的效果會(huì)是

1 只要bar模塊的a或者b變化了，都會(huì)觸發(fā)該CcFragment的渲染  
2 只要foo模塊的任意key變化了，都會(huì)觸發(fā)該CcFragment的渲染  
3 點(diǎn)擊了div,會(huì)去修改foo模塊的name值，關(guān)注foo模塊name值變化的所有cc組件或者CcFragment組件都會(huì)觸發(fā)渲染

所以CcFragment解決了用戶在無(wú)狀態(tài)組件里共享了model數(shù)據(jù)的問(wèn)題，你寫的無(wú)狀態(tài)組件很容易和cc store打通，而無(wú)需在考慮抽取為cc class組件，CcFragment本質(zhì)上和hooks不存在沖突管理，也和現(xiàn)有cc class不沖突，只是作為cc世界里更重要的補(bǔ)充，讓你可以無(wú)損的使用現(xiàn)有的function組件。
注意一點(diǎn)哦，CcFragment本身是不會(huì)因?yàn)楦附M件的更新而被更新的哦，僅僅受控制于connect參數(shù)觀察的參數(shù)是否發(fā)生變化，所以它的渲染依然是高效的。

在線示例點(diǎn)我

cc版本ant-design-pro

基礎(chǔ)入門項(xiàng)目

runjs錄像教程