Posts
position: fixed与transform
最近使用antd的Affix组件，总是定位错乱，后来查到上级元素有使用动画效果的，用了transform属性，影响了position: fixed。可是去掉之后仍然会影响。最后找到上级元素还有个will-change: transform。
不光是transform会影响position: fixed，will-change指定的属性只要可能影响到fixed，也都会起作用。
Posts
fetch自动先发起option请求的问题
以前有些fetch在发起post请求之前总会先发一个option，等服务器返回头allow-methods里有post才会再发真正的post请求。没仔细研究还以为是post的特殊行为。最近遇到了get请求竟然也会先发option请求，但服务器没有正确返回头信息，导致请求中断。
仔细研究了一下以前不会先发起option请求区别发现在于只要有自定义的header放到fetch的option里，就一定会先试探发起一个option请求，不管是get还是post或其他什么请求方法。
Posts
数据到底应该前端还是后端处理
上家公司的后端同学，几乎是不会将数据做任何处理，大多数接口都是直接就是把数据库中的数据以数组形式输出，前端需要的、不需要的属性全有。以后端人员的思维就是，反正数据是给你了，你想怎么处理都行。前端处理业务逻辑多不说，还导致大量接口数据浪费和冗余。
现在公司的后端能力强，也容易沟通，常常是前端需要什么数据结构，就可以直接输出什么数据结构。
但个人认为数据要前端还是后端处理，得看具体情况。
例如树状菜单的输出。前端需要树状数据结构，如果要后端输出，可能这个接口需要多次数据库命中，或者后端一次性将数据拿出然后进行递归操作整理成树形结构。这种情况下，我认为后端接口还是直接输出数组方式较好。将计算任务前端化可以极大的减轻后端服务器内存与运算压力，等于是将运算分布到每个客户端上执行。如果是一些仅仅需要个总数计算的情况，就最好后端计算后直接输出数字比较好了，否则输出一大堆复杂结构的数组，前端也仅仅是计算一下数组的长度，太浪费带宽。
Posts
windows的vim对python的支持
在win上用vim，执行:version，看到有python和python3的支持，但装上python3.6却仍然不支持，令人十分困惑。
后来发现在vim中执行:py xxx，会有报错提示缺少python3.5.dll，原来是在编译的时候就和python的版本搭配固定了。赶紧装个python3.5就成了。
后记：win上各种不适应，就算折腾也得换回linux，下次再找活的时候先问清楚了，必须用windows的就pass掉。
Posts
package.json中的sideEffects: false
https://medium.com/webpack/webpack-4-beta-try-it-today-6b1d27d7d7e2最近webpack升级到了4，看了一下变更日志，支持package.json中的sideEffects: false。一开始没理解。
后来看了一下lodash-es就明白了，这个选项不是在项目本身的package.json中添加的，是在其他npm依赖包中需要的配置。
当npm包为纯函数时，加上这个可以让webpack在production模式打包时极大的减少文件体积。
在npmjs上查了一下package.json配置说明，目前还没有这项的说明，应该是个非标准配置。
Posts
setTimeout参数
今天看到一段代码setTimeout还有第三个参数，之前没见过。
看了一下mdn，是除了回调函数和延迟时间之后的参数都会被传入回调函数中。
顺带看了setInterval和setImmediate也是一样，可以通过更多的参数向回调函数中传入参数。
Posts
jquery与学习曲线
前两天公司年会，听了一句话：不谈价钱的比性能就是耍流氓。之前听过，是描述手机的价格和性能对比的，这次听到之后想到了一些工作上的事情。
头两年刚接触browserify的时候，当时刚将我的前端工程融入npm的海洋，感觉之前一直用jquery的自己太low了。
现在再结合上面那句话，在库与框架的选型上，价钱可比做学习时间成本，性能是该库可控的项目规模，周边第三方环境的支持与掌握之后coder可达到的开发效率。在轻松学习成本条件下，jquery还是挺不错的选择。
Posts
service worker的fetch事件和cache的match
早些时候看到在work service中可以拦截fetch从而起到缓存的作用。
这两天自己试了试，发现这个fetch不是狭义的原生fetch函数，浏览器发起的http请求，普通ajax都在被拦截之列。亏的我原来为了用service worker缓存还打算把原来qwest的请求换成fetch，看来是不用的。
cache和caches都有match方法，但cache的match经我试验是跨caches的key的，不是当前open的key的cache都能匹配到，只不过在then的回调中response是undefined。从api的定义上，感觉不应该是这样，如果match不到，应该reject才多啊。
caches的match也是跨key的，这个好理解。
参考