鍍金池/ 問答/HTML/ react生命周期的一些疑問

react生命周期的一些疑問

1.公共數(shù)據(jù)，都是通過redux放在store里面的。具體是在/dashboard 組件 的componentDidMount()中通過異步action去改變store，比如reducer結(jié)構(gòu)是user:{id:0}

2.在父組件下的子頁面，比如/dashboard/test 組件下。有一個(gè)getList的方法，getList(this.props.user.id)

3.當(dāng)刷新 /dashboard/test的時(shí)候。會(huì)有兩次請求1.getUser 2.getList.如果這個(gè)時(shí)候id還沒有寫入store的話。getList就會(huì)報(bào)錯(cuò)。

4.目前的方案:

componentWillReciveProps(nextProps){
    if(this.props.user.id!=nextProps.user.id){
        getList(nextProps.user.id)
    }
}

這樣有個(gè)問題，就是如果 已經(jīng)拿到了userId，在兩個(gè)子頁面切換的時(shí)候 也不會(huì)觸發(fā)componentWillReciveProps。
這樣就不會(huì)執(zhí)行g(shù)etList

還有沒有好的解決方案啊？

============補(bǔ)充內(nèi)容===========
可能是我沒表述清楚。
1.父頁面

componentDidMount(){
    this.props.action.getUser()//異步拿到userId放入store
}

2.子頁面1

componentDidMount(){
    this.getXXList(userId)//獲取某個(gè)xx list需要userId
}

3.子頁面2

componentDidMount(){
    this.getYYList(userId)//獲取某個(gè)yy list需要userId
}

場景:刷新子頁面1

現(xiàn)象:執(zhí)行this.getXXList(userId) ，this.props.action.getUser()
有可能userId還沒拿到，就執(zhí)行了getXXList

回答
編輯回答
練命

一個(gè)原則：通用數(shù)據(jù)沒回來之前，我的業(yè)務(wù)組件壓根就不渲染。比如，用戶數(shù)據(jù)沒回來之前我可以一直顯示Loading。等用戶數(shù)據(jù)回來之后再正常走流程（解決了你的依賴問題）

什么時(shí)候獲取用戶數(shù)據(jù)？

建議在最頂層組件去做（如果一定要在componentDidMount中獲取的話），頂層組件在數(shù)據(jù)沒回來之前一直Loading（或者你喜歡的頁面），數(shù)據(jù)回來之后正常渲染。

回到你的需求來說。

就是用戶數(shù)組沒回來之前，你的/dashboard/test是不會(huì)進(jìn)行渲染的（可以簡單的理解為返回了null），然后具體到子組件，一般也是在componentDidMount的時(shí)候進(jìn)行數(shù)據(jù)獲取（不會(huì)存在你的那個(gè)userid判斷），而恰恰當(dāng)子組件進(jìn)行切換的時(shí)候，你應(yīng)該在componentWillReceiveProps中判斷子頁面的id（不同則進(jìn)行l(wèi)ist數(shù)據(jù)獲取。

2017年1月7日 08:35
編輯回答
逗婦乳

現(xiàn)在的場景是 userList 是依賴于 userId 請求的，而且 user-id 也要共享，這樣就不好在 action 處做邏輯。

其實(shí)我更納悶的是，為什么有 getUserId 的存在。假如它是全局的用戶權(quán)限，必然是由登錄統(tǒng)一處理的。如果它是通過一個(gè)用戶列表點(diǎn)進(jìn)來的，那 user-id 是從 router 就可以獲取的。感覺不存在異步的情況。

回到這種場景... 一種是在頁面渲染的時(shí)候做限制，connect 的組件依賴于 user-id，獲取到 re-render。可以做判斷，存在 id 才渲染組件。
另一種就是 componentDidMount 和 componentWillReciveProps 結(jié)合處理，像樓上的做法那樣，didMount 判斷獲取，CWRP 再判斷處理 。不過個(gè)人不推薦這種，通常這種是因?yàn)樵O(shè)計(jì)的不合理，用來填坑的。不過要是為了快速解決問題，未嘗不可。

2017年8月13日 03:48
編輯回答
挽青絲

這個(gè)要看你的組件設(shè)計(jì)吧；userId影響組件的方法getList,那么具體在組件渲染上有什么影響？我理解的是你的組建需要一個(gè)userId的傳入，然后異步的獲取對應(yīng)id的數(shù)據(jù)getList(id);然后這個(gè)是通用組建，很多子頁面都在使用，我不理解的是子頁面的切換為什么id不會(huì)變化，而且更合理的方式不應(yīng)該是在didmount來通過porps里面的id來獲取list數(shù)據(jù)嗎？切換頁面的話就刪除組件，重新構(gòu)建一個(gè)新的組件；可能是我還沒有完全理解你的場景。

2017年6月22日 07:43
編輯回答
艷骨
componentDidMount(){
  if (this.props.user.id)  this.getList(userId)
}
componentWillReciveProps(nextProps){
    if(this.props.user.id!=nextProps.user.id){
        this.getList(nextProps.user.id)
    }
}
2017年12月21日 14:34