最近看韩国电视剧【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组件库感兴趣的小伙伴，欢迎加群一起交流哦！

htmx 的走红

过去 Web 非常简单。URL 指向服务器，服务器将数据混合成 html，然后在浏览器上呈现该响应。围绕这种简单范式，诞生了各种 Javascript 框架，以前可能需要数月时间完成的一个应用程序基本功能，现在借助这些框架创建相对复杂的项目却只需要数小时，我们节省了很多时间，从而可以将更多精力花在业务逻辑和应用程序设计上。

但随着 Web 不断地发展，Javascript 失控了。不知何故，我们决定向用户抛出大量 App，并在使用时发出不断增加的网络请求；不知何故，为了生成 html，我们必须使用 JSON，发出数十个网络请求，丢弃我们在这些请求中获得的大部分数据，用一个越来越不透明的 JavaScript 框架黑匣子将 JSON 转换为 html，然后将新的 html 修补到 DOM 中......

难道大家快忘记了我们可以在服务器上渲染 html 吗？更快、更一致、更接近应用程序的实际状态，并且不会向用户设备发送任何不必要的数据？但是如果没有 Javascript，我们必须在每次操作时重新加载页面。

现在，有一个新的库出现了，摒弃了定制化的方法，这就是 htmx。作为 Web 开发未来理念的一种实现，它的原理很简单：

• 从任何用户事件发出 AJAX 请求。

• 让服务器生成代表该请求的新应用程序状态的 html。

• 在响应中发送该 html。

• 将该元素推到它应该去的 DOM 中。

htmx 出现在 2020 年，创建者Carson Gross 说 htmx 来源自他于 2013 年研究的一个项目intercooler.js。2020 年，他重写了不依赖 jQuery 的 intercooler.js，并将其重命名为 htmx。然后他惊讶的发现 Django 社区迅速并戏剧性地接受了它！

图片来源：lp.jetbrains.com/django-deve…2021-486/

Carson Gross认为 htmx 设法抓住了开发者对现有 Javascript 框架不满的浪潮，“这些框架非常复杂，并且经常将 Django 变成一个愚蠢的 JSON 生产者”，而 htmx 与开箱即用的 Django 配合得更好，因为它通过 html 与服务器交互，而 Django 非常擅长生成 html。

对于 htmx 的迅速走红，Carson Gross 发出了一声感叹：这真是“十年窗下无人问，一举成名天下知（this is another example of a decade-long overnight success）”。

htmx 的实际效果

可以肯定的一点是 htmx 绝对能用，单从理论上讲，这个方法确实值得称道。但软件问题终究要归结于实践效果：效果好吗，能不能给前端开发带来改善？

在 DjangoCon 2022 上，Contexte 的 David Guillot 演示了他们在真实 SaaS 产品上实现了从 React 到 htmx 的迁移，而且效果非常好，堪称“一切 htmx 演示之母”（视频地址：http://www.youtube.com/watch?v=3GO…）。

Contexte 的项目开始于 2017 年，其后端相当复杂，前端 UI 也非常丰富，但团队非常小。所以他们在一开始的时候跟随潮流选择了 React 来“构建API绑定 SPA、实现客户端状态管理、前后端状态分离”等。但实际应用中，因为 API 设计不当，DOM 树太深，又需要加载很多信息，导致 UI“非常非常缓慢”。在敏捷开发的要求下，团队里唯一的 Javascript 专家对项目的复杂性表现得一无所措，因此他们决定试试 htmx。

九大数据提升

于是我们决定大胆尝试，花几个月时间用简单的 Django 模板和 htmx 替换掉了 SaaS 产品中已经使用两年的 React UI。这里我们分享了一些相关经验，公布各项具体指标，希望能帮同样关注 htmx 的朋友们找到说服 CTO 的理由！

• 这项工作共耗费了约 2 个月时间（使用 21K 行代码库，主要是 JavaScript）

• 不会降低应用程序的用户体验（UX）

• 将代码库体积减小了 67%（由 21500 行削减至 7200 行）

• 将 Python 代码量增加了 140%（由 500 行增加至 1200 行）；这对更喜欢 Python 的开发者们应该是好事

• 将 JS 总体依赖项减少了 96%（由 255 个减少至 9 个）

• 将 Web 构建时间缩短了 88%（由 40 秒缩短至 5 秒）

• 首次加载交互时间缩短了 50%至 60%（由 2 到 6 秒，缩短至 1 到 2 秒）

