就在昨天，一个名为win12的开源项目一度冲上了GitHub的Trending热榜。

而且最近项目的Star量也在飙升，目前已经获得了2.2k+的Star标星。

出于好奇，点进去看了看。好家伙，项目README里写道这是一个14岁的初中生所打造的开源项目。

即：在网页端实现了Windows 12的UI界面和交互效果。

这里也放几张图片感受一下。

登录页面

开始菜单

资源管理器

设置

终端命令行

AI Copilot

其他应用

这个项目的灵感来源于作者之前看到 Windows 12 概念版后深受启发，于是决定做一个Windows12网页版（就像之前的 Windows 11 网页版一样），可以让用户在网络上预先体验 Windows 12。

可以看到，这个项目是一个前端开源项目，而且由标准前端技术（HTML，JS，CSS）来实现，下载代码，无需安装，打开desktop.html即可。

项目包含：

• 精美的UI设计
• 流畅丰富的动画
• 各种高级的功能（相较于网页版）

不仅如此，作者团队对于该项目的后续发展还做了不少规划和畅想。

• 项目规划

• 项目畅想

刚上面也说了，项目README里写道该项目的作者是一位14岁的初中生，网名叫星源，曾获得CSP普及组一等奖和蓝桥杯国赛三等奖。

作者出生于2009年，在成都上的小学和初中，目前刚上初三。

这样来看的话，虽说作者年龄很小，不过接触计算机和编程应该非常早，而且对计算机领域的知识和技术应该有着非常浓厚的兴趣。

从作者的个人主页里能看到，技术栈这块涉猎得还挺广泛。

作者自己表示如今上初三了，对于win12这个项目也不会做什么功能的更新了，后续的维护更新将交给其他贡献者成员。

文章的结尾也附上Windows 12网页版体验地址：tjy-gitnub.github.io/win12/desktop.html，感兴趣的同学可以自行体验。

聊到这里不得不说，人与人之间的差距确实挺大的。就像这位小哥，才14岁就已经精通前端技术了。

而14岁的我，当年在干嘛呢？

我想了又想。。

额，我好像在网吧里玩红警。。（手动doge）

最近看韩国电视剧【D.P：逃兵追缉令】里面提到一个有趣的数学概率游戏 -> 蒙提霍尔问题

意思是：参赛者会看见三扇门，其中一扇门的里面有一辆汽车，选中里面是汽车的那扇门，就可以赢得该辆汽车，另外两扇门里面则都是一只山羊，让你任意选择其中一个，然后打开其余两个门中的一个并且是山羊（去掉一个错误答案），这时，让你重新选择。那么你是会坚持原来的选择，还是换选另外一个未被打开过的门呢？

大家可以想一想如果是自己，我们是会换还是不会换？

好了，我当时看到后感觉很有意思，所以我简单写了一套代码，源码贴在下面，大家可以验证一下，先告诉大家，换赢得汽车的概率是2/3，不换赢得汽车的概率是1/3

<header>

<h1>请选择换不换？</h1><button class="refresh">刷新</button>

</header>

<section>

<div class="box">

  <h2>1</h2>

  <canvas width="300" height="100"></canvas>

  <div class="prize">奖品</div>

</div>

<div class="box">

  <h2>2</h2>

  <canvas width="300" height="100"></canvas>

  <div class="prize">奖品</div>

</div>

<div class="box">

  <h2>3</h2>

  <canvas width="300" height="100"></canvas>

  <div class="prize">奖品</div>

</div>

</section>

<span>请选择号码牌</span>

<select name="" id="">

<option value="1">1</option>

<option value="2">2</option>

<option value="3">3</option>

</select>

<button class="confirm">确认</button>

<span class="confirm-text"></span>

<span class="opater">

<button class="change">换</button>

<button class="no-change">不换</button>

</span>

<p>

<strong>游戏规则：</strong>

<span>

  上面有三个号码牌，其中一个号码牌的里面有汽车，选中里面是汽车的号码牌，

  你就可以赢得该辆汽车，另外两个号码牌里面则都是一只山羊，

  你任意选择其中一个，然后打开其余两个号码牌中的一个并且是山羊（去掉一个错误答案），

  这时，你有一个重新选择的机会，你选择换还是不换？

</span>

</p>

.prize {

  width: 300px;

  height: 100px;

  background-color: pink;

  font-size: 36px;

  line-height: 100px;

  text-align: center;

  position: absolute;

}



canvas {

  position: absolute;

  z-index: 2;

}



section {

  display: flex;

}



.box {

  width: 300px;

  height: 200px;

  cursor: pointer;

}



.box+.box {

  margin-left: 8px;

}



header {

  display: flex;

  align-items: center;

}



header button {

  margin-left: 8px;

  height: 24px;

}

p {

  width: 400px;

  background-color: pink;

}

function shuffleArray(array) {

  for (let i = array.length - 1; i > 0; i--) {

    const j = Math.floor(Math.random() * (i + 1));

    [array[i], array[j]] = [array[j], array[i]];

  }

  return array;

}

function getRandomNumber() {

  return Math.random() > 0.5 ? 1 : 2;

}

let a1 = [0, 1, 2]

let i1 = undefined

let i2 = undefined

let isChange = false

const opater = document.querySelector('.opater')

opater.style.display = 'none'

// 随机一个奖品

const prizes = document.querySelectorAll('.prize')

let a0 = [0, 1, 2]

a0 = shuffleArray(a0)

a0.forEach((v,i) => {

  const innerText = !!v ? '山羊' : '汽车'

  prizes[i].innerText = innerText

})



const canvas = document.querySelectorAll('canvas')

const confirmText = document.querySelector('.confirm-text')

