背景

最近从网上看到一个有趣的CSS应用，就是纯用CSS也能是父子树展示，具体效果如下：

• 目录节点1

  • 节点1

    • 子节点1-1
    • 子节点1-2
  • 节点2

    • 子节点2-1
    • 子节点2-2

然后里面关联到一篇新闻，就是:has伪元素的出现会给CSS带来极大的变动，这是为什么，不就是一个CSS伪元素吗？因此去了解一下，才发现这个伪元素确实不一样，主要有以下几点：

• 可以选择父级元素， a:has(> img)，包含img元素的a元素
• 可以选择兄弟元素， h1:has(+ p)，后面为p元素的h1元素

为什么有了它之后，CSS会有大变动，因为以往我们的样式都是直接选择 元素 或者 子元素 或者 后面的元素，如果要选择父元素或前面的元素只能通过命名规范去确定，比如上述两个例子：

• a:has(> img)，我们只能通过a.has-img类似样式去命名
• h1:has(+ p)，只能通过h1.next-p类似样式去命名

大概清楚它能带来的变化，接下来我们来详细了解一下它。

背景

之前研究过一篇《移动端适配总结》，里面主要通过布局不变，改变布局组件元素的大小去适应移动端。但是这种方式对于PC端或者Pad等大屏幕并不适合，所以从想找找看是否有新的方案能否满足跨端自适应布局方式。

目前同时解决PC端和移动端的响应式布局的解决方案以下几种：

• 通过@media媒体查询去设置不同尺寸的样式
• 通过Flexbox Grid等现代化布局去做响应式布局

介绍

当hexo的文章越来越多，依靠标题和tag去搜索有点不够用，因此需要支持搜索功能，hexo查询主要依赖本地索引文件生成，具体步骤如下：

• 安装插件: npm install --save hexo-generator-search
• 根目录下的_config.yml中添加如下配置即可

背景

从上一篇《从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框架，同时实现各种后端所需要的鉴权、权限、文件上传等轮子