摘要：類組件中的增加學習成本，類組件在基于現有工具的優化上存在些許問題。由于業務變動，函數組件不得不改為類組件等等。那么可愛的各位看官，還不趕緊使用起來在線示例點我版本基礎入門項目錄像教程

model是需要精心的設計和合理的劃分的，這是我們之前開發大型的redux+react單頁面應用，大家都認同的真理，同樣的，在react-control-center+react的開發里也適用這條黃金規則，通常，我們在接到需求，定制開發計劃的時候，會抽象出很多業務相關的關鍵詞，這些關鍵詞慢慢經過進一步整理，將成為我們劃分功能或者模塊的有效依據，這些模塊最終在前端這里會沉淀為model，每一個model定義了自己的state、reducer,當然如果有需要，還可以為其定義computed、init，通過精心的目錄組織和規范的約定，視圖的渲染邏輯和我們書寫的業務邏輯被有效的解耦到component里和reducer里，這樣當我們需要重構UI組件，可以放心的對其重構或者新增一個組件，復用相同的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

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

通常，我們已開始精心設計好各種model后，開始信心滿滿的進入開發流程，隨著功能迭代越來越塊，需求變動越來頻繁，我們的model會不停的調整或者擴展，按照class組件和function組件比例2：8開的原則，我們總是想抽出更多的function組件，class組件負責和和model打通，然后從model里拿到的數據層層派發它的所以孩子function組件里，但是function組件通常都不是只負責展示，還是有不少function組件需要修改model的state,所以我們在ant-design-pro里或者別的地方，依然會看到不少類似代碼

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

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

如果有function組件Foo1、Foo2、Foo3,Foo1嵌套了Foo2,Foo2嵌套了Foo3，看起來要一層一層傳遞下去了。
同時視圖組件調整的時間占比會遠大于reducer函數的書寫，我們有時候為了那個某個model的state,不停的傳遞下去或者慢慢的將某些比較重的function組件又提升為class組件

這里復制一段facebook引出hooks要解決的問題所在之處

難以重用和共享組件中的與狀態相關的邏輯

邏輯復雜的組件難以開發與維護，當我們的組件需要處理多個互不相關的 local state * 時，每個生命周期函數中可能會包含著各種互不相關的邏輯在里面。

類組件中的this增加學習成本，類組件在基于現有工具的優化上存在些許問題。

由于業務變動，函數組件不得不改為類組件等等。

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

一個典型的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類組件一樣的使用它們，沒有區別 */}
              {propState.foo.name}
              {propState.bar.a}
              {propState.bar.alias_b}
            
          )
        }
      
    
  }

上面代碼里，CcFragment標記一個ccKey，connect

cc默認是會為所有CcFragment自動生成ccKey的，但是我們推薦你書寫一個有意義的ccKey，因為CcFragment允許無狀態組件直接使用setState, dispatch, emit, effect, xeffect, lazyEffect, lazyXeffect方法去修改狀態或者發起通知，這些函數的使用體驗是和cc class一摸一樣，加上ccKey,你可以在你的中間件函數里看到某一次的狀態變化是由哪一個ccKey觸發的，這樣未來你可以在還在計劃開發中的cc-dev-tool里查看具體的狀態變遷歷史，當然目前你需要查看狀態變化的話，可以寫一個簡答的中間件函數來log

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

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

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

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

所以CcFragment解決了用戶在無狀態組件里共享了model數據的問題，你寫的無狀態組件很容易和cc store打通，而無需在考慮抽取為cc class組件，CcFragment本質上和hooks不存在沖突管理，也和現有cc class不沖突，只是作為cc世界里更重要的補充，讓你可以無損的使用現有的function組件。
注意一點哦，CcFragment本身是不會因為父組件的更新而被更新的哦，僅僅受控制于connect參數觀察的參數是否發生變化，所以它的渲染依然是高效的。

在線示例點我

cc版本ant-design-pro

基礎入門項目

runjs錄像教程