这个话题很难写。
然则反过来讲，爱因斯坦有句名言：假如你不能把一个问题向一个六岁孩子诠释清楚，那末你不真的邃晓它。
所以诠释清楚一个问题的症结，不是去扩大化，而是相反，最小化。
Let’s begin.
组件
组件不是一个很清楚的编程观点。UML里的组件图基础上就是一个图示，远不能和具有数学完整性的State Diagram比拟，也不能和静态构造的Class Diagram和时序交互的Sequence Diagram比拟。但人人平常照样会画一个出来，便于顺序员明白体系的运转时构造，或许代码构造。
你很轻易在Google里搜刮到一些Component Diagram的图例，所以这里不贴图了。你在组件图上可以看到有如许一些观点是重要的：
port，它指的是包含一组相干函数的接口，一个interface或许一个protocol；
user和provider，谁供应port和谁运用port；
这两个观点都不须要很庞杂的论述，直觉的明白没问题；
但问题是他们定义得迥殊粗，接口怎样完成的？是function call？rpc？message passing？event？没说，事实上是都行。
罕见的Component Diagram画的平常是run-time的instance，black box逻辑，强调的是instance之间的依靠关联。
另一种关于组件的罕见说法，是组件是为了重用。这把问题聊到了另一个空间去了。重用是静态观点，它指的是代码里的一个模块，类、构造等等，而不是指run-time实例。
然则这两种说法不抵牾。由于中心的问题，不管运转时照样静态代码，组件起首强调的是黑盒头脑，这点不是问题，封装是开辟者熟习的逻辑；然则组件必需集成为体系，不管在静态代码层面照样运转时，组件之间都有依靠关联，在项目具有一定范围时这特别重要。
在静态代码层面，任何言语都有库和源码模块话机制，include，import，require等语法症结字或函数建立了这类依靠关联；在运转时，组件（或对象实例）之间可以有动态发生的绑定关联；A对象要具有B的援用，才运用B的要领；或许要下降耦合，采纳视察者情势，音讯总线或音讯路由，Pub/Sub，等等。相对而言，后者更加重要一些，前者你总能通太过拆模块防止轮回，静态依靠关联总归是比较清楚的，它定了就定了，不会运转时发生变化。
所以这篇文章重要谈运转时组件依靠关联的处置惩罚，特指在一个运用以内，不是微效劳或许多个效劳器构成的分布式体系。
React
可以可以不必一上来就谈React，然则如许做最简朴。
React的基础代码单位称为React Component；它声称是View Component，但也可以是纯state的Component，在render要领里render其他view component即可；有履历的React开辟者晓得这被社区称为Container Component。
假如从Component的角度看，React的Component有一个异常迥殊的设想：Component之间只需一种通信机制！就是经由历程Props通报对象或函数，准绳上Component之间是不会经由历程援用相互挪用要领以至发送音讯的。换句话说，统统Component都是匿名的。开辟者不应在运转时查找某个Component实例接见其数据或要领，挪用其要领的只需React框架。
从这个意义上说，React象一个Inversion of Control（IOC）情势，统统有态组件都插在React框架之上，他们可以在willReceiveProps或许render要领被挪用时取得通报进来的数据或要领，他们也可以经由历程挪用setState要领触发一次更新，但这险些就是悉数了。
React的官方开辟者供应了一套叫做flux的数据流体式格局，须要耐久化（生命周期比视图长）的状况存入store，社区也有许多改进的事变，包含盛行的redux，mobx等等；然则实质上说，react自身具有完整的态处置惩罚才能，只需把两个有相干性的组件的关联状况放到他们的配合先人即可；只是如许做，假如没有特别的处置惩罚的化并不天真，在设想变更时大批代码要修正，还不如运用redux等框架来得轻易；anyway，这一点不是我们这篇文章要议论的主题，它指的是静态代码层面的模块化问题，我找时刻写文章专述。我们回到React组件是怎样组合和互动这个话题上。
我们从新强调一下React组件的匿名问题。对一个组件而言，它要能事变，固然须要和外部组件互动，然则React组件在这里做了一个极致的设想：
统统依靠性都是注入的；注入的依靠性来自哪一个外部组件，组件内部一窍不通。
依靠性注入（Dependency Injection）一词，对熟习可测试性（tesability）的开辟者来讲不生疏，但大多数状况下这停留在测试范畴，很少影响设想。绝大多数运用在顶层都有一些相似全局变量的模块，也就是组件图中表达的那些；运用这些模块的其他模块都能用全局的name找到它们，找到就可以运用了。然则在React里，NO! 纵然在顶层，每一个组件的外部依靠也都是注入的。
所以你看到React的组件模子实际上只包含三个元素：
父组件向子组件通报的prop是对象或值
父组件向子组件通报的prop是要领（bound）
父子组件们用一个tree示意，是单向的通报数据或要领的（即层层注入）
视察者与资本建模
我们先说第一个要素：父组件向子组件传值。实质上，它是子组件对父组件或父组件可视察的某个资本状况的一个视察。
从语法上来讲，它比写Observer Pattern要来得轻易，由于子组件没有Subscribe的累赘，是反过来做的，父组件把子组件的依靠性（须要视察的对象）塞进来。
由于React是function programming作风，如许写更轻易；不轻易的处所是视察变化的逻辑是在willReceiveProps里，须要自身比较新版本和副本的辨别，假如有差异，挪用setState要领更新自身。
然则这类视察能完成统统须要的视察吗？比方SomethingStarted，SomethingResumed，SomethingOpened？
确切可以碰到一些辣手的状况难以简朴用值的变化来表述一种变化，然则我们反过来想这个问题，数据库是用CRUD完成的，Restful API设想采纳资本建模也只需有限的verb，他们都事变的很好；事变的好的原因是他们都是用资本而不是行动建模的，假如确切须要为行动建模，我们也可以运用状况机，对单一模块而言，在种种粒度上状况机都是很好的建模体式格局；在状况机模子下，状况就一定可以用离散值来示意，比方运转状况可以是started, stopped, resumed, failed，等等。
如许的建模体式格局是不是比自身发现许多message范例更加有用呢？个人意见是的，这是一种远好过用行动语义定义事宜的体式格局。不管crud照样restful都有极为普遍的实践，可以被认为是被证明可行的体式格局。
从这些意义上说，React的组件建模体式格局具有相似crud或http verb的一致笼统，是防止涌现大批顺序员自身发现杂沓语义的好办法。
Bound要领通报
父组件向子组件通报的Bound要领，应当看做是父组件向子组件供应的一种触发状况变化的代办。比方你去旅店，你叫效劳生来开门，这是一种相似function call或许message passing的机制，然则效劳生也可以给你一张卡你自身去开门，这就是一种代办；和视察资本一样，由于运用了一致的Prop机制，在组件内部看，这类代办也是匿名的，组件并不晓得究竟是谁在供应这项功用，它只是在须要的时刻运用罢了。
这件事变是前端特有的，受限制于HTML的构造。
许多功用组件都不只是基于视察逻辑事变，他们还会须要供应功用性效劳，功用性效劳的进口从那里触发，看运用和体系构造而定，它可以来自用户操纵，可以来自操纵体系，也可以来自API请求，背面我们还会细致说这个问题。
Tree
事实上绝大多数App，其组件都是可以用一个tree来示意的，只不过在项目范围不大的时刻，人人更喜好把顶层组件就堆在一起相互援用，如许变化的时刻最天真。
但React组件的Composition构造更相符组件设想的准绳：组件和组件可以轻易的组合起来完成更大的组件，而且最重要的，它仍然是只需React定义的只需Prop通报的组件。一种自相似性。或许叫做Composability。
组件更新
简朴说一下React组件的更新历程；假如一个组件视察到变化，或许被子组件挪用了要领，须要更新状况，这时候假如变化只影响到自身和某些子组件，它只需直接setState触发变化即可，React回挪用它的render要领触发一连串的变化，更新是自上至下的，所以比较轻易做到更新收敛；假如变化会影响到组件树上某个非子组件的变化，那末应当经由历程上面通报下来的Bound要领触发更高层的组件先做状况迁徙。这个设想会致使在状况设想上涌现mediator情势，anyway，这也是罕见情势和基础功了。
这里须要强调的是，理论上这类更新是同步的，虽然React由于效力问题做了其他的事变，它的VDOM衬着实际上是有Batch和异步的，细节不说了。
杂沓的组件通信
那末假如我们不说前端，假如写后端，或许写体系运用，用React的这个情势构建悉数组件树可行吗？答案是不，也不必要。
这一节的问题叫做杂沓的组件通信，我们来细致掰扯一下细节，由于组件模子虽然很常说然则对通信历程没有商定。
第一个上台的是function call。
function call不管是同步的照样异步的，它没有辨别（1）它是不是转变了被挪用对象的状况（2）它是不是须要返回值。假如它不须要返回值，它就和emit了一个event没什么离别。假如它须要一个返回值，那末挪用者是user角色，被挪用者是provider角色，假如被挪用者的状况发生了变化，这相当于crud里的cud，不然是read。
明白了对function call的分类体式格局，那末event和message passing也就好明白了。message和function call一样是含糊其词的。在Sequence Diagram里，有去必定有回的message被称为synchronous message，有去无回的叫做asynchrnous；然则我们防止这个术语，和我们在JS里说的不是一回事。然则这个分类体式格局是对的。
比拟之下只需event很地道，它就是有去无回的。
OK，你看我们的分类要领异常简朴，就是单向的或许有去有回的。然则内涵的故事不简朴。
State & IO
单向的event，它有可以trigger一个模子内的state或许resource变化（背面统称为State）。
双向的通信，是一种许诺，纵然是失利或毛病也要有返回，我们称之为IO。注重这个定义是我自身发现的，它仅仅示意双向通信。
双向通信岂非就不会trigger模子内的state变化吗？这固然是异常可以的。然则问题的症结点就在这里：
关于一个供应IO效劳也可以由于IO转变其内部状况的模块，你是不是在代码层面上把IO和State分离了呢？
我们专注于说JavaScript的事宜模子；假如你把模块写成状况机，模块接收到的event会race吗？固然不会。IO呢？极可以。并发的实质就是IO的并发，event在单线程的事宜模子下没有并发的观点。
那末这里就有一个迥殊简朴的建模体式格局，你可以脑补一个鸡蛋三明治。
三明治双方的面包（实在只需一边有面包的逻辑也是一样的），可以看做一个是向外供应的IO效劳，另一个是自身须要运用的IO效劳；而中心的鸡蛋，是这个模块的State，悉数State，状况机。
进来的IO假如有资本争论，可以列队；出去的IO假如有返回效果，返回效果要看成一个Event来处置惩罚。假如某些Event致使当前正在效劳或许列队的IO请求失利，进来的IO请求行列清空，悉数返回毛病；假如对象涌现生命周期完毕，其发出的和效劳的IO都要清空，返回失利或许abort。你看这超等轻易，就是callback行列和handle行列罢了。
我们把中心这层鸡蛋，称为该模块的模子（model），它封装了共享资本，完成了内部和外部状况。
在这个模子上前端和后端有无辨别呢？照样有的，虽然二者都可以看做在对外供应效劳，一个是效劳机械另一个是效劳人。后端的效劳在对外供应效劳的那层面包上，前端呢，前端都是Event进来的。
级联
在级联这个问题上，React的组件模子显现出了它的简朴笼统的威力。假如我们可以把统统模块的鸡蛋部份，象React组件那样级联起来：
React的框架的render历程要自身手写，而且也不大实际搞成functional作风的，只需遵照其自上至下的更新逻辑即可。
React的依靠性全注入的组件情势是异常诱人的，然则在设想变更时要修正mediator在组件树上的所在位置也有些恼人。这里会有一些比较tricky的写法，然则好音讯是对大多数运用而言，实在粗粒度的组件数目还没有一个React写的网页里的组件数目多，所以这件事变也不见得要做到极致去，组件数目不多的时刻Pub/Sub事变的也很好。然则关于明白的Leaf Node组件，如许写是引荐的。
同步更新。能悉数组件同步更新鸡蛋层是异常值得寻求的目标。由于它让你的模子具有一个全局的显式状况设想，包含组件相干的数据完整性定义；假如到处是异步状况更新，这个设想自身就有贫苦，其逻辑完整性不轻易磨练，状况机很轻易依据State/Event组合排查设想完整性和合理性，而同步更新是祛除态空间爆炸的利器，不然状况之间要排列组合了。
Event Model
JavaScript是Event Model。Event Model编程的中心就是用状况建模，状况同步更新轻易保证数据完整性。建模的最先是看有那些共享资本须要封装，把组件一个一个写出来，然后组合起来。
历程在这里是二等国民，它重要致力于上面说的面包层的IO处置惩罚。从这个意义上说，callback照样promise照样async基础不是重点，没有什么值得争论的，哪一个合实用哪一个。在状况建模之下，IO历程都被碎片化了，试图用远程奔袭的体式格局串连大批IO操纵很难保证设想正确性，光写出来能跑频频胜利测试的代码是没意义的，从这个意义上说我不赞同那些伪线程框架。
事件锁的问题不是这篇议论的重点。事宜模子下用状况机和IO列队处理争论是第一要领，90%以上用这个要领；剩下10%是用opportunistic lock的体式格局一次性commit多个数据更新状况，这个也很轻易，但须要注重读入的数据是只管同步的（偶然这没法保证，但应当去detect不法组合和重试）。
抱负的事宜模子应当是盘算不消耗时刻的；实际上这固然不可以。所以主历程的重要目标是保护全局状况层，即统统的鸡蛋；文件和收集IO操纵Node大多做得很好，须要算力的使命要用Cluster/Worker了，这是Node的短板，只是请求不高的状况下可用。
假如你的后端或许体系运用是异常stateful的，包含文件耐久化的资本，node是很好的挑选；假如只是对称的无态逻辑，资本都在数据库里，node没什么意义；假如算力请求高，数据集也大，不适合在历程间抛来抛去，万万别用node，go/java/c++都是好得多的挑选。
Rx
我基础没有Rx的开辟履历，只是看了半本书。
上面说的悉数笔墨，都可以看做是基于事宜模子的reactive编程；然则rx框架是另一个故事，它没有事宜模子假定，有许多言语完成，而且它斟酌的问题不是一个运用级的，是分布式体系级的。
但rx是不是是一个好的挑选呢？比方说只用于数据层？
有可以。然则它用于组件层的话，它有几个问题：
1，它没商定单向，这个只能自身来；
2，它须要显式视察，即subscribe，个人认为这不如React的注入机制，后者真正让组件象乐高积木一样轻易组合的，没有外部需求的组件才是真正的组件，才可以随便拆装运用；
所以我以为它写在组件内视察被注入进来的状况变化可以更适宜，固然用于麋集的异步IO更新的数据集是一定没问题的。
Final
把症结点陈设一下，该说的前面都说过了。
依靠性注入的组件
状况机和资本建模
状况或资本变化即事宜，不要分外发现语义了
明白State和IO的辨别
全局级联的状况更新，同步！
～～～～～～～～～～～～～～～～
题外话：
最近在重构一个中等范围项目，在组件模子上想了许多；然则React的原作者们并没有迥殊的以为他们的设想是unusual的。Jordan Walke的大部份视频都在谈react怎样运用。
但在我来看，或许从后端或许体系顺序的角度看，react的组件模子在运用上真正相符了组件的定义：无外部依靠，这一点比node里的module们require来require去高妙太多。
