本文用于论述StateUp情势的算法和数学背景，以及诠释了它为何是React里最圆满的状况治理完成。
关于StateUp情势请参阅：https://segmentfault.com/a/11…
P-State, V-State
假如要做组件的态封装，从组件内部看，存在两种差别的state：
p-state, or persistent state, 是生命周期凌驾组件自身的state，纵然组件从DOM上烧毁，这些state依然须要在组件外部耐久化；
v-state, or volatile state, 是生命周期和组件一样的state，假如组件从DOM上烧毁，这些state一同烧毁；
依据这个定义，React组件的this.state毫无疑问是v-state；
开辟者常说的model或许store state应当看做p-state，然则如许说过于笼统和广泛，没有边境；而另一个说法，view state，一样缺少明白的边境定义；所以我们临时防止运用这两种表述；器具有严厉定义的p-state和v-state来睁开议论；
义务与边境
对象封装的义务与边境在面向对象编程里都是迥殊基本的观点，优越的模块封装必需做到义务明白和边境清楚；每一个范例的对象有明白的义务和边境定义，差别范例的对象之间经由过程组合、接口挪用、或许音讯机制完成交互，组成易于保护的体系；
然则在React里，这个设想体式格局变得难以付诸实施；
React的机制是父组件不应直接接见子组件，因为子组件的生命周期不是父组件保护的，是React保护的；React父组件不去接见子组件也意味着子组件须要的状况要提拔至父组件保护，父组件更新了这些状况以后，经由过程props向下通报；
触发状况转变的缘由可以由子组件提议（看起来更像封装），然则须要父组件供应Callback，逻辑处置惩罚依然由父组件完成；这意味着子组件的状况和行动，都托管到父组件去了，子组件只担任衬着和诠释用户输入行动；但这给封装和重用制作了贫苦，雷同的逻辑会反复书写在差别的父组件中；
在StateUp情势中，我们明白给出了p-state的定义和完成，即StateUp组件中的静态State类，用于组织p-state对象；
StateUp组件的衬着函数相当于f(p-state, v-state, props)；
增添的p-state对象用于保护底本要提拔至React父组件的状况，以及行动；换句话说，假如运用p-state对象，底本由子组件托管到父组件保护的（属于子组件保护义务的）状况，及其致使的经由过程props向下通报的数据，应当移动到p-state内保护，组件直接经由过程this.props.state接见；
固然这不能消弭一个StateUp组件衬着须要的一切props，因为HTML/DOM的构造设想，完整衬着组件须要的数据注定是它的一切父组件容器向下通报的数据的总和的一部份（即须要用到的部份）。
P-State的保护
p-state的完成在StateUp情势中有细致引见，这里不赘述；这里先论述一下基于p-state和v-state观点，StateUp情势中的生命周期题目怎样严厉表述，然后论述StateUp情势的数学实质；
在StateUp情势中，StateUp组件A的p-state不在组件A中保护，它须要提拔至父组件B，提拔有多是递归的，即在父组件B中被继承提拔；直到某一个React组件C，把这个树状层级的p-state对象安排在本身的v-state (this.state)中，这意味着StateUp组件A的状况生命周期，和组件C的视图生命周期是一致的；
我们把组件C称为组件A的p-state ancestor；
组件C在它的任何子组件的p-state发生变化时，都邑挪用this.setState更新本身的v-state，关于React而言，这触发一切子组件的衬着；但因为immutable的数据构造和PureComponent的SCU设想，render是按需的，仅须要render的子组件会被render；
p-state的更新途径
在StateUp情势中有一些一眼看上好像不合理的设想；
const StateUp = base => class extends base {
setSubState(name, nextSubState) {
let state = this.props.state || this.state
let subState = state[name]
let nextSubStateMerged = Object.assign(new subState.constructor(), subState, nextSubState)
let nextState = { [name]: nextSubStateMerged }
this.props.setState
? this.props.setState(nextState)
: this.setState(nextState)
}
setSubStateBound(name) {
let obj = this.setSubStateBoundObj || (this.setSubStateBoundObj = {})
return obj[name]
? obj[name]
: (obj[name] = this.setSubState.bind(this, name))
}
stateBinding(name) {
return {
state: this.props.state ? this.props.state[name] : this.state[name],
setState: this.setSubStateBound(name)
}
}
}既然我们明白分清了p-state和v-state，为何p-state的更新，要象上述代码一样走React组件的要领，为何不是把p-state对象零丁构建一个tree，毕竟它是JavaScript对象，写起来并不难；
这个题目的实质触及到了immutable的tree数据构造的一个常见题目，即你不可以构建一个cyclic数据构造是immutable的，至少在JavaScript这类有statement没有lazy evaluation的言语里不可以；
事实上我为这个主意写了代码，例如在父组件的p-state对象中如许写：
// parent component p-state object
static State = class State {
constructor() {
this.sub1 = new Sub.State()
this.sub1.parent = this
this.sub1.propName = 'sub1'
}
}如许就在子组件的p-state内装载了父组件的p-state的援用；看起来在子组件的p-state上好像可以设想一个setState要领（不是React Component上的setState），直接挪用父组件的p-state对象上的setState要领，就可以完成递归更新；
但这是一个假象；斟酌以下A/B/C/D的构造：
A -> A'
B B'
C C'
D D在C更新至C’时，D没有变化，然则D的父对象不再是B而是B’；
处理这个题目的方法，也是通用的immutable tree数据构造的双向援用题目的解法，是所谓的Red-Green Tree (拜见参考文献)。
Red Green Tree
Red-Green Tree在外部看是一个Tree，在内部份成Red Tree和Green Tree，外部接见经由过程Red Tree，Green Tree是内部的；
Red Tree的构造和Green Tree如出一辙，它是一个mutable tree，每一个节点包括自下至上的援用(parent援用)和向右援用Green Tree上的对应对象，Green Tree是immutable tree，只要自上至下的援用：
red tree green tree
A -> null, A' A'
B -> A, B' B'
C -> B, C' C'
D -> B, D' D'
A -> null, A" A"
B -> A, B" B"
C -> B, C" C"
D -> B, D' D'当操纵C的时刻，Green Tree的A’/B’/C’都邑发生变化，同时Red Tree自上至下更新，它的向上援用稳固，然则向右的援用悉数革新成最新的Green Tree对象；如许既保护了双向援用，又完成了immutable；
在StateUp情势中，Component相当于Red Tree上的节点，p-state对象是Green Tree上的节点；Component的this.prop.state相当于向右援用，render时自上至下更新(B’ -> B”)；this.prop.setState相当于向上援用(B->A)，它是稳固的，这个稳固援用保证在更新D时可以先找到父节点B然后找到最新的B”，从而准确完成D在父对象里的援用更新；
因为React自上至下衬着，所以在父组件内拿子组件的援用是风险的，因为可以逾期；然则子组件向父组件的援用在每次衬着以后都是保证准确的；
所以在StateUp情势中，经由过程用Component负担Red Tree的义务，保证p-state tree可以完成immutable的Green Tree，有此带来p-state对象的高可保护性和机能保证；
我曾以为stateBinding函数完成了两个prop通报是不太合理的设想，但从上面的图示看这非常合理，个中state是子组件的向右援用，setState是子组件的向上援用，应用React的props和render机制完成Red-Green Tree的更新，这是React和Immutable的圆满连系。
状况治理
假如去对照其他的React状况治理器，运用这里给出的p-state和v-state观点，会发明：
大多数状况治理器把
p-state提拔到最顶层，构建外部状况树；状况治理器须要用户手工代码来完成组件更新绑定，以进步效力，但这是理论上的优美，实际上程序员不会对更新做太细粒度的治理，除非碰到严峻机能题目；
种种状况治理器都在试图应用immutable来做机能优化，然则没有触及题目的实质，即Red-Green Tree题目，这也是React的实质；假如你仅仅运用全局状况树，你只做对了题目的一半。
置信每一个深切思索过React的外部状况树和组件树关联的程序员都曾在大脑中有过如许的题目，它们两个究竟该不应一致？
StateUp情势给这个题目一个明白的回复：应当，但不是在React组件层面上的，而是StateUp组件层面的；更确实的说是p-state ancestor组件组成的树，就是Model的构造树，它包括运行时组件状况组合构造和生命周期两方面的定义；而每一个节点拓扑睁开的React Component子树，仅具有视图层的寄义；
所以在设想时细致斟酌p-state ancestor的处置惩罚，是对状况该写在那里的最有协助的思索；同时，基于StateUp情势，这个Model的构造是自动组出来的，不是开辟者自力定义的；
React的this.state仅针对v-state设想，在没有p-state对象封装的情况下，它相当于把p-state ancestor的子树睁开后，内部一切情势无态但本该有态的组件的态和行动都提拔到该组件内完成，为代码重用和保护带来很大贫苦；
从前面Red-Green Tree的剖析可以看出，提取p-state举行对象封装，不然则可行的，而且是适当的，可以有用应用PureComponent特征进步最高衬着效力，在模子上也有数学算法的支持。
因为事情忙碌我无意把StateUp情势搞成象redux那样的盛行项目，代码量也撑不起一个项目的范围；而且StateUp的代码自身也还显得过于大略，或许让p-state对象可以emit event可以制造更多的方便，等等；
然则在工程实践上我会主动实践这类体式格局，碰到实际题目也会尽最大勤奋去在这个框架下追求处理方案，毕竟在现在阶段看起来，StateUp情势把UI的开辟带回了我们熟习的面向对象范畴，对种种庞杂的行动情势和构造情势，都有大批的成熟情势可用，而没必要在非常分裂的组件交互机制下觉得左支右绌。
末了
这20行代码是我一年多的React开辟实践中写过的最好的代码，它很粗拙，然则它背地的算法模子有非常简朴壮大的气力；
它并不是基于Red-Green Tree推演的效果，而是偶得后对其做更深层面的思索，发明它完整符合了immutable数据构造和函数式编程的设想头脑；而immutable，是我们现在已知虽然机能并不是最好，然则处理自动革新题目的最简朴手腕；同时函数式编程的易于调试也是庞大的工程收益。
迎接人人议论和发表意见。
