工程化 | Last Stand

ECool 面试资料中的工程化分类，文章顺序与原站知识树一致。

前端性能监控

大纲我们会从以下三个方向来讲解埋点与监控的知识：什么是埋点？什么是监控？ JS 中实现监控的核心方案写一个“相对”完整的监控实例一、什么是埋点？什么是监控？在日常沟通中，我们经常会把【埋点】和【监控】放到一起说，但是它们在本质上是有一定的区别的： 1. 埋点埋点主要用于收集用户行为数据。在日常开发中，我们会通过在前端代码中插入代码或脚本的方式来实现埋点功能。埋点的主要作用就是：捕获特定用户行为（如点击、浏览、提交表单、页面跳转等）以及关键业务数据（如下单金额、商品类别等）在日常开发中，埋点的实现方案大致可以分为以下三大类：手动埋点：在代码中手动加入记录代码来捕获特定事件。自动埋点：利用 DOM 事件代理等技术来捕获页面上所有事件，从而减少手动配置。可视化埋点：通过工具界面标记需要采集的元素和事件，可以不用手写代码。 2. 监控而监控则主要关注系统的性能和稳定性。在日常开发中，我们会通过采集页面加载时间、资源请求、错误日志等数据的方式来实现前端监控。监控的主要作用就是：及时发现并定位页面性能瓶颈或代码异常，目的是为了保障系统不出 bug 在日常开发中，监控一般需要完成以下三大部分：性能监控：如：首屏加载时间、页面交互耗时、资源加载耗时等。错误监控：捕获 JavaScript 错误、网络请求失败、资源加载异常等。用户体验监控：收集白屏、卡顿等影响用户体验的问题等。区别总结维度前端埋点前端监控目标捕获用户行为数据监控系统性能、错误、稳定性数据类型用户点击、表单提交、页面跳转等页面加载时间、错误日志、卡顿情况等实现方式手动埋点、自动埋点、可视化埋点错误捕获、性能指标采集核心关注点用户行为、业务数据系统Bug、性能优化二、JS 中实现监控的核心方案根据上面所说，我们知道埋点和监控的目的存在不同，但是它们的思路确是有很多一致性的，其核心都是：获取关键的数据，发送（上报）给服务端，依据数据来解决其不同的目的。所以，无论是埋点也好，还是监控也罢，我们都需要获取关键位置数据。 1. 跟踪用户事件（点击、滚动等）定义通用跟踪函数（后续事件会通过该函数完成上报）：trackEvent 函数接收事件类型和事件详情，并上报到服务端。 // 用于记录或发送跟踪数据到服务器的函数 function trackEvent(eventType, details) { console.log(`Event: ${eventType}`, details); // 在控制台打印事件类型和详情 // 上报到服务端。 fetch('/测试接口地址', { method: 'POST', body: JSON.stringify({ eventType, details }) }); } 捕获按钮点击事件：获取 id 为 myButton 的按钮，并在其 click 事件上添加监听器。在按钮被点击时调用 trackEvent 函数，记录点击事件的类型（button_click）、按钮 ID 和时间戳。 ...

前端组件化开发

背景不知道你有没有遇到过以下场景: 页面逻辑越来越多,代码越来越庞大,写到后面难以 hold 住所有逻辑,很容易牵一发而动全身. 你负责的页面好好的突然出现问题,查到最后是别人代码影响. 同样的逻辑在多个地方重复书写,每次一改要改一批文件随着前端项目复杂度的急剧增加, 上面列出的几种场景就是传统开发中会出现的问题. 也是前端组件化出现的原因. 项目复杂度增加, 一个页面一个文件需要处理的内容过多. 重复性劳动多, 效率低质量差, 不可控组件化初探正是由于出现了这样的问题, 为了在越来越复杂的前端项目中提高开发效率和保证开发质量, 各路大神们开始通过各种方式来尝试解决问题. 曾经非常火的 jQuery 就基于自己建立了 jQuery 插件机制. 你可以将一些常用逻辑进行封装变成 jQuery 插件, 还可以将插件开源进行共享. 比如纯手写会吐血的日期时间选择器,轮播, 多级菜单等等. 你可以在这里浏览更多jQuery插件. jQuery 插件的用法通常是: $(".select").pluginName(config) 除了 jQuery 插件模式, 还有一种常见模式是对象模式. 这种模式现在仍然有很多优秀的库在被我们直接或者间接使用. 比如: swiper 对象模式的写法:  <div class="swiper-container">  <div class="swiper-wrapper">  <div class="swiper-slide">Slide 1</div> <div class="swiper-slide">Slide 2</div> <div class="swiper-slide">Slide 3</div> ... </div> </div> <script src="path/to/swiper.min.js"></script> <script> var mySwiper = new Swiper ('.swiper-container', { direction: 'vertical', loop: true, }) </script> 对象模式通过配置创建对象, 通常创建对象的参数中有一项是元素/元素选择器, 通过js代码将逻辑与这个元素紧密绑定. ...

