上一篇文章分析 Babel 编译流程的时候，提到 Babel 会将 JS 代码转换成 AST（抽象语法树）。这种行为是一种通用的行为，无论什么编程语言都会将源代码解析成 AST，AST 不是 Babel 特有的，更不是 JS 特有的。
为什么要这么做呢？原始的 JS 文件是计算机是无法理解的，计算机也很难直接修改 JS 代码，但是转换成 AST 后，由于 AST 本质上是一组表示程序结构的对象，我们可以通过修改这个对象，间接的实现修改代码的目的。chrome V8 引擎也是这么做的，比起 Bable 更进一步的是，V8 引擎会编译 AST 生成字节码。
Parser的过程分为两步，第一步，词法分析，也就是编译原理中的有限状态机，将一段代码拆分为一个个Token，第二步，语法分析，将Token数组，转换为AST树。
这次我就看一下源码，简单分析一下这个过程。
最近接触了一点关于Babel的知识，产生了一些兴趣，于是就打算看一看Babel的原理，然后总结学习下，这东西太复杂了，就分多个博客来写吧，这篇博客主要讲两件事，第一，简单描述下Babel的工作流程，第二，简单介绍下Babel的项目结构，也就是微内核模式。
这几个周算是把慕课上400大洋买的关于React最佳工程实践的课程听的七七八八了，剩下的主要就是两部分，一部分是一些交互的优化，还有一点点关于性能的优化，这两部分我感觉不是很急，可以在我的工作中去慢慢体会。
我目前在react方面的当务之急是，我只学了实践，但是很多东西我都不知道为什么要这样写，比如为什么要setState才能更新，hook是如何生效的，react fiber是什么等等，不了解这些，我感觉自己的react还浮在半空中，没有比较好的落地，所以下一步的计划就是去了解一下原理，至于是否要去阅读源码，下一步再说。
这篇博客的主要内容是读了一下几位国内外大佬的博客，先对react的fiber有个大概的了解
在接触Redux的内容时，不免接触了一些它的配套工具，一时之间被这些工具搞得有些混乱，不知道哪个是哪个，他们各自的作用与联系。这篇文章就来简单记录下我的查询结果。
首先说一下这几个工具，redux，redux-thunk，redux-toolkit，react-redux。
这周在工作中需要开发一个npm的package，是辅助其他已有的pacakge。整个仓库采用了monorepo的形式，记录一下整个过程中踩的坑和学到的新技术
目前，跑在浏览器端的web IDE产品越来越多，按照他们的功能特性来做划分的话，目前的web IDE可以分为两种，一种是将本地IDE的功能基本原封不动的迁移到了web端的IDE，像是目前最流行的前端IDE VS Code，借助于云+容器化的能力，在浏览器端VS Code拥有着跟本地IDE几乎完全一样的功能；还有一种web IDE则更多的聚焦于 页面开发与实时的代码解析、编译、预览的呈现，代码打包构建的实现则并不局限于在服务端（如基于Docker容器等）实现，部分的产品实现了 基于浏览器端的代码编译、打包、构建、运行的功能，而这一切在我们原来的开发体系里是只有基于 本地IDE+Node本地构建、本地服务+浏览器访问预览才有的能力。此类产品的代表是CodeSandbox，codepen，StackBlitz，JSFiddle等。
也就是说前者只是将代码的编辑放在了web段，其实背后借助了云去做代码的存储，项目的编译打包运行等，这种方式下，我们最后得到的和本地开发并无区别，对我们的区别只是不用特地下个编辑器了。
后者则是将一部分的编译打包功能以及最终的运行放在了浏览器，且由于浏览器的限制，其所能支持的应用大小是有限制的（PS：最近遇到一个问题，看错误应该是代码大小超过了500K，留个坑，留待以后解决，嘿嘿）