canvas.forEach(c => {

  // 使用canvas实现功能

  // 1. 使用canvas绘制一个灰色的矩形

  const ctx = c.getContext('2d')

  ctx.fillStyle = '#ccc'

  ctx.fillRect(0, 0, c.width, c.height)

  // 2. 刮奖逻辑

  // 鼠标按下且移动的时候，需要擦除canvas画布

  let done = false

  c.addEventListener('mousedown', function () {

    if (i1 === undefined) return alert('请先选择号码牌，并确认！')

    if (!isChange) return alert('请选择换不换！')

    done = true

  })

  c.addEventListener('mousemove', function (e) {

    if (done) {

      // offsetX 和 offsetY 可以获取到鼠标在元素中的偏移位置

      const x = e.offsetX - 5

      const y = e.offsetY - 5

      ctx.clearRect(x, y, 10, 10)

    }

  })

  c.addEventListener('mouseup', function () {

    done = false

  })

})

const confirm = document.querySelector('.confirm')

const refresh = document.querySelector('.refresh')

confirm.onclick = function () {

  let select = document.querySelector('select')

  const options = Array.from(select.children)

  confirmText.innerText = `您选择的号码牌是${select.value}，请问现在换不换？`

  // 选择后，去掉一个错误答案

  // i1是下标

  i1 = select.value - 1

  // delValue是值

  let delValue = undefined

  // 通过下标找值

  if (a0[i1] === 0) {

    delValue = getRandomNumber()

  } else {

    delValue = a0[i1] === 1 ? 2 : 1

  }

  // 通过值找下标

  i2 = a0.indexOf(delValue)

  // 选择的是i1, 去掉的是

  const ctx = canvas[i2].getContext('2d')

  ctx.clearRect(0, 0, 300, 100)

  options.map(v => v.disabled = true)

  confirm.style.display = 'none'

  opater.style.display = 'inline-block'

}

const change = document.querySelector('.change')

const noChange = document.querySelector('.no-change')

change.onclick = function () {

  isChange = true

  const x = a1.filter(v => v !== i1 && v !== i2)

  confirmText.innerText = `您确认选择的号码牌是${x[0] + 1}，请刮卡！`

  opater.style.display = 'none'

}

noChange.onclick = function () {

  isChange = true

  confirmText.innerText = `您确认选择的号码牌是${i1 + 1}，请刮卡！`

  opater.style.display = 'none'

}

refresh.onclick = function () {

  window.location.reload()

}

确实会慢，但不多 🤪

qiankun2 自发布以来，常被人诟病慢、有性能问题。虽在大部分场景下，这个问题表现的并不明显，不会对应用造成可感知的影响（2m JS 的解析约增加 200ms 耗时，单个函数调用增加耗时可忽略不计）。大部分情况下应用渲染慢，真的就是因为你的 JS 太大（一个不分片的超大的 bundle），接口响应太长，UI 不够有「弹性」导致的。
但在面临一些 CPU 密集型的 UI 操作时，如图表、超量 DOM 变更（1000以上）等场景，确实存在明显的卡顿现象。所以我们也不好反驳什么，通常的解决方案就是推荐用户关闭沙箱来提升性能。

去年底我们曾尝试过一波优化，虽然略有成效，但整体优化幅度不大，因为有一些必要访问耗时省不掉，最终以失败告终。

重启优化之路 😤

近期有社区用户又提到了这个问题，加之年初的时候「获取」到了一些灵感，中秋假期在家决定对这个问题重新做一次尝试。
我们知道 qiankun 的沙箱核心思路其实是这样的：

const windowProxy = new Proxy(window, traps);



with(windowProxy) {

  // 应用代码，通过 with 确保所有的全局变量的操作实际都是在操作 qiankun 提供的代理对象

  ${appCode}  

}

此前主要的性能问题出在应用的代码会频繁的访问沙箱，比如 Symbol.unscopables 在图表场景很容易就达到千万级次的访问。
优化的思路也很简单，就是要减少全局变量在 proxy 里的 lookup 次数。比如可以先缓存起来，后续访问直接走作用域里的缓存即可：

const windowProxy = new Proxy(window, traps);



with(windowProxy) {

+ // 提前将一些全局变量通过 赋值/取值 从 proxy 里缓存下来

+ var undefined = windowProxy.undefined; var Array = windowProxy.Array; var Promise = windowProxy.Promise;

  // 应用代码，通过 with 确保所有的全局变量的操作实际都是在操作 qiankun 提供的代理对象

  ${appCode}  

}

看上去很完美，不过手上没有 windows 设备没法验证（M1性能太强测不出来），于是先提了个 pr。

验证 👻

假期结束来公司，借了台 windows 设备，验证了一下。
糟了，没效果。优化前跟优化后的速度几乎没有变化。🥲

想了下觉得不应该啊，理论上来讲多少得有点作用才是，百思不得其解。

苦恼之际，突然好像想到了什么，于是做出了下面的修改：

const windowProxy = new Proxy(window, traps);



with(windowProxy) {

+ // 提前将一些全局变量通过 赋值/取值 从 proxy 里缓存下来

- var undefined = windowProxy.undefined; var Array = windowProxy.Array; var Promise = windowProxy.Promise;

+ const undefined = windowProxy.undefined; const Array = windowProxy.Array; const Promise = windowProxy.Promise;

  // 应用代码，通过 with 确保所有的全局变量的操作实际都是在操作 qiankun 提供的代理对象

  ${appCode}

}

改动更简单，就是将 var 声明换成了 const，立马保存验证一把。

直接起飞！

场景 1：vue 技术栈下大 checkbox 列表变更

在有沙箱的情况下，耗时基本与原生框架的一致了。

场景 2：10000 个 dom 插入/变更

在 vue 的 event handler 中做原生的 10000 次 的 for 循环，然后插入/更新 10000 个 dom，记录中间的耗时：

<template>

  <div>

    <ul>

      <li v-for="item in aaa" :key="item">{{ item }}</li>

    </ul>

    <button @click="test">test</button>

  </div>

</template>