单页面架构

传统的多页面应用构建方式：纯服务端渲染，前后端不分离，使用jsp,jade,’ejs’,’tempalte’等技术在后台先拼接成对应的HTML结构，然后转换成字符串，在每个对应的路由返回对应的数据（文件）即可 Jade模版服务端渲染，代码实现： const express= require('express') const app =express() const jade = require('jade') const result = *** const url path = *** const html = jade.renderFile(url, { data: result, urlPath })//传入数据给模板引擎 app.get('/',(req,res)=>{ res.send(html)//直接吐渲染好的`html`文件拼接成字符串返回给客户端 }) //RestFul接口 app.listen(3000,err=>{ //do something }) 使用jQuery等传统库绘制的前端页面传统前后端不分离，服务端渲染的优缺点：优点： SEO友好，因为返回给前端的是渲染好的HTML结构，里面的内容都可以被爬虫抓取到。对于一些应用性能等要求不高的项目，比如某个公司的静态网页，内容很少的情况下，直接一把梭就好，不用再搭建工程化的环境等对于后端程序员（全干工程师）来说，不用去特意学习前端框架，公司也不用特意去招聘前端兼容性好，传统服务端渲染多页面应用吐出来的都是字符串，HTML结构缺点：如果项目很大，不利于维护，据我所知，目前很多云计算公司，还有不少都是使用非单页面应用，例如一个几十万行的项目是用jQuery写的，如果注释和文档不是非常齐全，那么真的会无从下手性能和用户体验，不能跟单页面应用相比后期迭代，升级空间不大，目前大部分写得比较好的库，都建立vue,react等框架基础上，他们都有一套自己的运行机制，有自己的生命周期，并且不像传统的应用，还加上了一层虚拟DOM以及diff算法现在类似Ant-Design-pro这样的开箱即用的库已经很多，单页面应用的学习和开发成本已经很低很低，如果还在使用传统的技术去开发新的应用，对于开发人员多内心来说也是一种折磨。这里并不是说多页面应用不好，只能说各有各自的好，单页面应用如果通过大量的极致优化手段，是可以从不少方面跟原生一拼。目前的单页面应用：只有一张Web页面的应用，是一种从Web服务器加载的富客户端，单页面跳转仅刷新局部资源，公共资源(js、css等)仅需加载一次，常用于PC端官网、购物等网站其实只有一个空的DIV标签，其他都是js动态生态的内容单页面应用实现步骤：代码实现：首先是一个静态模板文件 index.html <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <meta http-equiv="X-UA-Compatible" content="ie=edge"> <title>Document</title> </head> <body> <div id="root"></div> </body> <script> </script> </html> 在vue react框架的入口文件中指定对应的渲染元素： import React from 'react; import ReactDOM from 'react-dom'; ReactDOM.render( <App/>, document.querySelector("#root") ) 引入react-router或者 react-router-dom，dva等路由跳转的库配置路由跳转 <HashRouter>//这里使用HashRouter <ErrorBoundary>//React错误边界 <Switch> <Route path="/login" component={Login} /> <Route path="/home" component={Home} /> <Route path="/" component={NotFound} />//404路由或者重定向都可以 </Switch> </ErrorBoundary> </HashRouter> 单页面应用所谓路由跳转，其实最终结果就是：浏览器的url地址发生变化，但是其实并没有发送请求，也没有刷新整个页面根据我们配置的路由信息，每次点击切换路由，会切换到不同的组件显示，类似于选项卡功能的实现,但是同时url地址栏会变化分为HashRouter和BrowserRouter两种模式自己实现一个粗略的路由跳转：自己实现传统的Hash模式跳转： hash 就是指 url 后的 # 号以及后面的字符。例如www.baidu.com/#segmentfault,那么#segmentfault就是hash值 ...

状态管理工程化

