前言
React 是 Facebook 里一群牛 X 的码农折腾出的牛X的框架。 实现了一个虚拟 DOM,用 DOM 的方式将需要的组件秒加,用不着的秒删。本文主要给大家介绍了关于想用好React的你必须要知道的一些事情,下面话不多说,来一起看看详细的介绍:
一、容器性组件(container component)和展示性组件(presentational component)
使用React编写组件时,我们需要有意识地将组件划分为容器性组件(container component)和展示性组件(presentational component),这样有助于我们在编写组件时,更加明确这个组件应该负责哪些事情。
容器性组件,负责业务流程逻辑的处理,如发送网络请求,处理请求数据,将处理过的数据传递给子组件的Props使用。同时,容器性组件提供源数据的方法,以Props方式传递给子组件,当子组件的状态变更引起源数据的变化时,子组件通过调用容器性组件提供的方法同步这些变化。
展示性组件,负责组件的外表,也就是组件如何渲染,具有很强的内聚性。展示性组件不关心渲染时使用的组件属性(Props)是如何获取到的,它只要知道有了这些Props后,组件应该如何渲染就足够了。属性如何获取,是容器性组件负责的事情。当展示性组件状态的变化需要同步到源数据时,需要调用容器性组件中的方法,这个方法一般也是通过Props传递给展示性组件。
例如,一个Todo项目,有一个Todo组件和一个TodoList组件,Todo组件是一个容器性组件,负责从服务器端获取待办事项列表,获取到待办事项列表后传递给TodoList显示。当在TodoList中新建一项待办事项后,需要通过TodoList 的 Props,调用Todo组件中保存待办项目的方法,将新建的待办项目同步到服务器端。
容器性组件和展示性组件可以相互嵌套,一个容器性组件可以包含多个展示性组件和其他的容器性组件;一个展示性组将也可以包含容器性组件和其他的展示性组件。这样的分工,可以使与组件渲染无直接关系的逻辑由容器性组件集中负责,展示性组件只关注组件的渲染逻辑,从而使展示性组件更容易被复用。对于非常简单的页面,一般只要一个容器性组件就足够了;但对于负责页面,则需要多个容器性组件,否则所有的业务逻辑都在一个容器性组件中处理的话,会导致这个组件非常复杂,同时这个组件获取到的源数据,可能需要经过很多层的组件Props的传递,才能到达最终使用的展示性组件。
二、Props、State和组件的普通属性
Props、State的概念都很清晰,组件的普通属性是指在组件中直接挂载到this下的属性。其实,Props和State也是组件的两个普通属性,因为我们可以通过this.props
和 this.state
直接获取到。那么Props、State 和 组件的其他普通属性,分别应该在什么场景下使用呢?
Props和State都是用于组件渲染的,也就是说,一个组件最终长成什么样,取决于这个组件的Props和State。Props和State的变化都会触发组件的render方法。但这两者也是有区别的。Props是只读的数据,它是由父组件传递过来的;而State是组件内部自己维护的状态,是可变的。State可以根据Props的变化而变化。如果组件中还需要其他属性,而这个属性又与组件的渲染无关(也就是render方法中不会用到),那么就可以把这个属性直接挂在到this下,而不是作为组件的一个状态。
例如,组件中需要一个定时器,每隔几秒改变一下组件的状态,就可以定义一个this.timer
属性,以备在componentWillUnmount时,清除定时器。
三、setState 异步性
React官网提到,this.state
和this.props
的更新可能是异步的,React可能会出于性能考虑,将多个setState的调用,合并到一次State的更新中。所以,不要依赖this.props
和 this.state
的值计算下一个状态。引用官网的一个代码示例:
// Wrong this.setState({ counter: this.state.counter + this.props.increment, });
如果一定要这么做,可以使用另一个以函数作为参数的setState方法,这个函数的第一个参数是前一个State,第二个参数是当前接收到的最新Props。如下所示:
// Correct this.setState(function(prevState, props) { return { counter: prevState.counter + props.increment }; });
在调用setState之后,也不能立即使用this.state
获取最新状态,因为这时的state很可能还没有被更新,要想保证获取到的state是最新的state,可以在componentDidUpdate中获取this.state
。也可以使用带用回调函数参数版本的setStatesetState(stateChange, [callback])
,回调函数中的this.state
会保证是最新的state。
四、componentWillReceiveProps
当组件的属性可能发生变化时,这个方法会被调用。这里说可能,是因为父组件render方法每次被调用时,子组件的这个方法都会被调用(子组件第一次初始化时除外),但并不一定每次子组件的属性都会发生变化。如果组件的State需要根据Props的变化而变化,那么这个方法就是最适合这个这个逻辑的地方。例如当Props变化时,组件的State需要重置,就可以在这个方法中调用this.setState()
来重置状态。需要注意,在这个方法中调用this.setState()
并不会重新触发componentWillReceiveProps的调用,也不会导致render方法被触发两次。一般情况下,接收到新Props会触发一次render,调用this.setState
也会触发一次render,但在componentWillReceiveProps中调用this.setState,React会把原本需要的两次render,合并成一次。
五、shouldComponentUpdate
这个方法常作为优化React性能使用。当shouldComponentUpdate返回false时,组件本次的render方法不会被触发。可以通过在这个方法中比较前后两次state或者props,根据实际业务场景决定是否需要触发render方法。
React提供了一个React.PureComponent
组件,这个组件重写了shouldComponentUpdate,会对前后两次的state和props进行浅比较,如何不一致,才会返回true,触发后续的render方法。这里的浅比较指,只会对state和props的第一级属性进行比较(使用!==),这满足一般的使用场景。如果你的组件继承了React.PureComponent
,但在setState时,传入的state是直接修改的原有state对象,就会因为依然满足浅比较的条件,而不会重新触发render方法,导致最终DOM和state不一致。例如state={books: ['A','B']}
,在setState时,使用this.setState({name: this.state.books.push('C')})
直接修改books对象,这样虽然books内容发生了修改,但因为对象引用并没有变化,所以依然满足浅比较条件,不会触发render方法。
一般情况下,让shouldComponentUpdate返回默认的true是不会有太大问题的。虽然这样可能导致一些不必要的render方法被调用,但render方法直接操作的是虚拟DOM,只要虚拟DOM没有发生变化,并不会导致实体DOM的修改。而JS慢是慢在实体DOM的修改上。只要你的render方法不是很复杂,多调用几次render方法并不会带来多大的性能开销。
六、render
父组件每次render方法被调用,或者组件自己每次调用setState方法,都会触发组件的render方法(前提是shouldComponentUpdate使用默认行为,总是返回true)。那么组件每次render,是不是都会导致实体DOM的重新创建呢?答案是,不是!
React之所以比直接操作DOM的JS库快,原因是React在实体DOM之上,抽象出一层虚拟DOM,render方法执行后,得到的是虚拟DOM,React 会把组将当前的虚拟DOM结构和前一次的虚拟DOM结构做比较,只有存在差异性,React才会把差异的内容同步到实体DOM上。如果两次render后的虚拟DOM结构保持一致,并不会触发实体DOM的修改。
React速度快的原因,还有一个是它出色的Diff算法。标准的比较两棵树的Diff算法的时间复杂是 O(n3) 。而React基于非常符合实际场景的两个假设,就将Diff算法的时间复杂度降到了接近O(n)。这两个假设是:
- 如果两个组件或元素类型不同,那么他们就是完全不同的树,不需要再比较他们的子节点。例如,<Article>和<Comment>将产生是两个完全的树状结构;
<div>children</div>
和<p>children</p>
也是两个完全不同的树。这种情况下,组件会被完全重建,旧的DOM节点被销毁,组件经历componentWillUnmount()
,然后重新创建一棵新树, 组件经历componentWillMount()
和componentDidMount()
。 - 可以为组件或元素设置key属性,key用来标识这个组件或元素。key不需要全局唯一,只需要在兄弟组件或兄弟元素间保证唯一性就可以。key常用到集合(List)元素中。
例如:
<ul> <li key='a'>Book A</li> <li key='b'>Book B</li> </ul>
当在第一个位置插入一条记录Book C 时,
<ul> <li key='c'>Book C</li> <li key='a'>Book A</li> <li key='b'>Book B</li> </ul>
由于有key的标识,React知道此时新增了一条记录,会创建一个新的<li>元素,并把它插入到列表中的第一个位置。如果没有设置key,React并不知道是新增了一条记录,还是原来的两条记录完全替换成新的三条记录,或者其他更加复杂的修改场景。React需要自上而下的比较每一条记录,这样每次比较节点都不同,所以需要修改两次节点,然后再新增一个节点,效率明显要差很多。
这里同时揭露了另一个问题,不要使用元素在集合中的索引值作为key,因为一旦集合中元素顺序发生改变,就可能导致大量的key失效,进而引起大量的修改操作。
如何发送网络请求
当我们需要从服务器获取数据时,我们应该在组件的哪一个生命周期方法中发送网络请求呢?React官网上提到,可以在componentDidMount中发送网络请求,这也是一般情况下的最佳实践。有些人也会把发送网络请求放在componentWillMount中,并且认为这个方法先于componentDidMount调用,所以可以更快地获取数据。个人认为,这种使用方法一般也是没有问题的,但在一些场景下会出现问题,比如需要在服务器端渲染时,componentWillMount会被调用两次,一次是在Server端,一次是在Client端。可参考这篇文章。
总结
以上就是这篇文章的全部内容了,希望本文的内容对大家的学习或者工作能带来一定的帮助,如果有疑问大家可以留言交流,谢谢大家对的支持。
免责声明:本站资源来自互联网收集,仅供用于学习和交流,请遵循相关法律法规,本站一切资源不代表本站立场,如有侵权、后门、不妥请联系本站删除!
更新日志
- 凤飞飞《我们的主题曲》飞跃制作[正版原抓WAV+CUE]
- 刘嘉亮《亮情歌2》[WAV+CUE][1G]
- 红馆40·谭咏麟《歌者恋歌浓情30年演唱会》3CD[低速原抓WAV+CUE][1.8G]
- 刘纬武《睡眠宝宝竖琴童谣 吉卜力工作室 白噪音安抚》[320K/MP3][193.25MB]
- 【轻音乐】曼托凡尼乐团《精选辑》2CD.1998[FLAC+CUE整轨]
- 邝美云《心中有爱》1989年香港DMIJP版1MTO东芝首版[WAV+CUE]
- 群星《情叹-发烧女声DSD》天籁女声发烧碟[WAV+CUE]
- 刘纬武《睡眠宝宝竖琴童谣 吉卜力工作室 白噪音安抚》[FLAC/分轨][748.03MB]
- 理想混蛋《Origin Sessions》[320K/MP3][37.47MB]
- 公馆青少年《我其实一点都不酷》[320K/MP3][78.78MB]
- 群星《情叹-发烧男声DSD》最值得珍藏的完美男声[WAV+CUE]
- 群星《国韵飘香·贵妃醉酒HQCD黑胶王》2CD[WAV]
- 卫兰《DAUGHTER》【低速原抓WAV+CUE】
- 公馆青少年《我其实一点都不酷》[FLAC/分轨][398.22MB]
- ZWEI《迟暮的花 (Explicit)》[320K/MP3][57.16MB]