<script>

  import logo from "@/assets/logo.png";

  export default {

    data() {

      return {

        aaa: 1

      };

    },

    methods: {

      test() {

        console.time("run loop", 10000);



        for (let index = 2; index < 1 * 10000; index++) {

          this.aaa = index;

        }



        console.timeLog("run loop", 10000);



        this.$nextTick(() => {

          // 10000 个 dom 更新完毕后触发

          console.timeEnd("run loop", 10000);

        });

      }

    }

  };

</script>

 

可以看到，这个优化后的提升已经不止 10 倍了，都超过 50 倍了，跟原生的表现基本无异。

如何做到的 🧙

完成最后的性能飞跃，实际上我只改了 3 个字符，就是把 with 里的 var 换成了 const，这是为什么呢？
其实我之前的这篇文章早就告诉了我答案：
ES 拾遗之 with 声明与 var 变量赋值
里面有一个重要的结论：

因为 windowProxy 里有所有的全局变量，那么我们之前使用 var 去尝试做作用域缓存的方案其实是无效的，声明的变量实际还是在全局的词法环境中的，也就避免不了作用域链的查找。而换成 const，就可以顺利的将变量写到 with 下的词法环境了。

one more thing 😂

至此，如果以后你的应用在微前端场景下表现的不尽如人意，请先考虑：

1. 是否是应用的打包策略不合理，导致 bundle 过大 js 执行耗时过长
2. 是否是前置依赖逻辑过多执行过慢（如接口响应），阻塞了页面渲染
3. 是否是微应用的加载策略不合理，导致过晚的加载
4. 没有加载过渡动画，只有硬生生的白屏

别再试图甩锅给微前端了，瑞思拜🫡。

距离第一个试用版已经过去半年之久，想想就发了这篇文章，该文章起这种标题完全是被迫。之前也相继发表了一些相关的文章但是阅读量和点赞量寥寥无几，这种标题我也是看了一些自媒体发表的文章后学习而来。我也在尝试编写一些高质量的文章，如果你看到这篇文章请嘴下留情。

响应式

Gyron.js是一款零依赖的响应式框架，和社区中大多数响应式方案一样，Gyron.js也是利用Proxy提供的能力进行的依赖收集和更新，理论上来说只要支持Proxy能力的环境都支持这套响应式的逻辑，只是需要修改（接入）对应的渲染部分。这里也要感谢 Vue 实现的响应式依赖更新方案，我们基本上参考着这套方案实现了自己的 API。

响应式核心部分就是 effect 结构，基本上所有提供出来的 api 都是在 effect 之上实现的，所以我们先来介绍 effect 这个数据结构。

我们先来看一眼 effect 长什么样子

export type Dep = Set<Effect>;



export type EffectScheduler = (...args: any[]) => any;



export type Noop = () => void;



export interface Effect {

  // A 等于 self effect

  // B 等于 other effect

  // deps 是一个 Set 结构的 Effect ，用于存放 A 依赖的 B

  // 当A不再使用时需要清除所有依赖 A 的 B

  deps: Dep[];

  // 在边界情况下强制执行依赖的B

  allowEffect: boolean;

  // 在首次执行时收集依赖的函数

  scheduler: EffectScheduler | null;

  // 存放所有手动设置的依赖

  wrapper: Noop;

  // 当需要更新时执行的函数

  run: Noop;

  // 当不再使用时清除依赖的B

  stop: Noop;

}

effect 中有很多属性，我也在其中注释了每个属性的作用。每个属性都有自己的应用场景，比如 deps 就是用于卸载组件后清除所有组件依赖的数据，避免数据更新后组件被卸载，导致组件更新异常。其实响应式核心分为两个部分，第一个部分就是依赖收集，第二个部分就是响应更新，我们先来看看下面这张图。

上面这张图就是说明两个不同的数据之间的依赖关系，第一块（左上角）表明 variable proxy 2 依赖 variable proxy 1，在 variable proxy 2 中访问 variable proxy 1 时，会触发 variable proxy 1 的自动收集任务，当 variable proxy 1 的值更新后会触发依赖 variable proxy 2 的任务，也就是 run 或者 scheduler。那么我们是通过什么将这两个变量关联在一起的呢？我们引入了一个WeakMap数据effectTracks，用变量作为一个 key 值，然后在变更 variable proxy 1 时从这个模块变量中找到依赖再做更新，也就是图中右边部分。至此，依赖收集和依赖更新都已经完成，接下来，如何对应到组件上面呢？

上面我们介绍了两个响应式变量是如何完成这一整套响应式方案，那么我们把上述的变量变更为组件可不可以呢？答案是可以的。组件是什么？在 Gyron.js 中组件就是一个函数，一个被内装函数包装的函数。那么，组件在初次渲染时如何进行依赖收集呢？在讲解组件的依赖收集之前，我们先讲一讲另外一个模块变量activeEffect，这个变量主要用于组件初次渲染时保存组件的 effect 对象，然后在响应式数据 track 时，获取到组件的 effect 对象保存在上面讲的effectTracks模块变量中，在响应式数据发生变更后触发组件 effect 的 update 方法（也就是 run）来更新组件。这里值得一提的是，所有的更新我们全部都是异步，并且是可选支持中断继续模式的，这部分内容我们接下来再进行介绍。

好了，响应式的核心内容其实并不多，其实如何实现只是冰山一角，最主要的是其中的想法可以应用在你的业务之中，尽量少写一些恶心同事的代码。

任务调度

上面我们讲解了Gyron.js是如何做到响应式更新的，接下来我们说一说多个组件同时更新应该怎么处理呢？如果组件更新阻止了用户操作应该怎么办呢？如何在组件中拿到更新后的DOM呢？这些问题在平时开发中相信大多数开发中都遇到过，其实这些问题可以在编写业务代码时去进行优化，但是不怎么优雅，也可能会导致代码不可读，比如

获取更新后的 DOM

// 获取更新后的 D<DOM>

任务: [update component A, update component B, [update component C, [update component D]]]

等待任务更新完成: A、B、C、D

获取组件D更新后的DOM

