wangweida

1. ios中new Date中的日期字符串不能用-只能用/连接，比如new Date('2018/01/01') 2. ios中软键盘顶起页面导致布局变形在blur事件中加入window.scroll(0, 0) 3. ios中引入fastclick在某些页面中只有第一屏的点击事件才生效（至今没有找到原因），把整个页面包在一个高度100%的div内，使用div内的滚动条可解决。 4. 移动端熄后定时器不执行 ```javascript // 假设倒计时30s let initialTimeStamp = null; let timer = null; const initialCountdownTime = 30; let countdownTime = initialCountdownTime;...

react与vue的比较一直是一个比较引战与容易引起争议的话题，或许每个前端都或多或少的参与到过这场辩论中，但是在这场巨大的辩论中产出的有价值的内容却一直比较稀缺。在这里我无意再次引起争吵，只是结合我自己的经验希望尽可能客观的阐述一些我认为的两个框架上一些差别与优劣。事实上如果没有真的在生产环境中较多的使用过两个框架而只是根据文档与一些demo来做对比几乎是没有什么实际的意义的。我在前一年的工作中几乎只使用vue，因为当时上一家公司部门的技术栈只是vue，虽然我也学习了react并且根据文档做了一些demo，但当我当时真正去想知道react与vue之间的具体差别是什么从而去找一些react的文章来读时会发现,因为没有实践与系统的研究过react很难真正的弄清楚这两者的真正差异。而如今当我大概真正写了3个月左右的react后，最大的发现其实是很多差异你写着写着它自己就会慢慢的浮到水面上，所以建议部门技术栈宽松的同学还是多去尝试，弄清楚问题的最好的方式应该是自己试着解答它。 *以下只代表个人的意见，并不保证观点全部正确* ## diff、patch与update **react:** 在react中如果某个组件的状态发生改变，react会把此组件以及此组件的所有后代组件重新渲染，不过重新渲染并不代表会全部丢弃上一次的渲染结果，react中间还是会通过diff去比较两次的虚拟dom最后patch到真实的dom上。虽然如此，如果组件树过大，diff其实还是会有一部分的开销，因为diff的过程依然是比较以此组件为根的整颗组件树。react提供给我们的解决方案是`shouldComponentUpdate`，以此函数的返回结果来判断是否需要执行后面的diff、patch与update。再实际的开发过程中我们常常会用`pureComponent`来帮助我们做这一层逻辑判断，但需要注意的是`pureComponent`的`shouldComponentUpdate`也只是浅比较，假设比较的类型是object，如果object仅属性发生变化，但是其引用没发生变化那么`shouldComponentUpdate`会认为两者之间没有任何变化。  **vue:** vue的响应式使用的是`Object.defineProperty`api，并且由于在getter中实现了依赖收集，所以不会像react一样去比较整颗组件树，而是更加细粒度的去更新状态有变化的组件，同时`defineProperty`也不存在像`shouldComponentUpdate`中比较引用的问题。  **对比:** vue的更新要比react粒度要更细也更加不用去人为的关心，虽然react可以通过`shouldComponentUpdate`实现同样的效果，然而如果state的层级结构比较深那么相应的手动去优化这部分代码也会更加费力，所以在react中我们需要尽量保证整体结构的扁平，去让`pureComponent`帮助我们自动的对此作出优化。 ## 状态数据的更改方式 **react**: 由于react与redux推崇的都是函数式编程，所以类似的状态更改都类似如下代码 ``` state = { obj: {a: 1, b: 2}, arr: [1, 2, 3], }...

对于一个网站来说打开速度是一个很重要的指标，只是大部分时间内我们的精力可能都用来对付需求了，特别是当我们做的是一些内部的项目时，我们常常的会忽略了这一方面的优化。其实要对一个页面的打开速度做出一些比较常见的优化并没有想象中的困难，本文将带你做一些既不费力也不费时间的优化操作，这些操作中涉及到压缩，缓存，preload加载关键资源，prefetch缓存懒加载资源与一些引用组件的建议及常见的工具库处理。 ### 开启gzip压缩 当我们使用webpack打包并压缩js代码后，往往某些js（比如vendor）依然会很大，可能会达到1mb左右的大小，虽然以现在的带宽来说如果我们是pc端项目这也不是什么大问题，但是这里面明显是存在着相当大的优化空间的，gzip就是一种形式。 在浏览器的请求头里包含着这样一句话`Accept-Encoding:gzip, deflate`，这告诉我们浏览器是可以识别gzip压缩的，使用gzip压缩后的文件将大大减小，很多情况下甚至能压缩70%。现在的服务基本上都是使用nginx做转发的，对于我们来说开启gzip其实相当容易，只要配置如下的代码就可以了。 ``` server { gzip on; gzip_types text/xml text/css text/plain text/javascript application/javascript application/x-javascript; } ```   上图能看到没开启gzip时vendor近800k，而开启gzip后大概只有250k。 可以说如果我们连gzip都没有开启的话，其他任何优化都显得有点多余，因为大概没有另外一种优化方式能压缩如此高的比例。 ### 浏览器缓存 除了常见的gzip压缩外，另一个可以利用的优化点就是浏览器的缓存。我会顺带着介绍一下浏览器的缓存方式，但是不会过于详细，有兴趣的同学可以额外去找一些资料学习。 浏览器分为两种缓存，强缓存与协商缓存（也被称为弱缓存），其中协商缓存不用我们自己配置，下面我们通过连续两次刷新页面来观察一下协商缓存。  如上图，在第一次的请求中nginx的http响应头中携带了一个`Last-Modified:...

vue的数据是双向绑定的 但是vue的数据流是单向的

声明：本文章中所有源码取自Version: 2.5.13的dev分支上的Vue，不保证文章内观点的绝对准确性。文章整理自本周我在小组的内部分享。 我们目前的技术栈主要采用Vue，而工作中我们碰到了一种情况是当传入某些组件内的props被改变时我们需要重置整个组件的生命周期（比如更改IView中datepicker的type，好消息是目前该组件已经可以不用再使用这么愚蠢的方法来切换时间显示器的类型）。为了达成这个目的，于是我们有了如下代码 ```javascript btn { data() { return { show: true } }, methods: { handleClick() { this.show = false this.show = true } } } ``` 别笑，我们当然知道这段代码有多愚蠢，不用尝试也确定这是错的，但是凭借react的经验我大概知道将`this.show =...

```javascript var compose = function(f, g) { return function(x) { return f(g(x)) } } ``` 从右向左的数据流向都是先g()，然后f() 所以满足结合律 ```javascript var associative = compose(f, compose(g, h)) == compose(compose(f, g), h) ``` http://jsbin.com/wavusajipe/edit?html,js,console

有点遗憾学生时代始终没有真正的长时间玩过一款MMORPG，少了好多回忆

我们的世界看似很平滑的运行，但是其实内含很多暴虐的事情