codingmeup

### 终端交互优化 对click事件say no 弹性滚动 上拉刷新 tap事件基础 touch触摸事件 下拉加载 - 300ms tap事件及fastclick: 300ms延迟怎么破？tap事件代替click事件。自定义tap事件原理： 在touchstart、touchend的记录时间、手指位置，在touchend时进行比较，如果手指位置为同一位置(或允许移动一个非常小的位移值)且时间间隔较短（一般认为是200ms），且过程中未曾触发过touchmove，即可认为触发了手持设备上的“click”，一般称它为“tap”。 tap“点透”的bug： 有两层，点击第一层的时候，如果点击的区域在第二层的范围内，那么第二层也会被触发。（原因与300ms有关） tap透传的解决方案： ①使用缓存动画，过渡300ms的延迟 ②中间层dom元素的加入，让中间层接收这个“穿透”事件，稍后隐藏 ③“上下”都使用tap事件，原理上解决tap穿透事件，（但是不可避免原生标签的click事件，如a，input）。 ③ 改用Fastclick的库（听过最新的zepto已经fixed掉这个bug） - Touch基础事件 触摸才是移动设备的交互的核心事件，支持多点触摸。 touchstart：手指触摸屏幕触发（已经有手指放屏幕上不会出发） touchmove：手指在屏幕上滑动，连续触发 touchend：手指离开屏幕时触发 touchcancel：系统取消touch时候触发（不常用）eg：滑动页面时来了一个电话或者其他系统事件 除常见的事件属性外，触摸事件包含专有的触摸属性：...

### 零碎的细节 1）CSS3动画，代替DOM animation，效率更高，因为css3直接使用浏览器的GPU（图形处理器）渲染 2） 当你给一个元素设置它的百分比宽度的时候，他需要一个比照，也就是父元素，但是当它没有父的时候，需要给他一个绝对定位absolute值，但是在移动开发中，给整个整块的页面使用position: absolute;很占用内存，特别是当内容比较多的时候，会非常明显。会有几个后果：在ios下，会导致浏览器直接崩溃掉；在android下，会导致非常非常的卡。所以建议直接用js计算。 3）将图片显示到一排上，不使用浮动，使用-webkit-transform:translate3d(0,0,0); position: absolute; 4）new Date() * 1 === new Date().getTime()；// * 1 ，进行数值运算，转换为数字形式的时间戳 5） self.startX = evt.touches[0].pageX; //记录开始的位移,touches包含着所有手指触摸在屏幕上的点的集合 -webkit-backface-visibility:hidden;/* 防止闪白 */ 6）更多图片的优化，保留3个要使用的节点，当前的，上一个，下一个图片的节点，剩余的不需要的删除 8）2048制作过程中遇到的bug：（见9（2）touch基础事件BUG）]...

### 在生命周期中的哪一步你应该发起 AJAX 请求？ * React 下一代调和算法 Fiber 会通过开始或停止渲染的方式优化应用性能，其会影响到 componentWillMount 的触发次数。对于 componentWillMount 这个生命周期函数的调用次数会变得不确定，React 可能会多次频繁调用 componentWillMount。如果我们将 AJAX 请求放到 componentWillMount 函数中，那么显而易见其会被触发多次，自然也就不是好的选择。 * 如果我们将 AJAX 请求放置在生命周期的其他函数中，我们并不能保证请求仅在组件挂载完毕后才会要求响应。如果我们的数据请求在组件挂载之前就完成，并且调用了setState函数将数据添加到组件状态中，对于未挂载的组件则会报错。而在 componentDidMount 函数中进行 AJAX 请求则能有效避免这个问题。

### React 中的事件处理逻辑 * 为了解决跨浏览器兼容性问题，React 会将浏览器原生事件（Browser Native Event）封装为合成事件（SyntheticEvent）传入设置的事件处理器中。 * 这里的合成事件提供了与原生事件相同的接口，不过它们屏蔽了底层浏览器的细节差异，保证了行为的一致性。 * React 并没有直接将事件附着到子元素上，而是以单一事件监听器的方式将所有的事件发送到顶层进行处理。这样 React 在更新 DOM 的时候就不需要考虑如何去处理附着在 DOM 上的事件监听器，最终达到优化性能的目的。

### React解决了什么问题 * 赶上潮流 * MVC与Flux的差异，MVC的弱势以及Flux弥补的不足，MVC架构的双向绑定以及一对多的关系容易造成连级/联动（Cascading）修改，对于代码的调试和维护都成问题。 https://zhuanlan.zhihu.com/p/21324696

### React 中 SOLID五大原则 * **单一职责(Single responsibility principle)**，React组件设计推崇的是**组合**，而非**继承**。 * 如你的页面需要一个表单组件，表单中需要有输入框，按钮，列表，单选框等。那么在开发中你不应该只开发一（整）个表单组件（(Form)），而是应该开发若干个单一功能的组件，比如输入框、提交按钮、单选框等，最后再将它们组合起来。这其中的重点是每个组件仅做一件事。 * 你需要一个函数异步请求数据并返回JSON数据格式，那么你应该拆分为两个函数，一个复杂数据请求，另一个负责数据转化。你可能会好奇为什么一个简单的JSON.parse也拆分出来，因为将来需要会变动，你可能不仅仅需要JSON.parse，还需要转义，需要转化为proto buffer数据格式。而拆分之后如果再面临修改的话，就不会影响到数据请求部分的代码。 * 同样适用于**开放/封闭(Open/closed principle)原则**。开放/封闭强调的是对修改封闭（禁止修改内部代码），对拓展开放（允许你拓展功能）。因为修改意味着风险，可能会影响到不用修改的代码， 同时意味着暴露细节。你一定纳闷如果不允许修改代码的话如何拓展功能呢，在传统的面向对象编程中，这样的需求是通过继承和接口机制来实现的。在React中我们使用官方推荐的 Higher-Order Components 的模式去实现。 * **接口隔离（Interface segregation principle）** 这个就放之四海而皆准了。第三方类库或者模块都避免不了对外提供调用接口，比如对于jQuery来说$是选择器，css用于设置样式，animate负责动画，你不希望把这三个接口都合并成一个叫做together吧，虽然实现起来没有问题，但是对于你将来维护这个类库，以及使用者调用类库，以及调用者的接替者阅读代码（因为他要区分不同上下文中调用这个接口究竟是用来干嘛的），都是不小的困难。 * **依赖反转（Inversion Of Control）原则**。这条原则听上去有点拗口。这条原则是意思是，当你在为一个框架编写模块或者组件时，你只需要负责实现接口，并且到注册到框架里即可，然后等待框架来调用你，所以它的另另一个别名是 “Don't...

