背景

从上一篇《从egg.js转到nest.js》，想对其再深入了解一下，尤其比较好奇Typescript是如何实现IoC和DI，因为在Java的是通过的反射(Spring IoC实现原理)去创建对应的类。因此下文将详细讲解Nest.js中IoC和DI的实现原理。

前置知识

在了解实现原理之前有几个知识概念，需要了解一下：

• IoC和DI
• JavaScript的Reflect
• TypeScript的装饰器

Deprank js重要性排名

一个 JS 工具，按照重要性对本项目的所有脚本进行排序。原理是计算依赖关系，被依赖最多的脚本最重要。

官网：Deprank

例子如下：

1
2
3
4
5
6
7
8
9

| Filename               | Lines | Dependents | PageRank |
----------------------------------------------------------
| fixtures/core.js       | 3     | 1          | 0.284098 |
| fixtures/utils.js      | 4     | 3          | 0.268437 |
| fixtures/user/user.js  | 4     | 1          | 0.132253 |
| fixtures/todo.js       | 6     | 1          | 0.089796 |
| fixtures/user/index.js | 1     | 1          | 0.089796 |
| fixtures/concepts.js   | 4     | 1          | 0.079694 |
| fixtures/index.js      | 4     | 0          | 0.055926 |

背景

自从组内开发架构采用Monorepo大仓项目后，了解一些Monorepo的常用技术，主要采用了lerna框架去做多个子项目统一package.json命令脚本，因此想要了解一下lerna框架，同时也查到lerna的公司同步开发Nx项目，尝试一下它的应用。

想了解Monorepo大仓项目如何设计的可以翻到前往阅读 《从npm版本依赖到Monorepo大仓项目》。

背景

自从React16版本更新了Hook用法，同时引入了新的Fiber架构去重构整个渲染和事件处理过程，React团队引入Hook是为了更好剥离业务代码，让开发能更加友好的抽象代码，达到低耦合的函数组件目的，那么重构Diff算法，引入Fiber架构是为了什么呢？ 其实只是为了能够一个目标快速响应，原先Diff算法时间复杂度为$$ O(n^3)$$ ，最后经过Fiber重构达到了$$ O(n) $$，这里面具体有什么门道，值得我们去深入研究一下。

背景

最近想下载一些免费的电子书，然后找到一个推荐的网站，说是去中心化图书馆，利用去中心化，可以永久有效的，就是Z-Library，因此觉得挺有趣，所以适合简单研究一下。

Z-Library

Z-Library（简称Z-Lib，前身为BookFinder）是一个影子图书馆和开放获取文件分享计划，用户可在此一网站上下载期刊文章以及各种类型的书籍。根据Z-Library的说法，截至2022年6月12日，其共收录了10,456,034本书和84,837,646篇文章[1]。Z-Library在其电子书搜索页面上宣称自己是“全球最大的数字图书馆”[2]，并在文章搜索页面上称自身是“全球最大的科学文章存储库”[3]。它原是创世纪图书馆的镜像网站，并从该图书馆获得大部分馆藏。但它的一些馆藏由用户自行上载，并且不为创世纪图书馆所收藏[4]。该平台公开网域已于2022年11月3日遭到美国政府屏蔽。

ZLibrary虽然是一个俄国网站，但它拥有16种语言版本可供选择，下滑至网页末尾，即可切换语言。

访问地址：https://zlib.cydiar.com/
访问地址：https://bk.hallowlib.org/ 国内备用网址

背景

由于自己太久没开发移动端的页面，个人觉得移动端开发相比较PC端开发最大的不同，在于需要去适配各种尺寸的手机屏幕，尤其还有1px的问题。

因此需要再次收集一下，除了自己认知(rem适配)以外，是否还有移动端适配的方案吗？

问题

移动端存在几类问题，如下所列：

• 1px显示过粗问题
• 手机屏幕出现刘海屏、滴水屏等，如何适配
• 如何在不同屏幕，显示正确高清图片
• meta 的 viewport 值 能否用来适配
• rem，vw，vh计算单位的区别
• …

背景

