1. 父組件 -> 前幾層子組件： props

2. 父組件 -> 非常深入的子組件(比如從最頂層到第5層以后): context
這種情況幾乎很少見，除非寫框架或者工具，最好是只用props，清晰明了

3. 子組件 -> 父組件：callback

4. 子組件時間： 嚴格意義上不存在這種情況，如果出現(xiàn)這樣的需求，說明你的寫法是錯誤的，
數(shù)據(jù)的流向始終都應該是從頂至下。例如root -> (A,B,C) 所以A組件改變，需要讓B改變時，A調(diào)用root以props傳來的callback從而導致root的state發(fā)生變化，這樣B就能得到更新

5.

當APP復雜的可能特殊情況：在使用pureRenderMixin來提升渲染速度的時候，非常里層的子組件需要一些參數(shù)來計算顯示的值，但是你又不需要
當這個值改變的時候重新渲染這個組件而且也不想用context的時候, 在Root中定義this.getAllState= () =>
this.state， 然后將這個getAllState作為props傳遞給子組件； 這種情況很少出現(xiàn)，慎用

6.使用某種Flux，讓局部組件鏈接一個自己的store，同時接受來自父組件的各種callback props， 通過這些callback實現(xiàn) 小組件的store改變時，通知父組件

在一個實際的APP中的實際情況是如何設(shè)計store和props的呢？
其實重點，我認為是store和store之間是如何交流數(shù)據(jù)的。
這里我斗膽地拿我在家寫的一個編輯器來做一些分析：編輯器端Flommox, 播放器向redux遷移中
整個編輯器網(wǎng)站分成了不同的頁面，每個頁面(例如/course:id, /editor/:id, /quizs)對應一個Action分組+一個Store， 有的復雜頁面可能需要很多歌store整個編輯器網(wǎng)站分成了不同的頁面，每個頁面(例如/course:id, /editor/:id, /quizs)對應一個Action分組+一個Store， 有的復雜頁面可能需要很多歌store