为了提高开发效率和用户体验，开发者可以合理选择使用哪种模式更新组件。具体有哪些模式可以选择呢？答案是两种，第一种就是默认模式，组件更新全部在异步队列中完成。第二种模式就是在异步队列中的任务会受到外部状态控制。接下来我们分开讲一讲这两种模式。

第一种模式，我们可以使用Gyron.js暴露的FC方法定义组件，然后正常使用 JSX 去描述 UI，在组件更新时通过暴露的nextRender获取到更新后的 DOM。这是一个很常见的实现方式，这也和 Vue 的nextTick一样。我们重点讲讲另外一种更新模式。

延迟更新：组件更新的前面几步都是一样，有一个异步队列，但是延迟更新模式中有一个priority属性，当组件 effect 拥有这种属性的时候会自动根据这批组件的更新时间，或者用户操作来中断队列中后续任务的更新，当浏览器告诉我们，现在有空闲了可以继续任务时再继续未更新的任务。其实这种模式还可以更进一步，设定一个冷却时间，在冷却时间内再次发现相同的任务直接抛弃上一次相同的任务（根据任务 ID 来区分），这样做可以减少浏览器开销，因为这些任务在下一个周期中肯定会被覆盖。我们有计划的去实现这个内容，但不是现在。

第二种模式的实现完全得益于浏览器提供的 API，让这种模式实现变为可能，也让用户体验得到提升。

其实第二种模式后面的理念可以用在一些大型的编辑场景和文档协作中以此来提升用户体验，这也是在研究 React 的调度任务之后得出的结论。

所以，有人在反驳说看这些源码时没用时可以硬气的告诉他们，看完之后学到了什么。（不过不要盲目的去看，针对具体的问题去研究和借鉴）

复合直观的

如果你是一个 React 的用户，你会发现函数式组件的状态心智负担太高，不符合直觉，直接劝退新手。那么，什么是符合直观的代码？当我的组件依赖更新后组件的内容发生响应的更新即可，这也是响应式的核心。在Gyron.js中编写一个简单的响应式组件会如此简单。

import { FC, useValue } from "gyron";



interface HelloProps {

  initialCount: number;

}



const Hello = FC<HelloProps>(({ initialCount = 0 }) => {

  const count = useValue(initialCount);

  const onClick = () => count.value++;



  // Render JSX

  return <div onClick={onClick}>{count.value}</div>;

});

上面定义了一个 Hello 的组件，这个组件接受一个参数 initialCount，类型为数字，组件的功能也很简单，当用户点击这个数字然后自增一。而如果要用 React 去实现或者 Vue 去实现这样一个功能，我们应该怎么做呢？

我们用 Vue 去实现一个一样的组件，代码如下（使用了 setup 语法）

<script lang="ts" setup>

import { ref } from "vue";



const props = withDefaults(

  defineProps<{

    initialCount: number;

  }>(),

  {

    initialCount: 0,

  }

);



const count = ref(props.initialCount);

function onClick() {

  count.value++;

}

</script>



<template>

  <div @click="onClick">{{ count }}</div>

</template>

那么我们用 React 也去实现一个一样的组件，代码如下

import { useState, useCallback } from "react";



export const Hello = ({ initialCount = 0 }) => {

  const [count, setCount] = useState(initialCount);



  const onClick = useCallback(() => {

    setCount(count + 1);

  }, [count, setCount]);



  console.log("refresh"); // 每点击一次都会打印一次



  return <div onClick={onClick}>{count}</div>;

};

好了，上面是不同框架实现的 Hello 组件。这里并不是说其它框架不好，只是我认为在表达上有一些欠缺。Vue2 中需要理解 this，并且没办法让 this 稳定下来，因为它可以在任何地方修改然后还无法被追踪，在 Vue3 中需要理解 setup 和 template 之间的关系，然后实现类型推断需要了解 defineXXX 这种 API。在 React 中想要更新组件需要注意 React 更新机制，比如内部状态何时才是预期的值，在遇到复杂的组件时这往往比较考验开发者的编码水平。

以上，Gyron.js是如何解决这些问题的呢？其实，这完全得益于 babel 的强大能力，让开发者不需要知道编译构建优化的知识也能介入其中，改变源码并能重新构建。如果想了解其中的用法可以去 babel 官网plugin 页面

然后，Gyron.js是如何解决上面提到的问题？我们以上面编写的一个简单组件 Hello 为例，介绍其中到底发生了什么。
首先，我们的组件用 FC 函数进行了一个包装，这里 FC 就好比一个标识符，在 AST 中属于 BinaryExpression 节点，然后函数体的返回值就是JSX.Element。我们有了这个规则，然后在 babel 中就可以根据这个规则定位到组件本身，再做修改。为了解决重复渲染的问题，我们需要把返回值做一些修改，把JSX.Element用一个函数进行包裹再进行返回。具体转换如下：

const Hello = FC(({ numbers }) => {

  return <div>{numbers}</div>;

});

// ↓ ↓ ↓ ↓ ↓

const Hello = FC(({ numbers }) => {

  return ({ numbers }) => <div>{numbers}</div>;

});

名词解释

组件函数：我们熟知的 JSX 组件

渲染函数：转换后的 JSX 函数，用于标记哪些部分是渲染部分，哪些是逻辑部分。类似于 Vue3 的 setup 和 render 的区别。

这是一个最简单的转换，但是这又引入了另外几个问题。第一，在JSX.Element中的元素内容是组件的参数，但是在下次渲染时取到的是顶层函数中的numbers，为了解决这个问题，我们将顶层函数中的第一个参数作为渲染函数中的第一个参数，然后在渲染函数中访问到的状态就是最新状态。