• 使用 htmx 时可以配合更大的数据集，超越 React 的处理极限

• Web 应用程序的内存使用量减少了 46%（由 75 MB 降低至 40 MB）

这些数字令人颇为意外，也反映出 Contexte 应用程序高度契合超媒体的这一客观结果：这是一款以内容为中心的应用程序，用于显示大量文本和图像。很明显，其他 Web 应用程序在迁移之后恐怕很难有同样夸张的提升幅度。

但一些开发者仍然相信，大部分应用程序在采用超媒体/htmx 方法之后，肯定也迎来显著的改善，至少在部分系统中大受裨益。

开发团队组成

可能很多朋友没有注意，移植本身对团队结构也有直接影响。在 Contexte 使用 React 的时候，后端与前端之间存在硬性割裂，其中两位开发者全职管理后端，一位开发者单纯管理前端，另有一名开发者负责“全栈”。（这里的「全栈」，代表这位开发者能够轻松接手前端和后端工作，因此能够在整个「栈」上独立开发功能。）

而在移植至 htmx 之后，整个团队全都成了“全栈”开发人员。于是每位团队成员都更高效，能够贡献出更多价值。这也让开发变得更有乐趣，因为开发人员自己就能掌握完整功能。最后，转向 htmx 也让软件优化度上了一个台阶，现在开发人员可以在栈内的任意位置进行优化，无需与其他开发者提前协调。

htmx 是传统思路的回归

如今，单页应用（SPA）可谓风靡一时：配合 React、Redux 或 Angular 等库的 JS 或 TS 密集型前端，已经成为创建 Web 应用程序的主流方式。以一个需要转译成 JS 的 SPA 应用为例：

但 htmx 风潮已经袭来，人们开始强调一种“傻瓜客户端”方法，即由服务器生成 html 本体并发送至客户端，意味着 UI 事件会被发送至服务器进行处理。

用这个例子进行前后对比，我们就会看到前者涉及的活动部件更多。从客户端角度出发，后者其实回避了定制化客户端技术，采取更简单的方法将原本只作为数据引擎的服务器变成了视图引擎。

后一种方法被称为 AJAX（异步 JavaScript 与 XML）。这种简单思路能够让 Web 应用程序获得更高的响应性体验，同时消除了糟糕的“回发”（postback，即网页完全刷新），由此回避了极其低效的“viewstate”等.NET 技术。

htmx 在很多方面都体现出对 AJAX 思路的回归，最大的区别就是它仅仅作为新的声明性 html 属性出现，负责指示触发条件是什么、要发布到哪个端点等。

另一个得到简化的元素是物理应用程序的结构与构建管道。因为不再涉及手工编写 JS，而且整个应用程序都基于服务器，因此不再对 JS 压缩器、捆绑器和转译器做（即时）要求。就连客户端项目也能解放出来，一切都由 Web 服务器项目负责完成，所有应用程序代码都在.NET 之上运行。从这个角度来看，这与高度依赖服务器的Blazor Server编程模型倒是颇有异曲同工之妙。

技术和软件开发领域存在一种有趣的现象，就是同样的模式迭起兴衰、周而复始。随着 SPA 的兴起，人们一度以为 AJAX 已经过气了，但其基本思路如今正卷土重来。这其中当然会有不同的权衡，例如更高的服务器负载和网络流量（毕竟现在我们发送的是数据视图，而不只是数据），但能让开发者多个选择肯定不是坏事。

虽然不敢确定这种趋势是否适用于包含丰富用户体验的高复杂度应用程序，但毫无疑问，相当一部分 Web 应用程序并不需要完整的 SPA 结构。对于这类用例，简单的 htmx 应用程序可能就是最好的解决方案。

参考链接：

news.ycombinator.com/item?id=332…

htmx.org/essays/a-re…

http://www.reddit.com/r/django/co…

mekhami.github.io/2021/03/26/…

http://www.compositional-it.com/news-blog/m…

Taro开发小程序记录-海报生成

在公司开发的第一个项目是一个简单的Taro小程序项目，主要应用的则是微信小程序，由于是第一次使用Taro，所以在开发过程中遇到的一些问题和一些开发技巧，记录一下，方便以后进行查看，也与大家进行分享。

自定义海报

说到自定义海报可以说是很多小程序中都会进行开发的内容，比如需要进行二维码的保存，然后再对二维码进行一点文字的修饰，涉及到这方面的时候我们就需要使用canvas了。

在实际开发的过程中，遇到了一些很坑的问题，当我们需要使用离屏canvas来进行绘制时，我们可能就会遇到问题(我自己就遇到了)。