进入部门工作后，接触到的node.js服务端框架，是egg.js，后面基于扩展增加了很多插件，比如：@Controller @Service等注解，还有针对egg-framework 定制化部门使用的底层framework。

但是，随着时间的迁移，egg已经不太能满足我们的开发效率和开发模式，主要有以下几点：

• 对typescript支持度不够，这是由于egg.js本身就不是typescript开发
• egg.js封装web架构，约定大于编码，如：强制将web应用分级为： controller、service、middleware、extend等，自由度相对比较弱，当你需要定制化开发内容，你需要深入了解egg.js的整个运行原理才能实现
• 虽然部门内部定制化开发 @Controller @Service等注解，减少路由配置，但是这一块插件还存在一些隐藏规则，需要开发注意

当然egg.js运行的web应用还是比较稳定，而且相关插件生态也比较丰富，只是当egg.js迭代更新速度在2020年后就逐步放缓，更不上变化，我们就需要迎接一些新的框架来满足要求。

框架对比

我从近两年听到或者网上收集的，基于Node.js的框架主要有以下几个：

• 基础框架，基本上还是以express、koa、Fastify.js等为主
• egg.js，以MVC为架构的web框架
• nest.js，以Ioc 控制反转作为核心概念的web框架，对typescript支持友好
• nuxt.js，以Vue.js作为SSR服务端渲染核心的web框架，最新是Nuxt3（以Vue3为核心）
• next.js，以React.js作为SSR服务端渲染核心的
• Meteor.js，full-stack javascript平台，最大的特点是当数据发生改变的时候，所有依赖该数据的地方自动发生相应的改变。
• Fastify.js，号称最快的node.js web框架，特点是内置了基于 JSON schema 的 validation 和 serialization，比JSON.stringify还快的json序列化算法，虽然是借助借助第三方库 ajv。
• strapi.js，快速生成API接口的web框架，同时实现各种后端所需要的鉴权、权限、文件上传等轮子

背景

最近半年，都在开发部门内部的CMDB平台和申请流程，因此对CMDB有了一定了解，但是又不够系统，所以希望写一篇文章能够系统完整的认知一下CMDB，包括以下几点：

• 是什么
• 能做什么和怎么做
• 优秀方案
• 未来方向

原因

最近在做markdown 算法文章分享，算法肯定会涉及到数学复杂度，比如: $$ O(log_nX) $$ 等数学公式的展示，但是如果写成这样子lognX，估计很难准确表达，因此上网搜索了一下数学表达式在前端页面如何展示的相关技术。

web 数学表达式展示解决方案

一般需要在web页面展示数学表达式相关技术，基本上都是在线编辑器，但是markdown也算是一种编辑器语法，所以上网收集了主要以下几种

• TeX，前期计算机无法生成数学公式排版或者排版很丑，因此Donald E. Knuth设计了一套排版技术，拥有很多计算机的命令或者技术语言
• LaTeX，是一种基于TeX的实现排版系统，准确的基于TeX的应用系统，已经封装很多公式模板，直接套用即可
• MathJaX，基于LaTeX实现的JavaScript渲染器， 渲染稍慢，支持更多复杂的表示
• KaTeX，也基于LaTeX实现的是一个JavaScript库，对比MathJaX，渲染更快，支持若干简写字符，但是本身支持的范围较小

背景

前端的发展很快，自从node.js的出现，打开前端新的大门，npm让js有了自己的包管理能力，能够让前端项目工程化，从而能够处理更加复杂的前端项目。

但是随之而来的是，同一个项目的npm依赖越来越多，有些是开源的，有些是自研的，尤其在同一个团队，当你开发一个新的npm包的时候，只是为了服务特定几个项目，但是这几个项目不在你管理范围内，当你需要更新的时候需要通知到他们，有时候会出现版本依赖问题，然后反复沟通和测试，最终达到协调。但是下次更新的时候又再次遇到这个问题，重复一次。

npm依赖

npm是什么

npm，Node Package Manager的缩写，也就是“Node的包管理器”。
npm（“Node 包管理器”）是 JavaScript 运行时 Node.js 的默认程序包管理器。