这其中还有一个问题，我在组件函数中访问 props 状态也无法保证是最新的，这时候就需要使用Gyron.js提供的onBeforeUpdate方法，这个方法会在组件更新之前调用，然后我们需要把组件函数中定义的 props 全部放进这个函数中，然后根据函数的 new props 去更新用户定义的 props。但是真实的使用场景比较复杂，比如可以这样定义({ a, ...b }) => {}，将 props 的 a 单独拎出来，然后其余部分全部归纳到 b 中。

举一个简单的例子：

const Hello = FC(({ numbers }) => {

  function transform() {

    return numbers;

  }

  return <div>{transform()}</div>;

});

// ↓ ↓ ↓ ↓ ↓

import { onBeforeUpdate as _onBeforeUpdate } from "gyron";

const Hello = FC(({ numbers }) => {

  _onBeforeUpdate((_, props) => {

    var _props = props;

    numbers = _props.numbers;

  });

  function transform() {

    return numbers;

  }

  return <div>{transform()}</div>;

});

可以看到转换后的组件中多出了一个_onBeforeUpdate方法调用，其作用就是更新组件函数作用域中的 props。

小结：为了让用户在开发中编写符合直观的代码，Gyron.js在背后做了很多事情。这其实也是 babel 在实际项目中的一种使用方法。

极快的 hmr

hmr（hot module replacement ）就是模块的热更新，其实这部分功能都是编译工具提供，我们只需要按照他们提供的 API 然后更新我们的组件。

if (module.hot) {

  module.hot.accept("./hello.jsx", function (Comp1) {

    rerender("HashId", Comp1);

  });

}

以上代码我们的插件会自动插入，无需手动引入。（目前还只接入 vite，后续有计划的支持 webpack 等有 hot 模块的工具）

我们大致了解一下这其中发生了什么？首先，我们还是借助 babel 把每一个组件的名字和内容生成的 hash 值作为注释节点存放在模块中，然后通过编译工具获取到所有本模块的组件，然后通过注册 hot 事件重新渲染更新后的组件。

好了，讲解了编译工具提供的功能，这里着重讲解一下Gyron.js是如何做到重新渲染的。首先，我们通过编译工具获取到了组件 Hash 和组件函数，然后通过rerender函数执行重新渲染。那么rerender所需要的数据又是从哪里来的呢？其实，在实例第一次初始化的时候这个数据全部都收集到一个Map<string, Set<Component>>数据结构中，然后再通过Component上的 update 方法执行组件的更新。

SEO 友好

其实这段内容和Gyron.js本身关系不太大，但是没有Gyron.js提供的能力也很难办到。Gyron.js提供了 SSR（Server Side Render）的渲染模式，也就是我们熟知的服务端渲染。其中大致的原理就是服务端将实例渲染成字符串之后返回给浏览器，然后再通过客户端的hydrate功能让“静态”文本变的可响应。

以上是简单的用法，然后大致流程图如下所示：

为了让组件变得更通用，我们在所有组件的 props 上注入了一个变量告诉开发者当前处于何种模式的渲染当中，在服务端渲染当中时不能使用客户端提供的 API，在客户端渲染的过程中不能使用服务端的 API。

const App = ({ isSSR }) => {

  // ...

  if (!isSSR) {

    document.title = "欢迎";

  }

};

import { strict as assert } from "node:assert";

const App = ({ isSSR }) => {

  // ...

  if (isSSR) {

    assert.deepEqual([[[1, 2, 3]], 4, 5], [[[1, 2, "3"]], 4, 5]);

  }

};

这是服务端渲染的方式，还有一种介于服务端渲染和客户端渲染之间，就是完全输出静态资源然后就可以部署到任何机器或者在线平台服务商中，比如app.netlify.com、github.com等。这里不再介绍 SSR 模式的使用方法，可以去gyron.cc/docs/ssr这里有更详细的介绍。

所见即所得

这里介绍的是官方文档中的在线编辑器，相比于接入其它平台，我们占用的资源更少，功能齐全。

经过一段时间的折腾，终于弄出一个简单版的在线编辑器，支持实时预览、语法纠错、语法高亮、智能跳转等功能。

语言的话目前支持 jsx、tsx、less，并且还支持加载在线资源，比如import { h } from 'https://cdn.jsdelivr.net/npm/gyron'。因为所有数据都不保存在远端，只保存在本地，所以没有使用 standalone 沙盒技术隔离运行环境，也没有防范 xss 攻击。在线编辑器的目标就是让用户可以在线使用，支持用户编辑源代码，支持本地模块导入，支持实时预览，支持多个编辑器运行互不干扰。

目前这个编辑器支持本地编译和服务端编译，本地编译会让首屏加载变慢所以在线编辑器使用的服务端编译。现在，可以访问gyron.cc/explorer这个地址在线体验。

如果使用本地编译，这里面最终的就是需要实现一套本地的虚拟文件系统，让打包工具能够正常访问到对应的本地资源。而在 esbuild 中实现一套虚拟文件系统其实很简单，只需要编写一个插件，然后用 resolve 和 load 两种勾子就可以将本地文件输出到 esbuild 中。

const buildModuleRuntime = {

  name: "buildModuleRuntime",

  setup(build) {

    build.onResolve({ filter: /\.\// }, (args) => {

      return {

        path: args.path,

        namespace: "localModule",

      };

    });

    build.onLoad({ filter: /\.\//, namespace: "localModule" }, async (args) => {

      // 具体实现可以去github https://github.com/gyronorg/core/blob/main/packages/babel-plugin-jsx/src/browser.ts

      const source = findSourceCode(config.sources, args.path);



      if (source) {

        const filename = getFileName(args, source.loader);

        const result = await transformWithBabel(

          source.code,

          filename,

          main,

          true

        );

        return {

          contents: result.code,

        };

      }

      return {

        contents: "",

        loader: "text",

        warnings: [

          {

            pluginName: "buildModuleRuntime",

            text: `Module "${args.path}" is not defined in the local editor`,

          },

        ],

      };

    });

  },

};

然后会输出一个 module 文件，最终只需要将文件塞到 script 中让其运行。