状态管理是一个前端界老生常谈的话题了，所有前端框架的发展历程中都离不开状态管理的迭代与更替，对于react来说呢，整个状态管理的发展也随着react架构的变更和新特性的加入而不停的做调整，作为一个一起伴随react成长了快5年的开发者，经历过reflux、redux、mobx，以及其他redux衍生方案dva、mirror、rematch等等后，我觉得它们都不是我想要的状态管理的终极形态，所以为了打造一个和react结合得最优雅、使用起来最简单、运行起来最高效的状态管理方案，踏上了追梦旅途。为何需要状态管理为何需要在前端引用里引入状态管理，基本上大家都达成了共识，在此我总结为3点：随着应用的规模越来越大，功能越来越复杂，组件的抽象粒度会越来越细，在视图中组合起来后层级也会越来越深，能够方便的跨组件共享状态成为迫切的需求。状态也需要按模块切分，状态的变更逻辑背后其实就是我们的业务逻辑，将其抽离出来能够彻底解耦ui和业务，有利于逻辑复用，以及持续的维护和迭代。状态如果能够被集中的管理起来，并合理的派发有利于组件按需更新，缩小渲染范围，从而提高渲染性能已有状态管理方案现状 redux 遵循react不可变思路的状态管理方案，无论从git的star排名还是社区的繁荣度，首推的一定是redux这个react界状态管理一哥，约束使用唯一路径reducer纯函数去修改store的数据，从而达到整个应用的状态流转清晰、可追溯。 image.png mbox 遵循响应式的后期之秀mbox，提出了computed、reaction的概念，其官方的口号就是任何可以从应用程序状态派生的内容都应该派生出来，通过将原始的普通json对象转变为可观察对象，我们可以直接修改状态，mbox会自动驱动ui渲染更新，因其响应式的理念和vue很相近，在react里搭配mobx-react使用后，很多人戏称mobx是一个将react变成了类vue开发体验的状态管理方案。 image.png 当然因为mbox操作数据很方便，不满足大型应用里对状态流转路径清晰可追溯的诉求，为了约束用户的更新行为，配套出了一个mobx-state-tree，总而言之，mobx成为了响应式的代表。其他剩下的状态管理方案，主要有3类。一类是不满足redux代码冗余啰嗦，接口不够友好等缺点，进而在redux之上做2次封装，典型的代表国外的有如rematch，国内有如dva、mirror等，我将它们称为redux衍生的家族作品，或者是解读了redux源码，整合自己的思路重新设计一个库，如final-state、retalk、hydux等，我将它们称为类redux作品。一类是走响应式道路的方案，和mobx一样，劫持普通状态对象转变为可观察对象，如dob，我将它们称为类mobx作品。剩下的就是利用react context api或者最新的hook特性，主打轻量，上手简单，概念少的方案，如unstated-next，reactn、smox、react-model等。我心中的理想方案上述相关的各种方案，都各自在一定程度上能满足我们的需求，但是对于追求完美的水瓶座程序猿，我觉得它们终究都不是我理想的方案，它们或小而美、或大而全，但还是不够强，不够友好，所以决定开始自研状态管理方案。我知道小和美、全、强本身是相冲突的，我能接受一定量的大，gzip后10kb到20kb都是我接受的范围，在此基础上，去逐步地实现美、全、强，以便达到以下目的，从而体现出和现有状态管理框架的差异性、优越性。让新手使用的时候，无需了解新的特性api，无感知状态管理的存在，使其遁于无形之中，仅按照react的思路组织代码，就能享受到状态管理带来的福利。让老手可以结合对状态管理的已有认知来使用新提供的特性api，还原各种社区公认的最佳实践，同时还能向上继续探索和提炼，挖掘状态管理带来的更多收益。在react有了hook特性之后，让class组件和function组件都能够享有一致的思路、一致的api接入状态管理，不产生割裂感。在保持以上3点的基础上，让用户能够使用更精简且更符合思维直觉的组织方式书写代码，同时还能够获得巨大的性能提升收益。为了达成以上目标，立项concent，将其定义为一个可预测、零入侵、渐进式、高性能的增强型状态管理方案，期待能把他打磨成为一个真真实实让用户用起来感觉到美丽、全面、强大的框架。说人话就是：理解起来够简单、代码写起来够优雅、工程架构起来够健壮、性能用起来够卓越…… ^_^ concent.png 可预测 react是一个基于pull based来做变化侦测的ui框架，对于用户来说，需要显式的调用setState来让react感知到状态变化，所以concent遵循react经典的不可变原则来体现可预测，不使用劫持对象将转变为可观察对象的方式来感知状态变化（要不然又成为了一个类mobx……）, 也不使用时全局pub&sub的模式来驱动相关视图更新，同时还要配置各种reselect、redux-saga等中间件来解决计算缓存、异步action等等问题（如果这样，岂不是又迈向了一个redux全家桶轮子的不归路….. ）吐槽一下：redux粗放的订阅粒度在组件越来越多，状态越来越复杂的时候，经常因为组件订阅了不需要的数据而造成冗余更新，而且各种手写mapXXXToYYY很烦啊有木有啊有木有，伤不起啊伤不起…… 零入侵上面提到了期望新手仅按照react的思路组织代码，就能够享受到状态管理带来的福利，所以必然只能在setState之上做文章，其实我们可以把setState当做一个下达渲染指令重要入口（除此之外，还有forceUpdate）。 setState，下达更新指令仔细看看上图，有没有发现有什么描述不太准确的地方，我们看看官方的setState函数签名描述: 代码语言：txt AI代码解释 setState<K extends keyof S>( state: ((prevState: Readonly<S>, props: Readonly<P>) => (Pick<S, K> | S | null)) | (Pick<S, K> | S | null), callback?: () => void ): void; 通过签名描述，我们可以看出传递给setState的是一个部分状态(片段状态)，实际上我们在调用setState也是经常这么做的，修改了谁就传递对应的stateKey和值。 ...