对于安卓端，我们可以正常的使用OffscreenCanvas来创建离屏canvas，然后绘制相关内容，最后在使用Taro.canvasToTempFilePath方法保存到临时文件下，Taro.canvasToTempFilePath方法会返回文件路径，我们就可以通过获取到的文件路径来进行下载。

下面是安卓端的一个🌰，大家有需要也可以直接拿去使用

• 需要使用到的方法

 /**

  * @description 获取二维码图像

  */

 export const qrCodeImage = async (qrCodeValue: string, size: number = 128) => {

     /* NOTE: 通过创建离屏canvas承载code */

     const context = createOffscreenCanvas('2d', size, size);

     QRCode.toCanvas(context, qrCodeValue, { width: size, height: size, margin: 1 });

     return (context as unknown as HTMLCanvasElement).toDataURL();

 };

 /**

  * @description 创建离屏canvas对象，width与height单位为px

  */

 export const createOffscreenCanvas = (type: '2d' | 'webgl', width: number = 100, height: number = 100) => {

     return Taro.createOffscreenCanvas({ type, width, height });

 };

 /**

  * @description 将传入的图片url转换成一个ImageElement对象

  */

 export const loadImageByUrlToCanvasImageData = async (url: string, width: number = 100, height: number = 100) => {

     const context = createOffscreenCanvas('2d', width, height);

     const imageElement = context.createImage();

     await new Promise(resolve => {

         imageElement.onload = resolve;

         imageElement.src = url;

     });

     return imageElement;

 };

 /**

  * @description 将canvas转成图片文件并保存在临时路径下

  */

 export const changeCanvasToImageFileAndSaveToTempFilePath = async (options: Taro.canvasToTempFilePath.Option) => {

     const successCallback = await Taro.canvasToTempFilePath(options);

     return successCallback.tempFilePath;

 };

 interface SettingOptions {

     title: string;

     titleInfo: {

         dx: number;

         dy: number;

         color?: string;

         font?: string;

     };

     imageUrl: string;

     imagePos: {

         dx: number;

         dy: number;

     };

     width: number;

     height: number;

 }

 /**

  * @description 获取二维码图像并设置标题

  */

 export const generateQrCodeWithTitle = async (option: SettingOptions): Promise<string> => {

     const {

         title,

         titleInfo,

         imageUrl,

         imagePos,

         width,

         height,

     } = option;

     const context = await createOffscreenCanvas('2d', width, height);

     const ctx = (context.getContext('2d') as CanvasRenderingContext2D);

     const imgElement: any = await loadImageByUrlToCanvasImageData(imageUrl, width, height);

     ctx.fillStyle = 'white';

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

     ctx.fillStyle = titleInfo.color || 'black';

     ctx.font = titleInfo.font || '';

     ctx.textAlign = 'center';

     ctx.fillText(title, titleInfo.dx || 0, titleInfo.dy || 0);

     ctx.drawImage(imgElement, imagePos.dx, imagePos.dy);

 

     const filePath = await changeCanvasToImageFileAndSaveToTempFilePath({

         canvas: (context as Canvas),

         width,

         height,

         fileType: 'png',

         destWidth: width,

         destHeight: height,

     });

     return filePath;

 };

 /**

  * @description 保存图片

  */

 export const saveImage = async (urls: string[], isLocal: boolean = true) => {

     let filePath = urls;

     if (!isLocal) {

         filePath = await netImageToLocal(urls);

     }

     await Promise.all(filePath.map(path => {

         return Taro.saveImageToPhotosAlbum({ filePath: path });

     }));

 

     return true;

 };

 /**

  * @description 加载在线图片，并返回临时图片文件地址

  */

 export const netImageToLocal = async (urls: string[]) =>  {

     const res = await Promise.all(urls.map((url:string) => {

         return Taro.downloadFile({ url });

     }));

 

     const result = res.map(data => {

         if (data.statusCode === 200) {

             return data.tempFilePath;

         }

         throw new Error(data.errMsg);

     });

 

     return result;

 };

 /**

  * @description 判断用户是否授权保存图片

  */

 export const checkHasAuthorizedSaveImagePermissions = async () => {

     const setting = await Taro.getSetting();

     const { authSetting } = setting;

     return authSetting['scope.writePhotosAlbum'];

 };

 /**

  * @description 下载图片,需要区分是本地图片还是在线图片

  */

 export const downloadImage = async (urls: string[], isLocal: boolean = true) => {

     const hasSaveImagePermissions = await checkHasAuthorizedSaveImagePermissions();

     if (hasSaveImagePermissions === undefined) {

         // NOTE: 用户未授权情况下，进行用户授权，允许保存图片

         await Taro.authorize({ scope: 'scope.writePhotosAlbum' });

         return await saveImage(urls, isLocal);

     } else if (typeof hasSaveImagePermissions === 'boolean' && !hasSaveImagePermissions) {

         return new Promise((resolve, reject) => {

             Taro.showModal({

                 title: '是否授权保存到相册',

                 content: '需要获取您的保存图片权限，请确认授权，否则图片将无法保存到相册',

                 success: (result) => {

                     if (result.confirm) {

                         Taro.openSetting({

                             success: async (data) => {

                                 if (data.authSetting['scope.writePhotosAlbum']) {

                                     showLoadingModal('正在保存...');

                                     resolve(await saveImage(urls, isLocal));

                                 }

                             },

                         });

                     } else {

                         reject(new Error('未授予保存权限'));

                     }

                 },

             });

         });

     }

     await saveImage(urls, isLocal);

     return true;

 };