在页面中引用多个编辑器，需要注意的是在不用这个 module 文件后及时删除。可以使用命名空间给 module 加上一个标签，新增和删除都使用这个命名空间作为变量控制当前运行时的资源。

如果你正在开发一个前端程序，后端使用的 RESTFUL API，那你必须停止为每一个接口编写函数。

RESTFUL API 通常提供在不同实体上执行增删改查（CRUD）操作的一组接口。我们通常在我们的前端项目中为这些每一个接口提供一个函数，这些函数的功能非常的相似，只是为了服务于不用的实体。举个例子，假设我们有这些函数。

// api/users.js



// 创建

export function createUser(userFormValues) {

  return fetch('users', { method: 'POST', body: userFormValues });

}



// 查询

export function getListOfUsers(keyword) {

  return fetch(`/users?keyword=${keyword}`);

}



export function getUser(id) {

  return fetch(`/users/${id}`);

}



// 更新

export updateUser(id, userFormValues) {

  return fetch(`/users/${is}`, { method: 'PUT', body: userFormValues });

}



// 删除

export function removeUser(id) {

  return fetch(`/users/${id}`, { method: 'DELETE' });

}

类似的功能可能存在于其他实体，例如：城市、产品、类别...但是我们可以用一个简单的函数调用来代替这些函数：

// apis/users.js

export const users = crudBuilder('/users');



// apis/cities.js

export const cities = crudBuilder('/regions/cities');

然后像这样去使用：

users.create(values);

users.show(1);

users.list('john');

users.update(values);

users.remove(1);

你可能会问为什么？有一些很好的理由：

• 减少了代码行数：你编写的代码，和当你离开公司时其他人维护的代码
• 强制执行 API 函数的命名约定，这可以增加代码的可读性和可维护性。例如你已经见过的函数名称: getListOfUsers, getCities, getAllProducts, productIndex, fetchCategories等, 他们都在做相同的事情，那就是“获取实体列表”。使用这种方法，你将始终拥有entityName.list()函数，并且团队中的每个人都知道这一点。

所以，让我们创建crudBuilder()函数，然后再添加一些糖。

一个非常简单的 CRUD 构造器

对于上边的简单示例，crudBuilder()函数将非常简单：

export function crudBuilder(baseRoute) {

  function list(keyword) {

    return fetch(`${baseRoute}?keyword=${keyword}`);

  }

  function show(id) {

    return fetch(`${baseRoute}/${id}`);

  }

  function create(formValues) {

    return fetch(baseRoute, { method: 'POST', body: formValues });

  }

  function update(id, formValues) {

    return fetch(`${baseRoute}/${id}`, { method: 'PUT', body: formValues });

  }

  function remove(id) {

    return fetch(`${baseRoute}/${id}`, { method: 'DELETE' });

  }



  return {

    list,

    show,

    create,

    update,

    remove

  };

}

假设约定 API 路径并且给相应实体提供一个路径前缀，他将返回该实体上调用 CRUD 操作所需的所有方法。

但老实说，我们知道现实世界的应用程序并不会那么简单。在将这种方法应用于我们的项目时，有很多事情需要考虑：

• 过滤：列表 API 通常会提供许多过滤器参数
• 分页：列表 API 总是分页的
• 转换：API 返回的值在实际使用之前可能需要进行一些转换
• 准备：formValues对象在发送给 API 之前需要做一些准备工作
• 自定义接口：更新特定项的接口不总是${baseRoute}/${id}

因此，我们需要可以处理更多复杂场景的 CRUD 构造器。

高级 CRUD 构造器

让我们通过上述方法来构建一些日常中我们真正使用的东西。

过滤

首先，我们应该在 list输出函数中处理更加复杂的过滤。每个实体列表可能有不同的过滤器并且用户可能应用了其中的一些过滤器。因此，我们不能对应用过滤器的形状和值有任何假设，但是我们可以假设任何列表过滤都可以产生一个对象，该对象为不同的过滤器名称指定了一些值。例如，我们可以过滤一些用户：

const filters = {

  keyword: 'john',

  createdAt: new Date('2020-02-10')

};

另一方面，我们不知道这些过滤器应该如何传递给 API，但是我们可以假设（跟 API 提供方进行约定）每一个过滤器在列表 API 中都有一个相应的参数，可以以'key=value'URL 查询参数的形式被传递。

因此我们需要知道如何将应用的过滤器转换成相对应的 API 参数来创建我们的 list 函数。这可以通过将 transformFilters 参数传递给 crudBuilder() 来完成。举一个用户的例子：

function transformUserFilters(filters) {

  const params = [];

  if (filters.keyword) {

    params.push(`keyword=${filters.keyword}`);

  }

  if (filters.createdAt) {

    params.push(`create_at=${dateUtility.format(filters.createdAt)}`);

  }



  return params;

}

现在我们可以使用这个参数来创建 list 函数了。

export function crudBuilder(baseRoute, transformFilters) {

  function list(filters) {

    let params = transformFilters(filters)?.join('&');

    if (params) {

      params += '?';

    }



    return fetch(`${baseRoute}${params}`);

  }

}

转换和分页

从 API 接收的数据可能需要进行一些转换才能在我们的应用程序中使用。例如，我们可能需要将 snake_case 转换成驼峰命名或将一些日期字符串转换成用户时区。

此外，我们还需要处理分页。

我们假设来自 API 的分页数据都按照如下格式（与 API 提供者约定）：

{

  data: [], // 实体对象列表

  pagination: {...} // 分页信息

}

因此，我们需要知道如何转换单个实体对象。然后我们可以遍历列表对象来转换他们。为此，我们需要一个 transformEntity 函数作为 crudBuilder 的参数。

export function crudBuilder(baseRoute, transformFilters, transformEntity, ) {

  function list(filters) {

    const params = transformFilters(filters)?.join('&');

    return fetch(`${baseRoute}?${params}`)

      .then((res) => res.json())

      .then((res) => ({

        data: res.data.map((entity) => transformEntity(entity)),

        pagination: res.pagination

      }));

  }

}

