上节课我们介绍了如何去优化mapDispatchToProps
函数,这节课我们继续来讲关于优化的问题。
回顾
在这节课内容开始之前,我们来对上节课的内容来做一个简单的回顾:
mapDispathtoProps
可以是一个对象react-redux
可以自动分发动作对象
以上便是我们上节课的主要要点,接下来,我们来开始这节课的内容。
redux
状态驱动页面更新
我们先来回想一下,我们之前说过redux
中的状态变化并不会驱动页面更新,那么我们不得已就得在组件一挂载完成的时候就让redux
来监测状态变换,一旦变化了我们就通过修改组件state
的方式来使得页面重新渲染
export default class Sum extends Component { componentDidMonut() { store.subscribe( () => this.setState({}); ) } }
我们之前是不是这么写的?但是这么写是不是很麻烦啊?如果说这个组件没被挂载怎么办啊?我们有一个方法可以在index.js
这个入口文件中来做处理,我们来看一下:
ReactDOM.render(<App />, document.getElementById('root')); store.subscribe( () => ReactDOM.render(<App />, document.getElementById('root')) );
这是什么意思?我们首先是不是先渲染了App
组件?App
组件是一切组件的父组件。这样我们可以完成一个初始页面的展示。然后我们再用store
来监测state
的变化,一旦变化我们直接通过ReactDOM
将整个页面重新渲染。
可能有人要问了,你这么搞,如果页面上有几百个组件效率不会出问题吗?我们之前是不是说过有diffing
算法啊?我们这么搞的话,即便组件很多,diffing
算法也还是会照常进行比对的啊。所以说不会有什么影响。
但是呢我们上面这个操作是不是都是原生redux
需要注意的点?我们现在是不是用上了react-redux
?那么我们把这段代码删掉,我们不手动去监测redux
里的状态了,那么我们看效果:
现在我们没有手动去监测,但是也可以驱动页面更新了,这是为什么呢?这就是react-redux
为我们做的事儿了,我们的容器组件是不是通过connect
函数创建的?我们用了connect
函数就使得我们的容器组件自动有了监测redux
状态变化的能力了。
传入store
那么我们还有一个问题,我们的容器组件是在哪渲染的?是不是在App
组件里?那么我们的App
组件里可能就只有一个组件吗?如果我们有十几个容器组件,这十几个容器组件是不是都要接收到store
啊?那么我们这样一个个传是不是很麻烦?那么有没有一个简单的办法呢?那就要请出我们的Provider
组件了。
Provider
组件是react-redux
库中提供的一个专门用来传递store
的一个组件,那么怎么用呢?
// App 组件 export default class App extends Component { render() { return ( <div> <Sum /> </div> ) } } // index.js import store from './redux/store'; import { Provider } from 'react-redux'; ReactDOM.render( <Provider store={store}> <App /> </Provider>, document.getElementById('root') );
我们来看一下,我们用Provider
来传store
的话,那么我们的App
组件中就不用再手动给各个子组件传store
了。然后再来看index.js
文件,我们是不是用Provider
组件把App
组件包裹住了。并且通过props
把store
传给了Provider
组件,那么这个时候Provider
组件就会同意给App
组件中的容器组件传入store
总结
react-redux
自动帮我们监测redux
中的状态变化react-redux
提供了Provider
组件来替我们批量传递store
Copyright statement:The articles of this site are all original if there is no special explanation, indicate the source please when you reprint.
Link of this article:https://work.lynchow.com/article/provide_component/