### 组件的Render函数在何时被调用 * 单纯、侠义的回答这个问题，毫无疑问Render是在组件 state 发生改变时候被调用。无论是通过 setState 函数改变组件自身的state值，还是继承的 props 属性发生改变都会造成render函数被调用，即使改变的前后值都是一样的。 shouldComponentUpdate 默认都返回true，即允许render被调用。如果你对自己的判断能力有自信，你可以重写这个函数，根据参数判断是否应该调用 Render 函数。这也是React其中的一个优化点。 * React组件中存在两类DOM，一类是众所周知的Virtual DOM，相信大家也耳熟能详了；另一类就是浏览器中的真实DOM（Real DOM/Native DOM）。React的Render函数被调用之后，React立即根据props或者state重新创建了一颗Virtual DOM Tree，虽然每一次调用时都重新创建，但因为在内存中创建DOM树其实是非常快且不影响性能的，所以这一步的开销并不大。而Virtual DOM的更新并不意味这Real DOM的更新，接下来的事情也是大家知道的，React采用算法将Virtual DOM和Real DOM进行对比，找出需要更新的最小步骤，此时Real DOM才可能发生修改。

### 组件的生命周期有哪些 - 初始化阶段（Mounting） - constructor(): 用于绑定事件以及初始化state（可以通过"fork"props的方式给state赋值） - componentWillMount(): 在mount前被调用，你可以在这里同步操作state, 但是不会render - render(): 这个函数是用来渲染DOM没有错。但它只能用来渲染DOM，请保证它的纯粹性。如果有操作DOM或者和浏览器打交道的一系列操作，请在下一步骤componentDidMount中进行 - componentDidMount(): 如果你有第三方操作DOM的类库需要初始化（类似于jQuery，Bootstrap的一些组件）操作DOM、或者请求异步数据，都应该放在这个步骤中做 - 更新阶段（Updating） - componentWillReceiveProps(nextProps): 在这里你可以拿到即将改变的状态，可以在这一步中通过setState方法设置state，我通常做编辑回填表单 - shouldComponentUpdate(nextProps, nextState): 这一步骤非常重要，它的返回值决定了接下来的生命周期函数是否会被调用，默认返回true，即都会被调用；你也可以重写这个函数使它返回false。 - componentWillUpdate(): 我也不知道这个声明周期函数的意义在哪里，在这个函数内你不能调用setState改变组件状态 -...

### 组件的优化 - 使用上线构建（Production Build）：会移除脚本中不必要的警告和报错，减少文件体积 - 避免重绘 （Avoid Reconciliation）：重写 shouldComponentUpdate 函数，手动控制是否应该调用 render 函数进行重绘 - 尽可能的使用 Immutable Data（ The Power Of Not Mutating Data）：尽可能的不修改数据，而是重新赋值数据。这样的话，在检测数据对象是否发生修改方面会非常快，只需要检测对象引用即可，而不用挨个的检测对象属性的更改 - 在渲染组件的时候尽可能的添加key ，这样Virtual DOM在对比时就会更容易发现哪里，哪里是修改元素，哪里是新插入的元素。这里也同时回答了key的作用。如果你有使用过React渲染一个列表的话，它会建议你给每一项添加上key。我个人认为key就类似于DOM中的id，不过是组件级别的，用于标记元素的唯一性。

### React Vue Redux Vuex - 代码文件大小：React代码打包之后相对较大，基本是300KB起跳；而Vue和Vuex框架代码则相对较小，基础库能维持在100KB左右。 - 现成的框架：在Flux初期，Facebook只是推出了Flux这个框架概念，而没有实现这个框架。除非你使用一些第三方的Flux框架，否则你需要自己去实现Flux中的两个事件机制（Component对于Store的响应，Store对于Action的响应）。当然现在React的github项目里已经有Flux框架的示例代码，以及他们推出了Relay框架。相反Vuex不仅提出了这个框架概念，还实现并且提供了这个框架，让开发起来更加便捷 - 针对性的改进：如果你阅读过Vuex的官方文档的话，你会明白Vuex其实是针对Flux存在的一些缺陷而开发的。具体的缺陷其实我们在上一篇中提到过，例如不同的组件都维护自己的状态的话，不同组件之间想改变对方的状态其实会比较困难的。Vuex的解决办法也是上一篇中提到的那样，把state提升到全局的高度，尽可能是使用stateless组件。同时又引入了module等概念更利于代码的解耦和开发 - Vuex中保留了action与store的概念，并且引入了新的mutation。action和mutation广义上来说都是提交对store修改，不同的是action可以是异步的，并且大多数情况是在event handler中提交，通过$store.dispatch方法；唯一修改 Store 的地方只能通过mutation，而且mutation必须是同步的，直接对store进行修改，举例一个简单store的例子：