list() 函数我们就完成了。

准备

对于 create 和 update 函数，我们需要将 formValues 转换成 API 需要的格式。例如，假设我们在表单中有一个 City 的城市选择对象。但是 create API 只需要 city_id。因此，我们需要一个执行以下操作的函数：

const prepareValue = formValue => ({city_id: formValues.city.id});

这个函数会根据用例返回普通对象或者 FormData，并且可以将数据传递给 API：

export function crudBuilder(baseRoute, transformFilters, transformEntity, prepareFormValues) {

  function create(formValues) {

    return fetch(baseRoute, {

      method: 'POST',

      body: prepareFormValues(formValues)

    });

  }

}

自定义接口

在一些少数情况下，对实体执行某些操作的 API 接口不遵循相同的约定。例如，我们不能使用 /users/${id} 来编辑用户，而是使用 /edit-user/${id}。对于这些情况，我们应该指定一个自定义路径。

在这里我们允许覆盖 crud builder 中使用的任何路径。注意，展示、更新、移除操作的路径可能取决于具体实体对象的信息，因此我们必须使用函数并传递实体对象来获取路径。

我们需要在对象中获取这些自定义路径，如果没有指定，就退回到默认路径。像这样：

const paths = {

  list: 'list-of-users',

  show: (userId) => `users/with/id/${userId}`,

  create: 'users/new',

  update: (user) => `users/update/${user.id}`,

  remove: (user) => `delete-user/${user.id}`

};

最终的 BRUD 构造器

这是创建 CRUD 函数的最终代码。

export function crudBuilder(baseRoute, transformFilters, transformEntity, prepareFormValues, paths) {

  function list (filters) {

    const path = paths.list || baseRoute;

    let params = transformFilters(filters)?.join('&');

    if (params) {

      params += '?';

    }



    return fetch(`${path}${params}`)

      .then((res) => res.json())

      .then(() => ({

        data: res.data.map(entity => transformEntity(entity)),

        pagination: res.pagination

      }));

  }

  function show(id) {

    const path = paths.show?.(id) || `${baseRoute}/${id}`;



    return fetch(path)

      .then((res) => res.json())

      .then((res => transformEntity(res)));

  }

  function create(formValues) {

    const path = paths.create || baseRoute;



    return fetch(path, { method: 'POST', body: prepareFormValues(formValues) });

  }

  function update(id, formValues) {

    const path = paths.update?.(id) || `${baseRoute}/${id}`;



    return fetch(path, { method: 'PUT', body: formValues });

  }

  function remove(id) {

    const path = paths.remove?.(id) || `${baseRoute}/${id}`;



    return fetch(path, { method: 'DELETE' });

  }

  return {

    list,

    show,

    create,

    update,

    remove

  }

}

Saeed Mosavat: Stop writing API functions

1. 使用场景：

公司开会的时候有师兄问到为什么hooks定义一般都写在顶部，对于这个问题我以前总结过，这次看了
react新文档后我给出更加详细的解释并给出具体代码来解释为什么要放在顶部。

2.官网解释：

1.官网截图镇楼：

2.那我写在条件语句中会怎样

我给出一段代码：其中const [message, setMessage] = useState('');写在了条件语句里面

import { useState } from 'react';



export default function FeedbackForm() {

  const [isSent, setIsSent] = useState(false);

  if (isSent) {

    return <h1>Thank you!</h1>;

  } else {

    // eslint-disable-next-line

    const [message, setMessage] = useState('');

    return (

      <form onSubmit={e => {

        e.preventDefault();

        alert(`Sending: "${message}"`);

        setIsSent(true);

      }}>

        <textarea

          placeholder="Message"

          value={message}

          onChange={e => setMessage(e.target.value)}

        />

        <br />

        <button type="submit">Send</button>

      </form>

    );

  }

}

效果图：这是一个收集用户反馈的小表单。当反馈被提交时

 它应该显示一条感谢信息，当我点击确定时出现一条错误。

“渲染的 hooks 比预期的少”

3.那我不写在顶部可能会怎样

下方的const [message, setMessage] = useState('');并没有写在顶部

   import { useState } from 'react';



    export default function FeedbackForm() {

      const [isSent, setIsSent] = useState(false);

      if (isSent) {

        return <h1>Thank you!</h1>;

      }

        const [message, setMessage] = useState('');

        return (

          <form onSubmit={e => {

            e.preventDefault();

            alert(`Sending: "${message}"`);

            setIsSent(true);

          }}>

            <textarea

              placeholder="Message"

              value={message}

              onChange={e => setMessage(e.target.value)}

            />

            <br />

            <button type="submit">Send</button>

          </form>

        );

      }

    }

效果图：

 点击确认后：
同样出现这个错误：提前return导致后面一个hooks没有渲染。

4.原因分析

从源码的角度来说的话，React会在内部创建一个名为“Hooks”（中文为钩子）的数据结构来追踪每个组件的状态。

在函数组件中调用Hook时，React会根据Hook的类型将其添加到当前组件的Hooks链表中。然后，React会将这些Hooks存储在Fiber节点的“memoizedState”字段中，以便在下一次渲染时使用。

如果你在代码中多次调用同一个Hook，React会根据Hooks的顺序将其添加到当前组件的Hooks链表中。这样，React就可以确定哪个状态应该与哪个组件关联，并且能够正确地更新UI。

以下是一个示例代码片段：

import { useState, useEffect } from 'react';



function useCustomHook() {



const [count, setCount] = useState(0);



useEffect(() => {

document.title = `Count: ${count}`;

}, [count]);

return [count, setCount];

}



export default function MyComponent() {



const [count, setCount] = useCustomHook();

return (

<div>

<p>Count: {count}</p>

<button onClick={() => setCount(count + 1)}>Increment</button>

</div>

);

}

