React.js 组件的 props vs state
|
看到一篇无比蛋疼的文章：https://www.oschina.net/translate/exploring-reacts-state-propagation。我不针对翻译，只是针对这篇文章想提出的概念，说了跟没说一样，傻傻的。 要搞清楚React.js的props和state，必须要结合组件（组件类）从初始化到装载（mount）的过程来说。 组件类假定我们通过以下的代码，创建了一个组件： var SimpleComponent = React.createClass({
getDefaultProps: function() {
return {
name: ''
};
},getInitialState: function() {
return {
};
},render: function() {
return <div>A simple component named {this.props.name}</div>;
}
});
这里SimpleComponent是一个组件类。 组件虚拟对象当我们要使用这个组件类的时候，可以写这样的代码： <SimpleComponent name="abc"/> 实际上上述代码会转移成下面的js代码： React.createElement(SimpleComponent,null) 通过React.createElement函数创建的，并不是SimpleComponent的组件类实例（即不是new SimpleComponent），而是一个不可写入的静态对象（Object），并且这个静态对象，具有props，没错，就是SimpleComponent组件类定义的getDefaultProps所返回的值。 我将这个静态对象称为组件虚拟对象，他持有了SimpleComponent的初始化所需的props，并且我有理由怀疑他是全局唯一的（当然我没精力去验证了）。 所以，要知道，当我们在jsx文件中，写了大量看似html标签的结构，他实际上并没有逐个创建对应的组件实例，取而代之的，仅仅是构造一大堆组件虚拟对象（静态Object）和传入参数而已。 注意，这个时候组件虚拟对象是没有state的。 组件实体（实例）当一个组件虚拟对象被装载（mount）后——这里所谓装载，就是将一个或一大段组件虚拟对象插入到实际的DOM节点中时，才会创建出真实的组件实体（实例）。 创建组件的实体的时候，才会真正将调用参数传入（比如上面的name=abc），并且混入组件虚拟对象上的props。 当组件被实体化后，才真正的拥有state。 而我们实际在编写SimpleComponent这个组件类的方法时，都是假定针对的是组件实体的状态下进行的。 最后，总结为一个流程图来说明的话： props只读、不可变？我只能说，这是一个误区。首先，假定你拥有React Development tools的话，通过修改React.js的组件props，也能促使组件发生变化。就好像这样： 这个问题，仔细想想就能明白是别人给你挖了个坑（不是React.js，而是这些所谓的教程）。假定我们设计两个组件： var AComponent = React.createClass({
getDefaultProps: function() {
return {
name: ''
};
},getInitialState: function() {
return {
name: this.props.name
};
},render: function() {
return <div>I'm {this.props.name}</div>;
}
});
var BComponent = React.createClass({
getDefaultProps: function() {
return {
name: ''
};
},render: function() {
return <div>
<AComponent name={this.state.name} />
<button type="button" onClick={e => this.setState({name: 'Jack'})}>change name</button>
</div>;
}
});
在B组件内，是使用state.name作为A组件的props.name传入的，如果是只读、不可变的话，那么B组件的按钮被点击后，B组件的state.name改变了，永远也不可能触发到A组件state更新了。 所以，严格来说，props不可变，只在组件虚拟对象这个阶段，因为那是一个不可写入的静态对象。 更进一步，从组件类到组件实例，实际上是完成了从props将数据传递给state。这是一个必然性的数据流向，无论多少次组件嵌套，这种数据流向都不会改变。所以一般而言，很少会去动（注意这里只是说动，但没有说不去读）一个组件实例的props，而直接操作state。 传统的OOP编程，并没有严格的数据流向，到底是属性到方法，还是方法到属性，还是属性到属性，完全由开发者自己掌控，你爱怎么写，就怎么写。这在前端组件的源码中，形成了很大的伪装性，当发生错误的时候，你完全不知道该从哪里开始着手，需要花一定的时间去解读、调试，然后才能定位问题（当然有好的规范可以相对的缓解类似的问题）。 而React.js则提供一种简单明确的机制（而且他只提供了这个机制而已），这也是React.js开发过程中会形成的一个思维定式。每当你开始编写一个组件，你就需要设计，这个组件应该具有哪些动态（交互性）特征需要放入state，而这些state又是怎么从props传递过去的。仅此而已，剩下的就是组件的界面逻辑开发而已。 state - 状态这个应该不用多介绍了吧，React.js的卖点，组件实例的界面和自身的state动态结合，而且性能还相当的好。 不过其实这里也有一个小坑，就是当你在设计一个组件的时候，应该认真的思考哪些特征属于动态的。如果你在state里装载了大量的数据，要监控这些state的更新，还是相当的时间（其实真正很大的数据，大概会有3-5ms的延迟，但这个数据真的很大了）。所以，特别注意： setState方法是异步的！！！ setState方法是异步的！！！ setState方法是异步的！！！ 重要的事情说三次，是的，所以如果你这样写，可能会导致你的界面发生不可预料的后果： this.setState(bigData); // ...干点别的事情 正确的写法应该这样： this.setState(bigData,function() {
// ...干点别的事情
});
当你使用React.js开发的时间长了的话，慢慢的也会调整自己的思维方式，更加集中的设计state。这个下面还会提到。 es6 or typescript如果可能的话，如果改用es6或者ts，上面的代码，将会简单很多很多： class SimpleComponentES6 extends React.Component {
constructor(props) {
super(props);
this.state = {
name: this.props.name || ''
}
}
render() {
return <div>A simple component named {this.props.name}</div>;
}
}
代码是不是顿时清晰了很多？ ts现在已经迈进2.0时代了，各方面都比过去完善了很多。假如你的项目，超过1000行JS，最好能换成ts，因为ts的语言特性，会让你的代码的自动提示得更加明确，而不像js或者es6，有的没的相似的不是的方法、属性提示你一大堆。 （编辑：李大同） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |