书中注重介绍了greensock这个工具，什么时候应该用css，什么时候应该用js库 以及greensock强大的动画补间功能 书中理论偏多，代码不是很完整，不如直接看最新文档。 https://greensock.com/

有亮点不同 不会下载Chromium. 不会识别一堆以PUPPETEER_开头的环境变量。 其他的地方都一样，按说只要把所有require(puppeteer)的地方都换成require('puppeteer-core')即可。 针对绝大多数用户，其实都已经安装了chrome，每次安装为了puppeteer都要下载一个巨大的Chromium，在国内的网络环境下十分耗时。 可问题是一些依赖的第三方package里面用的是require(puppeteer)。 这种情况推荐使用modules-alias工具登场。 用别名的方式将系统中的puppeteer 都置换为puppeteer-core 运行例子: jest-with-puppeteer-core

最近遇到conventional-changelog不能生成最新变更日志的问题。 经过排查发现，是因为gitflow和conventional-changelog一起使用时，应先升级package.json中的version，生成changelog之后再进行gitflow的release操作，否则最新的git标签与package.json中的version相同，则不会生成changelog。

我的编辑器里，既装了eslint的插件，也装了prettier的插件，然后，这两个工具都其作用并能自动修正文件了，还有什么问题呢？ 我之前的eslint配置是这样的 <br /> extends: [<br /> 'airbnb',<br /> 'prettier',<br /> ],<br /> prettier有其自己的配置文件，在eslint中通过eslint-config-prettier一起生效，使这两个规则不会冲突。 问题在于，每次文件保存，eslint和prettier会先后两次修正文件，引起两次写操作，结果可坑会导致开发环境webpack或jest运行多次。 之前没有在意这个细节，最近有空打算彻底解决一些之前觉得不对劲的地方。 正确的配置应该是，添加eslint-plugin-prettier，并且在编辑器中禁用prettier插件，使文件保存是，仅eslint修正即可，eslint通过这个plugin识别prettier.config.js配置来集成规则。 新的配置如下 <br /> extends: [<br /> 'airbnb',<br /> 'prettier',<br /> ],<br /> plugins: ['prettier'],<br /> rules: {<br /> 'prettier/prettier': 'error'<br /> }

在前端项目中，有大量的import，webpack的resolve.alias为此提供了很大的方便。为项目的一些常用路径定义别名，可以极大的简化代码并提高代码可读性。 eslint有一个plugin– eslint-plugin-import，能检测import的package是否合规，为了与webpack的alias一起工作，于是又有了一个新工具— eslint-import-resolver-webpack，使eslint可以识别webpack中定义的别名引用路径。 https://www.npmjs.com/package/eslint-import-resolver-webpack 我最初使用的是文档中省事的写法，直接在.eslintrc.js中使用了webpack的文件名 config:‘webpack.config.js‘vim通过ale插件，支持eslint语法检查，是随输入随检查。 从此开始了编译的噩梦。 只要vim修改了文件内容，文件还没保存，但jest –watch 或 webpack-dev-server进程就会认为文件有改动，疯狂的重新编译，或重新运行测试。 一开始没意识到问题，还以为正常就这样，后来发现用其他编辑器在文件还没有保存的时候，修改文件内容是不会出发文件监听更新事件的。 首先定位错误到vim，经过挨个插件排查发现问题出在ale上，只要每次ale调用eslint，就会触发文件更新。实际用ls -l –full-time检查了一下发现eslint并没有更新文件的任何属性。 于是定位到eslint，对比了一下tslint，发现tslint不会触发文件更新事件。以为是eslint的bug或默认行为？于是开始排除eslint的插件，发现只要加载了webpack的配置，就会触发文件更新。终于定位到错误。 最后，将webpack中的alias部分提取到独立的文件，分别由.eslintrc.js与webpack.config引入使用，解决该问题。