在上面的代码中，useCustomHook是一个自定义Hook，它使用useState和useEffectHook来管理状态。在MyComponent中，我们调用自定义Hook并使用返回值来渲染UI。

由于useCustomHook只能在函数组件或其他自定义Hooks的最顶层调用，我们不能将它嵌套在条件语句、循环或其他函数内部。如果这样做，React将无法正确追踪状态并更新UI，可能导致不可预测的结果。如果我们条件渲染中使用可能导致没有引入useCustomHook()，从而导致错误。

总结描述就是创建了一个链表，当在条件语句中使用hooks时可能会导致前后两次链表不同，从而导致错误，所以我们必须尽可能避免这种错误从而写在顶部。

前言

首先声明，没有标题党哈！

以下我知道的国内知名react组件库全部都有这个bug，你们现在都能去复现，一个提pr的好机会就让给你们了，哈哈！复现组件库：

• 阿里系：ant design, fusion design，
• 字节系：arco design
• 腾讯：tdesign

本来字节还有一个semi design，结果我发现它没有Affix组件，也就是固钉组件，让他躲过一劫，他有这个组件我也觉得肯定会复现相同的bug。

Affix组件是什么，以及bug复现

Affix组件（固钉组件）能将页面元素钉在可视范围。如下图：

这个button组件，会在距离顶部80px的时候会固定在屏幕上（position: fixed）,如下图：

如何复现bug

你在这个button元素任意父元素上，加上以下任意style属性

• will-change: transform;
• will-change: filter;
• will-change: perspective;
• transform 不为none
• perspective不为none
• 非safari浏览器，filter属性不为none
• 非safari浏览器，backdrop-filter属性不为none
• 等等

都可以让这个固定组件失效，就是原本是距离顶部80px固定。

我的组件库没有这个bug，哈哈

mx-design

目前组件不是很多，还在努力迭代中，不知道凭借没有这个bug的小小优点，能不能从你手里取一个star，哈哈

bug原因

affix组件无非都是用了fixed布局，我是如何发现这个bug的呢，我的组件库动画系统用的framer-motion，我本来是想在react-router切换路由的时候整点动画的，动画效果就是给body元素加入例如transform的变化。

然后我再看我的固钉组件怎么失效了。。。后来仔细一想，才发现想起来fixed布局的一个坑就是，大家都以为fixed布局相对的父元素是window窗口，其实是错误的！

真正的规则如下（以下说的包含块就是fixed布局的定位父元素）：

1. 如果 position 属性是 absolute 或 fixed，包含块也可能是由满足以下条件的最近父级元素的内边距区的边缘组成的：

评论区有很多同学居然觉的这不是bug？

其实这个问题本质是定位错误，在这些组件库里，同样使用到定位的有，例如Tooltip，Select,Popuver等等，明显这些组件跟写Affix组件的不是一个人，其他组件这个bug是没有的，只有Affix组件出现了，所以你说这是不是bug。

还有，如果因为引用了Affix组件，这个固定元素的任一父元素都不能用以上的css属性，我作为使用者，我用了动画库，动画库使用transfrom做Gpu加速，你说不让我用了，因为引起Affix组件bug，我心里想凭啥啊，明明加两行代码就解决了。

最后，只要做过定位组件的同学，其复杂度在前端算是比较高的了，这也是为什么有些组件库直接用第三方定位组件库（floating-ui，@popper-js），而不是自己去实现，因为自己实现很容易出bug，这也是例如以上组件库Tooltip为什么能适应很多边界case而不出bug。

所以你想想，这仅仅是定位组件遇到的一个很小的问题，你这个都解决不了，什么都怪css，你觉得用户会这么想吗，一有css，你所有跟定位相关的组件全部都不能用了，你们还讲理不？

总之一句话，你不能把定位组件的复杂度高怪用户没好好用，建议去看看floating-ui的源码，或者之前我写的@popper-js定位组件的简要逻辑梳理，你就会意识到定位组件不简单。边界case多如牛毛。

解决方案

• 首先是找出要固定元素的定位元素（定位元素的判断逻辑上面写了），然后如果定位元素是window，那么跟目前所有组件库的逻辑一样，所以没有bug，如果不是window，就要求出相对定位父元素距离可视窗口顶部的top的值
• 然后在我们原本要定位的值，比如距离顶部80px的时候固定，此时80px再减去上面说的定位父元素距离可视窗口顶部的top的值，就没有bug了

具体代码如下：

• offsetParent固定元素的定位上下文，也就是相对定位的父元素
• fixedTop是我们要触发固定的值，比如距离可视窗口顶部80px就固定

affixDom.style.top = `${isHTMLElement(offsetParent) ? (fixedTop as number) - offsetParent.getBoundingClientRect().top : fixedTop}px`;

如何找出offsetParent，也就是定位上下文

export function getContainingBlock(element: Element) {

  let currentNode = element.parentElement;

  while (currentNode) {

    if (isContainingBlock(currentNode)) return currentNode;

    currentNode = currentNode.parentElement;

  }

  return null;

}

工具方法，isContainingBlock如下：

import { isSafari } from './isSafari';



export function isContainingBlock(element: Element): boolean {

  const safari = isSafari();

  const css = getComputedStyle(element);



  // https://developer.mozilla.org/en-US/docs/Web/CSS/Containing_block#identifying_the_containing_block

  return (

    css.transform !== 'none' ||

    css.perspective !== 'none' ||

    (css.containerType ? css.containerType !== 'normal' : false) ||

    (!safari && (css.backdropFilter ? css.backdropFilter !== 'none' : false)) ||

    (!safari && (css.filter ? css.filter !== 'none' : false)) ||

    ['transform', 'perspective', 'filter'].some((value) => (css.willChange || '').includes(value)) ||

    ['paint', 'layout', 'strict', 'content'].some((value) => (css.contain || '').includes(value))

  );

}

本文完毕，求关注，求star!!!对于react组件库感兴趣的小伙伴，欢迎加群一起交流哦！