[[423277]]

自React 16.8支持hook以來，RN也在0.59版本支持了hook，而且官方給出的組件實例也分為了class和hook兩個版本，可以遇見hook是未來的趨勢。恰巧最近重構RN項目，把最近遇到的問題和思考記錄一下。

今天是總結課。

重構

重構，我想這個詞可能沒有多少人愿意做，在業務迭代頻繁的今天，重構意味著資源的消耗，而且承擔著未知的風險，那么為什么還要重構?

主要有以下思考：

• 代碼沉郁，不敢刪除舊代碼，舊有的代碼邏輯不熟，關聯關系不清，隨著業務的迭代，代碼越來越多。
• 模塊化不清晰，文件混亂。
• 規范不統一，注釋不明確，代碼雜亂。文件查找困難。
• 工程化不完善，請求不統一，如遇到接口參數變更，需要修改多處。
• 組件化不完善，公共組件不統一。

hook化

hook化一個很重要的就是class邏輯的復用，比如：

// class 
this.setState({ 
    count:0 
},()=>{ 
    // 修改數據成功之后 處理的邏輯 
}) 
 
// hook 
useEffect(()=>{ 
    // 監控count值的變更 處理邏輯 
},[count]) 

如果我們需要監控的值很多，是否需要寫很多useEffect呢?這里會用到另一個概念，細粒度組件。寫hook寫多了，會把一些需要處理的業務組件都抽離出來，每個組件只管自己的狀態。這樣就會極大減少了父組件的業務堆積和state堆積。

組件多了就會涉及到組件傳值，這里有三種場景：

• context包裹子組件
• memo + context + reducer 組件傳值
• ref + useImperativeHandle + forwardRef 暴露狀態給父組件
• props 組件傳值

props傳值，通過標簽屬性傳遞。

// props 通過標簽傳值 
<CenterMenu style={style} list={list}  /> 
 
//  
export default CenterMenu(props){ 
    const { style, list } = props; 
    //. ... 
} 

context包裹的話，就會把所有狀態都放在了父組件，就會造成context很臃腫。

<PerfectInfoContext.Provider 
    value={{ 
        serviceBill, 
        patientInfo, 
        batchList, 
        navigation, 
        ...params 
}}> 
    // ...View 
    <Footer  /> 
</PerfectInfoContext.Provider> 
 
// 
const Footer = () => { 
    const  data  =  useContext(PerfectInfoContext); 
    // ... 
} 
export default Footer;