• 生成海报（二维码+标题头）

 /**

  * @description 获取二维码图像并设置标题

  */

 export const generateQrCodeWithTitle = async (option: SettingOptions): Promise<string> => {

     const {

         title,

         titleInfo,

         imageUrl,

         imagePos,

         width,

         height,

     } = option;

     const context = await createOffscreenCanvas('2d', width, height);

     const ctx = (context.getContext('2d') as CanvasRenderingContext2D);

     const imgElement: any = await loadImageByUrlToCanvasImageData(imageUrl, width, height);

     ctx.fillStyle = 'white';

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

     ctx.fillStyle = titleInfo.color || 'black';

     ctx.font = titleInfo.font || '';

     ctx.textAlign = 'center';

     ctx.fillText(title, titleInfo.dx || 0, titleInfo.dy || 0);

     ctx.drawImage(imgElement, imagePos.dx, imagePos.dy);

 

     const filePath = await changeCanvasToImageFileAndSaveToTempFilePath({

         canvas: (context as Canvas),

         width,

         height,

         fileType: 'png',

         destWidth: width,

         destHeight: height,

     });

     return filePath;

 };

• 具体使用

 export const saveQrCodeImageWithTitle = async () => {

     const url = await qrCodeImage(enterAiyongShopUrl(), 160);

     const imgUrl: string = await generateQrCodeWithTitle({

         title: 'adsionli菜鸡前端',

         titleInfo: {

             dx: 95,

             dy: 20,

             font: '600 14px PingFang SC',

             color: 'black',

         },

         imageUrl: url,

         imagePos: {

             dx: 15,

             dy: 34,

         },

         width: 190,

         height: 204,

     });

     await downloadImage([imgUrl]);

 }

上面三块内容就可以组成我们的海报生成了，这里面的主要步骤不是很难，包括了几个方面：

1. 用户授权鉴定，主要是是否允许保存，这里做了一点处理，就是可以在用户第一次授权不允许时，进行二次授权调起，这个可以看一下上面的downloadImage这个函数，以及用于判断用户是否授权的checkHasAuthorizedSaveImagePermissions这个函数
2. 创建OffscreenCanvas并进行绘制，这里其实没有太多的难点，主要就是需要知道，如果我们使用image的内容的话，或者是一个图片的url时，我们需要先将其绘制到一个canvas上(这里可以获取imageElement对象，也可以直接使用canvas)，这样方便我们后面进行drawImage时进行使用
3. 图片保存，这里也有一个需要注意的点，如果图片(或二维码)是网络图片的话，我们需要处理以下，先将其转成本地图片，也就是通过netImageToLocal这个方法，然后再还给对应的将图片画在canvas上的方法。最后的保存很简单，我们可以直接使用Taro.canvasToTempFilePath这个方法转到临时地址，再通过downloadImage就可以搞定了。

感觉好像很麻烦，其实就四步：图片加载转化—>canvas绘制—>用户鉴权—>图片保存。

安卓端实现起来还是很简单的，但是这些方法对于ios端就出现了问题，如果按照上面的路线进行海报绘制保存的话，在ios端就会报一个错误(在本地开发的时候并不会抛出): canvasToTempFilePath:fail invalid viewId

这一步错误就是发生在Taro.canvasToTempFilePath这里，保存到临时文件时会触发，然后这一切的原因就是使用了OffscreenCanvas离屏canvas造成的。

