从我毕业到现在也差不多快一年半了,想要找个地方沉淀下自己,同时也希望大佬们,指出我错误的思考。 我直接把我自己写的 ppt 的东西复制过来了
特点
1.声明式设计 −采用声明范式,可以轻松描述应用。
2.高效 −通过对DOM的模拟,最大限度地减少与DOM的交互。
3.灵活 −可以与已知的库或框架很好地配合。
4.组件 − 通过 React 构建组件,使得代码更加容易得到复用,能够很好的应用在大项目的开发中。
5.单向响应的数据流 − React 实现了单向响应的数据流,副作用少,易于追踪问题和维护
定义组件的多种方式
createClass
// es5 环境下
var Contacts = React.createClass({
render() {
return (
<div>1</div>
)
}
})
React.Component
// es6 方式需要编译
class Contacts extends React.Component {
constructor(props) {
super(props);
}
render () {
return <div>1</div>
}
}
无状态函数式组件
// 适合纯渲染组件
const Contacts = (props) => <div>1</div>
生命周期
贴张官方图

各阶段函数说明
Mounting(挂载)
- getDefaultProps:获取默认 props
- getInitialState | | constructor: 都是定义默认的 state,只不过是两种定义组件的方式
componentWillMount: 即将废弃,在render之前调用,所以就算在这个方法中调用setState也不会触发重新渲染(re-render)- render: 最核心的方法: 返回需要渲染的东西
- componentDidMount:
- 此时已获取到真实 dom, jquery 。
- 不过一般都用做 数据请求,此时 setState 可以重新触发渲染
- 如果一个组件有兄弟组件、父子组件那么执行该方法的顺序:排在面的子组件, 所有子组件执行完再父亲组件,都是因为递归渲染的特性
Updating(更新) 将会在 props或 state 更新后调用
componentWillReceiveProps: 即将废弃, 由 getDerivedStateFromProps 替代,更新 state 的值、比较 nextProps和 this.props 避免重复渲染- shouldComponentUpdate: 判断组件是否应该重新渲染,默认为 true,主要用于性能优化
- componentWillUpdate: state 或者 props 更新后 re-render 之前调用。不可以在此 setSate , 会溢出栈造成浏览器卡死 render()
- componentDidUpdate:可以操作dom 发起 网络请求
卸载阶段
componentWillUnmount: 当我们的组件被卸载或者销毁了就会调用,我们可以在这个函数里去清除一些定时器,取消网络请求, 在 spa 中比较常见
组件通信
父子: 通过 props
子父: 回调函数,通过更新 父亲的 state 来更新
子子: 1. emit 的方式 发布订阅 2. 通过父亲组件来中转
跨层级组件:context context是一个全局变量,像是一个大容器,在任何地方都可以访问到。
但是 当中间某个组件 shouldComponentUpdate 设置为 false 的时候就 gg 了。
原因是 shouldComponentUpdate 会切断子树的 rerender,当 state 或 props
没有发生变化时,可能意外中断上层 context 传播。也就是当 shouldComponentUpdate
返回 false 时,context 的变化是无法被底层所感知的。
三方状态库: redux、rematch (二次封装redux)、mobx、smobx,
这些东西借助一句话,"如果你不知道是否需要 Redux,那就是不需要它。"
redux 🌰
三大原则
- 单一数据源
- State 只读的 (此处可能会有歧义)
- 用纯函数执行修改
结合 react 使用, 一张我画的简图代表个人理解

核心概念
路由
更多
- 高阶组件
- graphql
- react native
- 函数式编程
结语
2019 年基本计划是 写一个不错的个人项目, 同时有机会去了解下底层实现,也去学习 vue 对比下。 欺骗一下自己: 新的一年,新的自己