<li> constructor(props) <ul> <li> 不能在这里setState。 </li> <li> 只有这里可以直接给this.state赋值。 </li> <li> 不能在这里调用有side-effects作用的函数，如果有需要，在componentDidMount里调用。 </li> <li> 不要在这里用props的值生成state内容。 </li> </ul> </li> <li> componentDidMount <ul> <li> 此时组件已经载入，发起request请求，进行setState操作。 </li> <li> 可以在此进行一些事件订阅。 </li> </ul> </li> <li> componentDidUpdate(prevProps, prevState, snapshot) <ul> <li> 在每次更新state或props之后调用，在第一次render时<strong>不</strong>调用。 </li> <li> 此处禁用setState（文档上说尽量避免，但我认为应该禁用，如果有逻辑必须在此处调用setState，那么有必要重新梳理逻辑，一定是哪里想错了）。 </li> <li> 如果shouldComponentUpdate返回false，则不会被调用。 </li> <li> 如果有getSnapshotBeforeUpdate，则getSnapshotBeforeUpdate的返回值会作为第三个参数传入。 </li> </ul> </li> <li> componentWillUnmount <ul> <li> 在此进行一些取消订阅或其他的清扫操作。 </li> <li> 此处禁用setState。 </li> </ul> </li> <li> shouldComponentUpdate(nextProps, nextState) <ul> <li> return false则不会重新渲染，可在此处改善渲染性能避免重复渲染。 </li> <li> return false会阻止UNSAFE_componentWillUpdate(), render(), and componentDidUpdate() 这三个生命周期函数的运行。 </li> <li> 在绝大多数情况下，不应手动实现该函数，应依赖react本身的默认更新行为。 </li> </ul> </li> <li> getSnapshotBeforeUpdate <ul> <li> 在每次组件重渲染前调用，可获取当前dom内容。 </li> <li> 应有返回值。 </li> </ul> </li> <li> componentDidCatch(error, info) <ul> <li> 捕获前端组件错误，通常只在最外层组件实现一次即可。 </li> <li> 以下错误不在该函数捕获范围内： </li> <li> dom事件错误。 </li> <li> 异步错误。 </li> <li> 服务端渲染。 </li> <li> 该函数本身又抛出的错误。 </li> </ul> </li> <li> 即将废弃 <ul> <li> UNSAFE_componentWillMount </li> <li> UNSAFE_componentWillReceiveProps </li> <li> UNSAFE_componentWillUpdate </li> <li> 都是去掉UNSAFE的同名函数的别名，即将废弃，无论是有没有UNSAFE前缀，别用就对了。 </li> </ul> </li> <li> 非生命周期的实例方法 <ul> <li> setState(updater[, callback]) </li> <li> setState可能同步或异步执行，因此不保证调用后的state为最新状态。 </li> <li> updater除了对象，还可以是函数，例如：<br /> <code>&lt;br /> this.

学习笔记 service worker仅能运行在https或localhost本地模式下的http环境中。 利用pwa的caches可以为web程序添加一层shell，或拦截并替换或加工请求。比如根据浏览器兼容，替换webp格式图片。 利用web数据库缓存提交请求，待连线时再与服务器同步。 讲解stream概念。结合caches自建流式渲染。 最后的trouble shooting很有用，有问题时应该先从在这里找找答案。 最后还有个展望web未来，说了一些es的蓝牙api，社交分享功能。通用支付功能，图像识别功能，二维码识别的例子。

RxJS + React + Redux (what we call the 3R) architecture 3R这个概念还行，在这本书里头一次见。 Learning to use a new tool is as important as learning when not to use it. 与学习如何使用一项工具一样重要的是，知道什么时候该用它。 看到consumer pull和iterator push模式 对generator又加深了一些理解其应该存在的使用场景 rx生成的订阅模型，比事件模型的更容易清理，unsubscribe，对内存释放友好 hot与cold的observable对象的区别，push与pull。 There is no onesize-fits-all solution to every problem 一句话说，没有银弹。 看完之后，对rxjs总算有了个靠谱的了解。可惜看到一半左右再上的官网看，发现已经升级版本6了，书里讲的都是5。 好在5和6除了函数式风格api的变化，其他相差不多。