所以为了能够兼容ios端的这个问题，有了以下的修改：

首先需要在我们要下载海报的pages中，添加一个Canvas，帮助我们可以获取CanvasElement

 <Canvas

     type='2d'

     id='qrCodeOut'

     className='aiyong-shop__qrCode'

 />

这里需要注意一下，我们需要添加一个type='2d'的属性，这是为了能够使用官方提供的获取Canvas2dContext的属性，这样就可以不使用createCanvasContext这个方法来获取了(毕竟已经被官方停止维护了)。

然后我们就可以获取一下CanvasElement对象了

 /**

  * @description 获取canvas标签对象

  */

 export const getCanvasElement = (canvasId: string): Promise<Taro.NodesRef> => {

     return new Promise(resolve => {

         const canvasSelect: Taro.NodesRef = selectQuery().select(`#${canvasId}`);

         canvasSelect.node().exec((res: Taro.NodesRef) => {

             resolve(res);

         });

     });

 };

注：这里又有一个小坑，我们在获取CanvasElement之后，如果直接进行绘制的话，这里存在一个问题，就是这个CanvasElement的width:300、height:150被限制死了，所以我们需要自己在拿到CanvasElement之后，在设置一下width、height。

 const canvasNodeRef = await getCanvasElement(canvas);

 let context;

 if (canvasNodeRef && canvasNodeRef[0].node !== null) {

     context = canvasNodeRef[0].node;

     (context as Taro.Canvas).width = width;

     (context as Taro.Canvas).height = height;

 }

好了，改造完成，这样就可以兼容ios端的内容了，实际我们只需要修改generateQrCodeWithTitle这个方法和page新增Canvas用于获取CanvasElement就可以了，其他可以不要动。修改后的generateQrCodeWithTitle方法如下:

 /**

  * @description 获取二维码图像并设置标题

  */

 export const generateQrCodeWithTitle = async (option: SettingOptions): Promise<string> => {

     const {

         title,

         titleInfo,

         imageUrl,

         imagePos,

         width,

         height,

         qrCodeSize,

         canvas,

     } = option;

     const canvasNodeRef = await getCanvasElement(canvas);

     let context;

     if (canvasNodeRef && canvasNodeRef[0].node !== null) {

         context = canvasNodeRef[0].node;

         (context as Taro.Canvas).width = width;

         (context as Taro.Canvas).height = height;

     }

     const ctx = (context.getContext('2d') as CanvasRenderingContext2D);

     const imgElement: Taro.Image = await loadImageByUrlToCanvasImageData(imageUrl, qrCodeSize.width, qrCodeSize.height);

     ctx.fillStyle = 'white';

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

     ctx.fillStyle = titleInfo.color || 'black';

     ctx.font = titleInfo.font || '';

     ctx.textAlign = 'center';

     ctx.fillText(title, titleInfo.dx || 0, titleInfo.dy || 0);

     ctx.drawImage((imgElement as HTMLImageElement), imagePos.dx, imagePos.dy, imgElement.width, qrCodeSize.height);

 

     const filePath = await changeCanvasToImageFileAndSaveToTempFilePath({

         canvas: (context as Canvas),

         width,

         height,

         fileType: 'png',

         destWidth: width,

         destHeight: height,

     });

     return filePath;

 };

如果大家不想让海报被人看到，那可以设置一下css

 .qrCode {

     position: fixed;

     left: 100%;

 }

这样就可以啦

突然发现内容可能有点多了，所以打算分成两篇进行Taro使用过程中的总结，开发完之后进行总结，总是可以让自己回顾在开发过程中遇到的问题的进一步进行思考，这是一个很好的进步过程，加油加油！！！

背景

前两天下午，测试同学反馈生产环境有个功能出现异常，然后给我发了张报错截图。 

随后在测试同学的电脑复现并排查问题，通过异常断点，捕捉到异常信息如下： 

可以看到异常的原因是 n.path 的值为 undefined，因此 n.path.find 等价于 undefined.find，因此程序报错。其中 n 是一个 Event 实例；path 是事件冒泡经过的节点组成的数组。n.path 有值的情况如下： 

Event.path 不是标准属性，常见于 chrome 浏览器，取不到值出现异常不足为奇，只要做个兼容就搞定了，当 Event.path 取不到值时就取 Event.composedPath()。那这是兼容性问题吗，事情好像没有这么简单。仔细对比上述两张截图可以发现，异常时 Event 实例甚至不存在 path 属性，这跟属性存在但值为空是两码事。

