咯咯哒已经半岁多了，小家伙一天天长大，我在想除了物质上的保证，我还有什么可以给他的。于是我尝试着写下我近三十年的人生经验中，可以作为人生建议的一些东西送给他。

上一篇我们聊到，如果要实现组件的跨端复用，那么必然就要复用逻辑层。回过头来，审视过去几年前端的发展，我们可以看出，由于Vue,React框架等的兴起，前端越发重View层，基本都是以视图组件为主，围绕用户交互的纬度组织代码。比如下面这个组件：

简单来说，中间件就是对store 的dispatch方法进行包装扩展。它在 dispatch action 和到达 reducer 的那一刻之间提供了逻辑插入点。可以使用 Redux 中间件进行日志记录、异常监控、与异步 API 对话、路由等。具体可以见官方文档 Middleware 中间件 | Redux 中文官网

我们的页面主要由两部分组成：1.逻辑 2. 视图如果想要跨端复用的话，那么可以从上面这两方面入手一般跨端的页面有几种情况需求一样，对应页面中的逻辑也就完全一样，视图层只是使用的UI组件名字不一样(h5中写div,小程序中写View)，需要完全复用逻辑层需求部分一样，对应起来就是逻辑和UI组件也是只有部分的差异，需要复...

Tree shaking 是一个术语，通常用于描述移除 JavaScript 上下文中的未引用代码(dead-code) 更加详细的介绍可以移步官方文档Tree Shaking | webpack 中文文档 简单来说tree shaking分三步

我们在使用taro 和 @freud/http（公司内部项目，基于axios做的二次开发） 的时候，发现构建产物中多了很多没有用的包，导致产物变大了150kb左右。经过一番搜索，发现是因为taro小程序不能解析package.json中的browser module等字段，而@frued/http 因为要同时支持web和小程序环境，而axios中就有browser属性：

我们项目中的页面(主要是后台系统)功能大多类似，每次新增的时候，会写很多相似的代码。所以利用一个可配置的模板来生成文件代码是一个可以提高效率的方式。在网上找了下现有的vscode插件，发现都比较轻量(如Simple React Snippets)，所以就自己写了一个偏定制化的配置。

最近在工作中，听闻同事抱怨在内部平台上构建项目很慢。初步分析了一下，原因无非两个：1. 项目本身较大，导致构建时间较长 2. 我们的构建部署流程是：一次build qa和prod环境2个包，然后再分别部署不同环境的构建产物，无疑这样会导致整体构建时间变长。前者不是本文的重点，本文只讨论第二点:即如何 一次构建多环境部署。

这段时间在琢磨自己手写一个构建工具，不过在这之前，我们先试着梳理一下webpack的理念，毕竟它山之石可以攻玉，有助于我们想好该如何设计自己的项目。

获取异常在 Sentry的前端异常监控方案中之前我们说过，Sentry的全局异常获取方式有2种，window.onerror以及unhandledrejection。异常数据的处理以unhandledrejection为例 globalhandlers.ts中 {代码...} 整体流程分为以下几个模块讲解兼容处理 {代码...} 这一块都是在做兼容性处理，适配不同浏览器中的错误类型过滤条件 ...

就目前了解到的，主流的数据上报方式 而言，Sentry还是采用的ajax上报的方式。为了有更好的兼容性，在初始化的时候会去判断浏览器是否支持fetch，支持就使用fetch否则是xhr。同时也支持自定义的上报方式，且优先级会高于fetch和xhr

最近在做业务的时候，了解到了一个叫imove开源项目，比较适合我现在做的业务 ，便了解了一下，发现它也借鉴了Vite的思想：即利用浏览器支持ESM 模块的特点，让我们的import/export 代码直接在浏览器中跑起来。结合之前社区的讨论，同时也让我对Vite有了兴趣，遂对它的代码进行了一些研究。如果你对Vite还没有大概的了解...

Sentry的异常信息收集方式分为两种，一种为自动收集，另一种为业务项目中手动收集，我们暂时只研究自动收集的方式。异常监控收集的数据类型首先定位到代码的instrument方法，可以看到全局自动收集的数据类型有以下几种：consoledomxhrfetchhistoryerrorunhandledrejection {代码...} 接下来我们重点研究一下 error unhan...

之前在做前端监控的时候，研究了一下sentry的源码，颇有启发。这次又准备做前端监控，所以借此机会想深入了解一番。但是此之前，我想谈谈自己对前端监控的一些思考。

Axios 是一个基于 Promise 的 HTTP 客户端，同时支持浏览器和 Node.js 环境。它是一个优秀的 HTTP 客户端，被广泛地应用在大量的 Web 项目中。具体介绍可见官方文档

对于webapck，因为在工作中一直接触到，之前也有写过一些相关的文章。但是一直都是处于怎么用好它的阶段。今天突然好奇了一下，它的内部原理是怎么样的，故写下次文档，作为一点积累，后面会陆续更新。(一些概念因为在上面的文章中写过，就不再赘述)

废话是另一种没意义的区分。假设你有一个 Product 类。如果还有一个 ProductInfo 或ProductData类，那它们的名称虽然不同，意思却无区别。Info和Data就像a、an和the一样，是意义含混的废话

基于数据驱动的做事原则，我们需要统计线上项目中，用户的行为和使用情况，从而更加贴近用户，为我们的决策提供相应的数据支持，更好地迭代升级我们的产品，创造用户价值。既然如此，研发同学以及业务方对前端监控的诉求应该有：

服务端渲染(Server Side Render)，其实非常好理解，就是服务器返回一堆html字符串，然后让浏览器显示。与服务端渲染相对的是客户端渲染(Client Side Render)。

将精力放到关键性的指标之上通常我们讲的性能优化就是缩短用户可见区域的内容的加载时间，一般来说就是我们的首屏。因为它和用户体验息息相关，而不是只关注于整个页面的加载时间（例如 onLoad 和 DOMContentLoaded 时间）。当然如果你网站确实很庞大，你也可以将精力放到减少白屏时间上，因为一个好的 loading 动画能让...

官方文档中的说明：[链接]cacheDirectory：默认值为 false。当有设置时，指定的目录将用来缓存 loader 的执行结果。之后的 webpack 构建，将会尝试读取缓存，来避免在每次执行时，可能产生的、高性能消耗的 Babel 重新编译过程(recompilation process)。如果设置了一个空值 (loader: 'babel-loader?cacheDirectory') 或...

DllPlugin结合DllRefrencePlugin插件的运用，对将要产出的bundle文件进行拆解打包，可以很彻底地加快webpack的打包速度，从而在开发过程中极大地缩减构建时间。webpack官网关于 DLLPlugin 以及DllRefrencePlugin解释[链接]

1.速度分析工具 speed-measure-webpack-plugin，可以看到每个loader和插件的耗时2.体积分析工具 webpack-bundle-analyzer ，可以看到打包的文件大小通过分析工具，就可以准确地知道我们构建的瓶颈在哪里。

插件是webpack的“支柱”功能，他在构建流程里注入钩子来实现。在webpack运行的声明周期中会广播许多事件，plugin可以监听这些事件，在特定的时刻调用webpack提供的API执行相应的操作。

官网解释：bundle由chunk组成，其中有几种类型（入口 entry chunk child chunk）。通常，chunk会直接对所输出的bundle。但是有些配置并不会产生一对一的关系。