React批量更新与事件体系
1 | let count = 0; |
- React的批量更新机制
- BatchUpdates
a. 什么场景下会默认使用React批量更新?
ⅰ. 答案:componentWillMount和React事件体系内
b. 为什么要做批量更新?
ⅰ. 解决性能问题 - React事件体系
a. React事件体系与浏览器原生事件体系的关系
b. 为什么React自己维护一套自己的事件体系
ⅰ. 一个重要的原因是为了实现批量更新
setState
1: setState是同步还是异步是根据什么来判断的
调用合成事件的时候是异步
原生事件的是同步
2: setState的简单原理(加分项)
大概就是采用队列机制
1:this.setState({ name: ‘新的state’ })
2:存入peding队列
3:调用enqueueUpdate
4: 判断是否处于批量更新状态 isBatchingUpdates
5: isBatchingUpdates为true, 调用setState的组件存入dirtyComponents中,
isBatchingUpdates为false, 遍历dirtyComponents中的组件调用updateComponent
async和defer的区别
相同点:加载阶段都不会阻塞HTML的解析,但JS的执行会阻塞解析
不同点:async加载完成立刻执行,一般是与功能无关的资源,比如统计js;defer则会等待HTML解析完成再执行,与将script标签放在body最后类似
React优化方案
移动端1px问题
移动端开发经常遇到的问题,UI稿上是1px的细线,但在手机上就是显得比较粗,这里UI稿1px指的实际是物理像素,而CSS设置的1px对应了逻辑像素。
他们之间的关系; 物理像素 / 逻辑像素 = 设备像素比(DPR)
一般手机为2,而iphone的某些机型可以达到3,这时1px的线就会显得很粗了。
常见git命令及使用场景
- 执行merge后发现冲突太多,想要放弃此次merge
git merge --abort
Git merge和rebase的区别
React中key的作用
Keys负责帮助React跟踪列表中哪些元素被改变/添加/移除。React利用子元素的key在比较两棵树的时候,快速得知一个元素是新的还是刚刚被移除。没有keys,React也就不知道当前哪一个的item被移除了。
事件冒泡与捕获
当一个事件发生在具有父元素的元素上时,现代浏览器运行两个不同的阶段 - 捕获阶段和冒泡阶段。 在捕获阶段:
浏览器检查元素的最外层祖先<html>
,是否在捕获阶段中注册了一个onclick事件处理程序,如果是,则运行它。
然后,它移动到<html>
中单击元素的下一个祖先元素,并执行相同的操作,然后是单击元素再下一个祖先元素,依此类推,直到到达实际点击的元素。
在冒泡阶段,恰恰相反:
浏览器检查实际点击的元素是否在冒泡阶段中注册了一个onclick事件处理程序,如果是,则运行它
然后它移动到下一个直接的祖先元素,并做同样的事情,然后是下一个,等等,直到它到达<html>
元素。
在现代浏览器中,默认情况下,所有事件处理程序都在冒泡阶段进行注册。
如果您真的想在捕获阶段注册一个事件,那么您可以通过使用addEventListener()注册您的处理程序,并将可选的第三个属性设置为true。
JS变量声明方式
这个问法不常见,实际工作中也没太关注。
概括的说:ES5中,有var,function,及隐式声明(比如 a = 123, 这时是在window对象上新增了a属性);ES6新增了let,const,import,class方式,所以总共有7种。