进一步排查

好好的 path 属性怎么就不翼而飞了，这是个神奇的问题。当我用自己电脑尝试复现问题时，发现功能正常且无法复现，事情变得更加神奇。两边浏览器都升到了最新版 chrome 108，区别是系统不同，一个是 windows 一个是 macOS。也就是 说同样的代码在同样的软件上跑出了不同结果，这说明可能不是代码或兼容性问题。

为找出真正的原因，我做了几组对照实验，以排除代码、硬件、操作系统和浏览器的影响。情况如下 ：

分析这些结果，出现了更有意思的事：只有一种情况会出现异常，使用测试同学的电脑且浏览器是 chrome 108；当改变电脑、系统、浏览器、浏览器版本等因素时结果都是正常。 也就是说导致异常的因素居然不是单一的，而是多个因素组合（测试同学电脑+chrome+108 版本）产生的结果。

chromium issue 的助攻

从上面的结果看好像没办法再继续排查下去，不过从经验判断，多半是 chrome 又在搞事，这时候可以去 chromium issue 里找找蛛丝马迹，经过一番搜索找到了这条 issue: Issue 1277431: Remove event.path。 

issue 标题很直白，Event.path 将被删除。 从 issue 内容可以看到，这次搞事是从 2021 年 12 月 7 日开始，起因是 chromium 开发团队认为 Event.path 属于非标准 API，会导致 Firefox 等其他浏览器的兼容性问题，于是他们决定将其删除。目前这个变更在 chrome 108 属于灰度阶段，在即将发布的 chrome 109 上会全面应用，webview 则是从 109 版本开始逐步禁用。

变更详情和计划

另外 issue 中提到这个变更会在 console 中进行告警。 

console 中确实有这个告警，不过藏在 console 面板的右上角，不太容易发现，而且需要调用 Event.path 后才会显示。点进去之后会跳转到 Issues 面板并显示详细信息。
 

从图中可以看到这个变更属于 Breaking Change，即破坏性变更。另外可以看到变更详情链接和版本计划链接。打开变更详情链接可以看到详细的说明、目的、状态、开发阶段等信息。 

打开版本计划链接可以看到，chrome 108 已经在 2022-11-29 正式发布（Stable Release Tue, Nov 29, 2022），chrome 109 将在 2023-01-10 正式发布（Stable Release Tue, Jan 10, 2023）。 

验证

由于英文水平有限，为了避免个人理解存在歧义，使用 chrome 的前瞻版本进行测试，以验证 chrome 108 之后的版本是否真的会应用这个变更。

• 测试使用的系统为 macOS，浏览器版本包括：chrome-stable（108.0.5359.124）、chrome-beta（109.0.5414.36）、chrome-dev（110.0.5464.2）、chrome-canary（110.0.5477.0）。

• 测试代码如下

<!DOCTYPE html>

<html lang="en">

  <head></head>

  <body>

    <script>

      function test() {

        console.log("event.path is:", window.event.path);

      }

    </script>

    <h1 onclick="test()">click me</h1>

  </body>

</html>

• 测试结果如下

chrome-stable（108.0.5359.124）在 macOS 下 Event.path 有值，结合上文的对照实验中 windows10 下一个有值一个为空。说明 chrome 108 中该变更属于灰度阶段。

chrome-beta（109.0.5414.36）、chrome-dev（110.0.5464.2）、chrome-canary（110.0.5477.0）在 macOS 下 Event.path 都为空，说明 chrome 109 之后全面删除了 Event.path 属性。

解决方案

先看影响范围，从项目维度来看，所有前端项目都可能受到影响；从代码维度来看，项目源码和第三方依赖都可能受影响。在 github 中搜索发现 swipper、openlayers 等第三方库中都有相关 issue。因此解决方案需要全面考虑：最好对所有项目都进行排查修复，另外不仅要排查源码，还要考虑第三方库。

根据官方建议及综合考虑，推荐在前端项目中统一添加如下 polyfill 代码：

  Object.defineProperty(Event.prototype, "path", {

    get() {

      return this.composedPath();

    },

  });

最后

chrome 109 预计在 2023-01-10 正式发布，届时会全面禁用 Event.path，所有源码中使用该属性或第三方库使用该属性的前端项目都可能会出现异常，还有 20 几天时间，建议尽快排查修复。

一些经验

• 关注 chorme 迭代计划，有条件可以做前瞻性测试，预防未来可能发生的异常