vite和SnowPack简介
目前主流的JS开发构建工具有两个——webpack用于前端项目的打包,rollup用于库的打包。
但是,随着ESM规范被各大主流浏览器支持,JS模块化已经成为了浏览器的内置功能,因此JS代码实际上已经不需要打包了。这使得市面上出现了snowpack,vite等主打budless(不打包)概念的开发构建工具。
什么是Vite?Vite是EVAN YOU开发的下一代前端开发与构建工具:
在开发模式下
首先,vite启动开发模式时会根据项目中的依赖项使用esbuild进行预构建,这主要是为了:
将commonjs模块转换为ESM模块;
将每个依赖项打包构建为一个文件,防止lodash-es这种库在ESM引入时产生瀑布请求(大量瞬时并发的文件get请求);
因为这些依赖项变动较少,这些依赖项在预构建后会被缓存至.vite目录中。
之后,vite对项目代码并不做处理就直接启动开发服务器,利用浏览器对ESM的支持就可以打开项目。
在开发模式下,vite能够做到如此快速主要得益于以下方面:
对于需要打包构建或编译转换的文件使用了esbuild,esbuild基于go语言编写,其性能是传统J ...
国际化方案调研与应用
背景国际化(internationalization, 简称i18n)是一个能够让产品适应多地区和多语言的能力。对于国际化公司而言,产品的使用者往往是来自不同国家、不同地区的用户人群,对平台使用语言的要求不尽相同。因此,有必要实现一套前端国际化通用方案,旨在提供语言环境适配和切换的能力,降低用户阅读门槛,从而提升平台使用体验和工作效率。
三、目标针对目前各平台项目没有提供国际化功能,将制定一套前端通用国际化方案,帮助平台开发者快速接入国际化功能而无需手动实现。
结合目前技术选型和业务情况,国际化方案需要支持的能力包括以下几点:
支持多语言展示与切换(核心)默认语言、多类型语言选择与切换
支持翻译资源管理非硬编码,业务方可以通过线上平台维护翻译资源,支持线上修改资源、扩展多语言,从而降低维护成本。
支持cli初始化国际化配置cli初始化项目时支持添加国际化功能(可选)
支持自动识别/切换语言识别地区,自动切换到当前地区对应的语言环境
兼容UI库国际化UI库内置组件的国际化同步
四、理想技术模型
五、开源方案(运行时)1. react-intlreact-intl是format ...
React Keep-Alive设计方案
一、概述为了在React中实现类似Keep-Alive的组件行为,之前对市面上目前所存在的一些主流实现库及其原理进行了调研总结。通过对比选择,最终得出以下三个实现方案是我们认为初步可行的:
方案
优点
缺点
组件级别缓存:react-activation
缓存粒度细
破坏DOM结构导致React 合成事件冒泡失效(基本无法修复)
路由级别缓存:react-router-cache-route
使用人数多、范围广
只支持react-router@5.x.x
路由级别缓存:自研react-router@6 Keep-Alive
支持最新的react-router@6.x.x
需要自己实现,有一定成本
可以看到,目前并没有一个完 ...
Git 回滚规范
结论开发流程中,不免会遇到需要回滚 master 代码的时候。关于如何回滚,我们将统一采用 revert 方式进行回滚,以保留之前错误的提交,便于进行复盘与 CR
回滚步骤如下
git checkout master —— 分支切换到 master
git pull —— 更新 master 代码为最新
从 master 分支中开一个 feat 分支
git log —— 查询提交记录,并找到需要回滚的 commit id
git revert 或者 git revert -m 1 faulty merge —— 回滚
push & 提交与 master 分支的 mr
Checkout、reset、revert 的择决Checkoutgit checkout 是一种便捷的方式,来将快照「解包」到你的工作目录上去。 git checkout 可以检出提交、也可以检出单个文件甚至还可以检出分支
1git checkout commitId
检出 commitId 对应的提交,你会发现当前工作目录和commitId完全一致,你可以查看这个版本的文件编辑、运行、测试都不会被保存 ...
lockfile效果调研
NPMnpm install
版本
package.json
package-lock.json
5.0.x
忽略
为准
5.1.0 - 5.4.1
为准
忽略
>=5.4.2
两者版本不兼容时
两者版本兼容时
5.0.x 忽略package.json, package-lock.json完全锁定;
5.1.0 - 5.4.1 只要package.json中的更新了, 就无视package-lock.json下载新版本(并更新package-lock.json);
>=5.4.2 根据package.json, package-lock.json版本是否兼容共同确定,兼容以package-lock.json为准,不兼容以package.json为主(并更新package-lock.json);
npm ci
推荐CI打包时使用;
使用npm ci时必须有package-lock.json;
npm ci确保不会更改package-lock.json中的版本,当package.json, package- ...
前端项目支持TS
vite 默认就支持 TS, 不过react需要加一些配置。
创建 tsconfig.json 如果有 jsconfig.json的话, 就把jsconfig改名为tsconfig
添加ts配置,最终如下参考
1234567891011121314151617{ "compilerOptions": { "jsx": "react-jsx", "allowJs": true, "isolatedModules": true, "baseUrl": "./", "paths": { "@/*": ["src/*"], "common/*": ["src/common/*"], "config/*": ["src/config/*&q ...
nodejs-snowflake分布式ID
雪花算法
https://www.npmjs.com/package/nodejs-snowflake
Number or String首先需要确定全局唯一ID是整型还是字符串?如果是字符串,那么现有的UUID就完全满足需求,不需要额外的工作。缺点是字符串作为ID占用空间大,索引效率比整型低。
如果采用整型作为ID,那么首先排除掉32位int类型,因为范围太小,必须使用64位long型。
数据库自增ID缺点数据库自增ID的缺点是数据在插入前,无法获得ID。数据在插入后,获取的ID虽然是唯一的,但一定要等到事务提交后,ID才算是有效的。有些双向引用的数据,不得不插入后再做一次更新
snowflake分布式ID解决方案
SnowFlake可以保证:
同一台服务器所有生成的id按时间趋势递增
整个分布式系统内不会产生重复id(因为有datacenterId和workerId来做区分)
业界mysql的实践方案调研
业界mysql的实践方案调研分类现存于 Node.js 和 TypeScript 生态环境中的数据库工具可以分为三类。
手写 SQL自己手写 SQL(比如使用 pg 和 mysql 这样的 Node.js 数据库驱动)当然可以完全控制数据库操作,但是,生产力却不高,而且会遇到很多细碎的事情(如手动处理链接、操作模板)。
这种方式的另一个问题在于你获取的查询结果时不是类型安全的。你可能会手动书写这些查询结果的类型,但这会花费大量的时间;另外,如果你对数据库进行了改动,你的类型文件也需要保持一致才行,这也会花费大量时间。
此外,手动构造 SQL 字符串的时候,编辑器没法给你任何提示(只能提示一些 SQL 关键字),效率极差。
特点:控制力极强,生产力弱
SQL 构造器有不少人用的解决方案是使用 SQL 构造器(如 knex.js,SQL Bricks)以提高生产力。这种工具为构建 SQL 语句提供了封装层次较高的 API。
但最大的问题在于这种工具需要开发者从 SQL 的角度来对待数据,但应用数据往往是关系型的对象,这就会导致了数据在认知层面与实际层面的差异。开发者不得不经常切换思维模型才 ...
NestJS 中使用esm
NestJS 中使用esm先说结论修改tsconfig 如下,修改 module/moduleResolution 这两个字段
1234567891011121314151617{ "compilerOptions": { "module": "Node16", // + "moduleResolution": "Node", // + "declaration": true, "removeComments": true, "emitDecoratorMetadata": true, "experimentalDecorators": true, "allowSyntheticDefaultImports": true, "target": "es2017", & ...
管理平台监控调研
管理平台监控调研一、背景对于管理平台未提供前端监控,无法主动发现报错、页面首屏加载时长、用户浏览器环境等影响用户体验的问题。因此,有必要实现一套前端监控体系方案,旨在提升平台质量和降低排查问题成本。
二、目标针对目前各管理平台项目没有提供监控体系功能,将制定一套前端监控体系 SDK,帮助平台开发者快速接入前端监控功能而无需手动实现。
结合目前技术选型和业务情况,前端监控 SDK 需要支持的能力包括以下几点:
异常监控
API 请求异常监控
JS 异常监控
静态资源加载异常监控
Promise 未捕获异常监控
性能监控
页面加载性能
TTFE:首包响应时间
First Paint:首屏渲染时间
DOM Ready:DOM 就位时间
First Interactive:首次可交互时间
埋点上报
支持自动采集异常信息
支持自动采集性能信息
支持数据埋点
浏览器环境
页面访问 pv、uv
手动埋点定制化数据
报警响应
支持报警规则配置
支持 sea talk 通知
支持邮件通知业务 owner
三、方案这里我们主要讨论三个方案
开源方案 — sentry
自研 SDK
...