<!-- Wrapper.Component.html --> <div> hello <ng-content></ng-content> </div>
假設(shè)我們有一個上述的組件，然后向下面這樣調(diào)用：
<wrapper> <span> World </span> </wrapper>
那么最終的渲染結(jié)果將會是這樣的：
<div> hello <span> World </span> </div>
看起來就是發(fā)生了很簡單的替換，但是如果在 Wrapper 中出現(xiàn)了多個 <ng-content> 會出現(xiàn)多個 <span> World </span> 嗎？答案是不會的。<ng-content> 的本質(zhì)只是移動元素，并不會去自動的創(chuàng)建傳入的模板，所以就算用 ngFor 套住 <ng-content> 也不會出現(xiàn)很多個 <span> World </span>。如果傳入的是自定義的組件，這些組件也只會被實(shí)例化一次。

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

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

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

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

5.

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

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

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