引言

一天哈比比突然冒出一个毫无理头的一个问题:

本文就该问题进行展开...

一、需求说明

大致需求如下, 当然这里做了些简化

有如下初始代码:

• 一个自适应的表格
• 每个单元格的宽度固定 200px
• 每个单元格高度则是自适应
• 每个单元格内是一个 div 标签, div 标签内包裹了一段文本, 文本内容不定

下面是初始代码(为了方便演示和美观, 代码中还加了些背景色、边距、圆角, 这些都是可以忽略):

<table>

  <tr>

    <td width="400">

      <div>

        路由器管理页面路由器管理页面路由器管理页面路由器管理页面路由器管理页面路由器管理页面

        路由器管理页面路由器管理页面路由器管理页面路由器管理页面路由器管理页面路由器管理页面

        路由器管理页面路由器管理页面路由器管理页面路由器管理页面路由器管理页面路由器管理页面

      div>

    td>

    <td width="400">

      <div>

        路由器管理页面路由器管理页面路由器管理页面路由器管理页面路由器管理页面路由器管理页面

        路由器管理页面路由器管理页面路由器管理页面路由器管理页面路由器管理页面路由器管理页面

      div>

    td>

    <td width="400">

      <div>

        路由器管理页面路由器管理页面路由器管理页面路由器管理页面路由器管理页面路由器管理页面

      div>

    td>

  tr>

table>

<style>

  table {

    background: #f5f5f5;

  }

  

  td {

    background: #ffccc7;

  }



  table, tr, td {

    padding: 12px;

    border-radius: 4px;

  }



  td > div {

    padding: 12px;

    border-radius: 4px;

    background: #f4ffb8;

  }

style>

上面代码的整体效果如下:

上面是哈比比目前的现状, 然后需求就是希望, 黄色部分也就是 div 标签能够高度撑满单元格(td), 也就是如下图所示:

二、关键问题

这里我第一反应就是, 既然 td 高度是对的(自适应)的那么 div 高度直接设置 100% 不就好了吗? 事实是这样的吗? 我们可以试下:

  ...

实际效果肯定是没有用的, 要不然也就不会有这篇文章了 🐶🐶🐶

主要问题: 在 CSS 中如果父元素没有一个明确的高度, 子元素设置 100% 是无法生效的, 至于为啥就不能生效呢, 因为如果可以, 那么必然会进入死循环这里可以参考张鑫旭大大的文章《从 height:100% 不支持聊聊 CSS 中的 "死循环"》

三、方案一(定位)

通过定位来实现, 也是哈比比最初采用的一个方案:

• td 设置相对定位即: position: relative;
• td 下的子元素通过相对定位(position: absolute;)撑满

....

整体效果如下:

上面代码其实我并没有给所有 td 中的 div 设置 position: absolute; 目的是为了留一个内容最多的块, 来将 tr、 td 撑开, 如果不这么做就会出现下面这种情况:

所以, 严格来说该方案是不行的, 但是可能哈比比情况比较特殊, 他只有空值和有内容两种情况, 所以他完全可以通过判断内容是否为空来设置 position: absolute; 即可

四、方案二(递归设置 height 100%)

第二个方案就是给 table、tr、td 设置一个明确的高度即 100%, 这样的话 td 中的子元素 div 再设置高度 100% 就可以生效了

效果如下:

上面第一个单元格高度其实还是有点问题, 目前也没找到相关研究可以结束这个现象, 要想达到我们要的效果解决办法有两个:

1. 移除代码中所有 padding, 有关代码和效果图如下:

2. 修改 td 中 div 的 box-sizing 属性为 border-box, 有关代码和效果图如下:

五、方案三(利用 td 自增加特效, 推荐)

方案三是比较推荐的做法, 其利用了 td 自增加的一个特效, 那么何谓自增加呢? 假设我们给 td 设置可一个高度 1px 但是呢它实际高度实际上是会根据 tr 的高度进行自适应(自动增长), 那么在这种情况下我们给 td 下子元素 div 设置高度 100% 则会奏效, 因为这时的 td 高度是明确的

<table>

  <tr>

    <td width="400">

      <div>

        路由器管理页面路由器管理页面路由器管理页面路由器管理页面路由器管理页面路由器管理页面

        路由器管理页面路由器管理页面路由器管理页面路由器管理页面路由器管理页面路由器管理页面

        路由器管理页面路由器管理页面路由器管理页面路由器管理页面路由器管理页面路由器管理页面

      div>

    td>

    <td width="400">

      <div>

        路由器管理页面路由器管理页面路由器管理页面路由器管理页面路由器管理页面路由器管理页面

        路由器管理页面路由器管理页面路由器管理页面路由器管理页面路由器管理页面路由器管理页面

      div>

    td>

    <td width="400">

      <div>

        路由器管理页面路由器管理页面路由器管理页面路由器管理页面路由器管理页面路由器管理页面

      div>

    td>

  tr>

table>

<style>

  table {

    background: #f5f5f5;

  }

  

  td {

    height: 1px; /* 关键代码 */

    background: #ffccc7;

  }



  table, tr, td {

    padding: 12px;

    border-radius: 4px;

  }



  td > div {

    height: 100%; /* 关键代码 */

    padding: 12px;

    border-radius: 4px;

    background: #f4ffb8;

  }

style>

效果如下:

六、补充: td 下 div 内容顶对齐

几天后, 哈比比又来找我了 🐶🐶🐶

这次需求就比较简单了, 就是 td 中默认情况下子元素(p)都是居中呈现的, 现想要的就是能否居上(置顶)展示

这里初始代码和上面是一样的:

<table>

  <tr>

    <td width="400">

      <div>

        路由器管理页面路由器管理页面路由器管理页面路由器管理页面路由器管理页面路由器管理页面

        路由器管理页面路由器管理页面路由器管理页面路由器管理页面路由器管理页面路由器管理页面

        路由器管理页面路由器管理页面路由器管理页面路由器管理页面路由器管理页面路由器管理页面

      div>

    td>

    <td width="400">

      <div>

        路由器管理页面路由器管理页面路由器管理页面路由器管理页面路由器管理页面路由器管理页面

        路由器管理页面路由器管理页面路由器管理页面路由器管理页面路由器管理页面路由器管理页面

      div>

    td>

    <td width="400">

      <div>

        路由器管理页面路由器管理页面路由器管理页面路由器管理页面路由器管理页面路由器管理页面

      div>

    td>

  tr>

table>

<style>

  table {

    background: #f5f5f5;

  }

  

  td {

    background: #ffccc7;

  }



  table, tr, td {

    padding: 12px;

    border-radius: 4px;

  }



  td > div {

    padding: 12px;

    border-radius: 4px;

    background: #f4ffb8;

  }

style>

默认效果就是 div 都居中展示:

这里我第一反应是用 vertical-align 但是该属性在很多人印象中只针对 行内元素(或文本)才能生效, 但这里是 div 是 块元素 所以哈比比自然就忽略了该 vertical-align 属性

但实际上如果查阅文档会发现 vertical-align 实际用途有两个:

1. 用来指定行内元素(inline)的垂直对齐方式
2. 表格单元格(table-cell)元素的垂直对齐方式

所以这个问题就简单了, 一行 CSS 就解决了:

完美实现(最终效果):

七、参考

• How to make
  fill height
• 从 height:100% 不支持聊聊 CSS 中的 "死循环"

作者：墨渊君
来源：juejin.cn/post/7436027021057884172

本文为稀土掘金技术社区首发签约文章，30天内禁止转载，30天后未获授权禁止转载，侵权必究！

前言

在基于GIS的数据可视化层面，我们能够展示的基本数据无非就是点线面体，其中，离散的点数据出现的情况相对较为普遍，通常POI（Point of Interest）的展示方式和丰富程度对于用户体验和地图的实用性有着重要的影响。在这篇技术分享文章中，我们将由浅入深地探讨如何在高德地图上创建大量立体 POI。相信通过本文的介绍，开发者能够受到启发，并且掌握这一个不错的技巧，为地图点数据的展示和应用带来新的视觉和功能体验。

需求分析

首先收集一波需求：在地图上展示大量的POI，能够配置用第三方工具制作的模型，作为POI的主体，能够实现基本的鼠标交互操作，比如鼠标悬浮状态下具有区别于其他POI的特殊的形态或者动画，每个POI能够根据自身属性出现特异的外观，再厉害一点的能不能实现固定POI在屏幕上的大小，即POI的尺寸不会随着地图缩放的远近而出现变化。

根据以上琐碎的内容我们可以整理为以下功能描述，下文我们将一步步实现这些需求：

• 支持灵活配置POI模型，POI样式可调整


• 能够支持大数据量（10000+）的POI展示


• 支持鼠标交互，能够对外派发事件


• 支持动画效果


• 支持开启一种模式，不会随地图远近缩放而改变POI的可见尺寸

实现步骤

从基础功能到进阶功能逐步完善这个POI图层，篇幅有限每个功能仅陈述开发原理以及核心代码，完整的代码工程可以到这里查看下载。

加载模型到场景中

解决大量模型的性能问题

上文的方案用来处理数据量较小的场景基本上是没有问题的，然而现实中往往有大量散点数据的情况需要处理，这时候需要THREE.InstancedMesh 出手了，InstanceMesh用于高效地渲染大量相同几何形状但具有不同位置、旋转或其他属性的物体实例，使用它可以显著提高渲染性能，尤其是在需要渲染大量相似物体的场中，比如一片森林中的树木、一群相似的物体等。

实现数据特异性

从上一步骤updateInstancedMesh方法中，我们不难发现在对每个POI进行实例化的时候都会调用一次变化装置矩阵和设置颜色，因此我们可以通过对每个POI设定不同的尺寸、朝向等空间状态来实现数据的特异性。

实现鼠标交互

我们实现这样一种交互效果，所有POI主体静止不动，当鼠标悬浮在POI上，则POI开始转动画，且在POI上方出现广告牌显示它的名称属性。这里涉及到three.js中的射线碰撞检测和对外派发事件。主要的业务逻辑如下图：

实现PDI效果

PDI即像素密度无关模式，本意是使图形元素、界面布局和内容在各种不同像素密度的屏幕上都能保持相对一致的显示效果和视觉体验 ，在此我们借助这个概念作为配置参数，来实现POI不会随着地图远近缩放而更改尺寸的效果。

在这里我们会用到高德API提供的非常重要的方法Map.getResolution()，它用于获取指定位置的地图分辨率（单位：米/像素），即当前缩放尺度下，1个像素长度可以代表多少米长度，在每次地图缩放时POI示例必须根据这个系数进行缩放，才能保证在视觉上是没有变化尺寸的。

接下来进行代码实现，对上文的代码再次进行改造：

代码封装

最后为了让我们的代码具有复用性，我们将它封装为POI3dLayer类，将模型、颜色、尺寸、PDI、是否可交互、是否可动画等作为配置参数，具体操作可以看POI3dLayer.js这个类的写法。

//创建一个立体POI图层

async function initLayer() {

      const map = getMap()

      const features = await getData()

      const layer = new POI3dLayer({

          map,

          data: { features },

          size: 20,

          PDI: false

      })



      layer.on('pick', (event) => {

          const { screenX, screenY, attrs } = event

          updateMarker(attrs)

      })

  }

  

  // POI类的构造函数

  

   /**

   *  创建一个实例

   *  @param {Object}   config

   *  @param {GeoJSON|Array}  config.data  图层数据

   *  @param {ColorStyle}   [config.colorStyle] 顔色配置

   *  @param {LabelConfig}   [config.label] 用于显示POI顶部文本

   *  @param {ModelConfig[]}  [config.models] POI 模型的相关配置数组,前2个成员modelId必须为main和tray

   *  @param {Number}   [config.maxMainAltitude=1.0] 动画状态下，相对于初始位置的向上最大值, 必须大于minMainAltitude

   *  @param {Number}   [config.minMainAltitude=0]   动画状态下，相对于初始位置的向下最小距离, 可以为负数

   *  @param {Number}   [config.mainAltitudeSpeed=1.0] 动画状态下，垂直移动速度系数

   *  @param {Number}   [config.rotateSpeed=1.0] 动画状态下，旋转速度

   *  @param {Number}   [config.traySpeed=1.0] 动画状态下，圆环波动速度

   *  @param {Array}    [config.scale=1.0] POI尺寸系数, 会被models[i].size覆盖

   *  @param {Boolean}  [config.PDI=false] 像素密度无关(Pixel Density Independent)模式，开启后POI尺寸不会随着缩放而变化

   *  @param {Number}   [config.intensity=1.0] 图层的光照强度系数

   *  @param {Boolean}  [config.interact=true] 是否可交互

   */

   class POI3dLayer extends Layer {

		   constructor (config) {

				   super(conf)

					 //...

			 }

   }

这样一来我们配置模型和颜色就很便捷了，试试其他业务场景效果貌似也还可以，今天就到这里吧。

相关链接

演示工程代码gitbub地址

高德JS API 2.0 Map文档

前言

低代码由来已久，主要是减少开发人员的编码时间，提高产品交付效率，甚至功能完备的低代码平台可以使非开发人员使用。

正如此，多年来，低代码平台层不出穷，但依然没有出现现象级的产品，不过，大多数公司也都有自己的低代码平台，体验和效果也是参差不齐。

新范式的到来

如今人工智能又达到了一个新的阶段，有预言说，它最先代替的是程序员。我认为这很难，如果你深度使用了ChatGPT，它确实非常非常惊艳，但是，要想取代程序员，还为时过早。不过如果能够善加利用，它将是一把利器，可以事半功倍。

但是，目前还没有发现一款体验非常好的GPT产品可以无缝的与开发环境融合。即使“历史悠久”的GitHub Copilot也没有达到一种理想效果，虽然还有它的孪生兄弟GitHub Copilot Chat也总是缺少一些体验。

虽然现在还没一个非常好的产品来辅助我们开发（GitHub Copilot已经很好了），但是也不影响一个新的范式即将到来，GPT注定会改变我们的开发方式。

目前，就我的体验来说，ChatGPT的自定义GPT体验是最好的，但是在开发的过程中，也相当割裂。下面我们就来定制这样一个GPT，看他的效果如何。

自定义GPT

假定你可以访问ChatGPT，并且开通了Plus。

自定义一个GPT和开发一个项目差不多，需要反复调试，第一版完成之后，还需迭代。但是，相对于开发项目，自定义一个GPT的调试过程要相对简单，我这里直接给出一个调试好的，你可以直接把这个指令粘贴到你的ChatGPT里。

你是一位资深的前端开发工程师，你的目标是根据用户要求创建一个不省略任何逻辑的，功能完备的组件。你需要跟用户沟通需求，满足条件之后进行组件开发。

你严格遵循如下规则完成组件开发：

- 使用最新的Typescript和Vue3进行开发。

- 使用Ant Design of Vue UI库。

- 代码结构必须是这样的：<template></template><script setup lang="ts"></script><style scoped></style>。

- 使用 Ant Design Vue 的栅格系统：利用 Ant Design Vue 的 <a-row> 和 <a-col> 组件创建响应式布局。

- 如果需要导航路由，必须这样：import { useRouter } from 'vue-router';  const router = useRouter(); router.push('xxx');

- 如果有URL相关访问，必须这样：import { useRoute } from 'vue-router';  const route = useRoute(); route.xxx

- 如果有提示、通知等，必须这样：import { notification, message, xxx } from 'ant-design-vue';

- 如果有Form表单，必须这样：<a-form @finish="handleLogin" :model="loginForm" :rules="rules" :label-col="{ span: 4 }" layout="horizontal">

- 如果组件有文字必须使用中文。

- 代码里避免使用any，复杂字段必须定义类型，可以参考api.json文档。

- 如果有数据提交按钮，按钮必须包含loading，防止多次触发。

- 如果有危险操作，进行二次确认。

- 如果有数据访问，做好下面处理：

    - import axios from '@/axios-config';

    - 根据api.json文档定义请求数据及响应的数据类型。

    - 使用api.json提供的接口路径。

    - 根据响应状态进行成功或者失败提示。

- 所有接口返回的数据类型都被如下范型包括:

[这里需要填写自己的]

- 输出代码之前：

    - 必须先参考示例代码文件LoginView.vue【重要】

    - 先把思路写出来，观察思路是否符合规则，之后再输出代码。

- 示例代码文件LoginView.vue内容如下：

[这里需要填写自己的]

你需要把 API 文档上传进去。

另外，可以根据开发过程遇到的问题，不断的调试这个指令，非常简单。

使用自定义GPT

上面，我们自定义了一个GPT，怎么使用呢？比如你可以输入这样的要求：

根据API文档及示例代码开发一个用户注册组件，要求如下： 

1、根据API定义三个字段，邮箱、邮箱验证码、密码 

2、邮箱后面需要有验证码发送按钮，参考下面代码 

<a-input-search v-model:value="value" placeholder="input search text" size="large" @search="onSearch" >

  <template #enterButton>

    <a-button>Custom</a-button>

  </template>

</a-input-search>

3、发送按钮要有一分钟倒计时功能

4、注册按钮下面要有一个跳转逻辑：已有账户登录？

它就会非常贴心的生成如下代码：

<template>

  <a-row type="flex" justify="center">

    <a-col :xs="24" :sm="16" :md="12">

      <a-form @finish="handleRegister" :model="registerForm" :rules="rules" layout="horizontal">

        <a-form-item label="邮箱" name="email">

          <a-input-search

            v-model:value="registerForm.email"

            placeholder="请输入邮箱"

            size="large"

            @search="sendVerificationCode"

          >

            <template #enterButton>

              <a-button :disabled="countdown > 0">{{ countdown > 0 ? `${countdown}秒` : '发送验证码' }}</a-button>

            </template>

          </a-input-search>

        </a-form-item>

        <a-form-item label="邮箱验证码" name="emailVerification">

          <a-input v-model:value="registerForm.emailVerification" placeholder="请输入验证码" />

        </a-form-item>

        <a-form-item label="密码" name="password">

          <a-input-password v-model:value="registerForm.password" placeholder="请输入密码" />

        </a-form-item>

        <a-form-item>

          <a-button type="primary" block html-type="submit" :loading="loading">注册</a-button>

        </a-form-item>

        <a-form-item>

          已有账户登录？<a @click="navigateToLogin">点击登录</a>

        </a-form-item>

      </a-form>

    </a-col>

  </a-row>

</template>



<script setup lang="ts">

import { ref } from 'vue';

import { useRouter } from 'vue-router';

import { notification } from 'ant-design-vue';

import axios from '@/axios-config';



interface RegisterModel {

  email: string;

  emailVerification: string;

  password: string;

}



const registerForm = ref<RegisterModel>({

  email: '',

  emailVerification: '',

  password: ''

});

const rules = {

  email: [{ required: true, message: '请输入邮箱', trigger: 'blur', type: 'email' }],

  emailVerification: [{ required: true, message: '请输入验证码', trigger: 'blur' }],

  password: [{ required: true, message: '请输入密码', trigger: 'blur' }]

};

const loading = ref(false);

const countdown = ref(0);

const router = useRouter();



const sendVerificationCode = async () => {

  if (countdown.value > 0) return;



  // 发送验证码请求

  try {

    const response = await axios.get('/auth/verify-email', { params: { email: registerForm.value.email } });

    if (response.appCode === 2000) {

      notification.success({ message: response.message });

      countdown.value = 60;

      let interval = setInterval(() => {

        countdown.value--;

        if (countdown.value === 0) clearInterval(interval);

      }, 1000);

    } else {

      notification.error({ message: response.message });

    }

  } catch (error) {

    notification.error({ message: '验证码发送失败' });

  }

};



const handleRegister = async () => {

  try {

    loading.value = true;

    const response = await axios.post('/auth/register', registerForm.value);

    if (response.appCode === 2000) {

      notification.success({

        message: '注册成功',

        description: '您可以现在登录了'

      });

      router.push('/login');

    } else {

      notification.error({

        message: '注册失败',

        description: response.message

      });

    }

  } finally {

    loading.value = false;

  }

};



const navigateToLogin = () => {

  router.push('/login');

};

</script>



<style scoped>

</style>

效果非常好，如果有哪些不满足要求， 可以不断的与之沟通，继续完善代码。当然如果有些小的改动，可以直接在编辑器里修改代码。比如，上面的上面发送验证码的地方是有问题的，没有没有判断邮箱是否可用，这里你就可以自己加个逻辑，或者告诉它 发送邮箱验证码之前，必须校验邮箱

于是，它就会给你想要的逻辑，非常喜人。不过有时候他会给出代码片段，有时候也会给出全部代码，看自己情况要求它。

const isEmailValid = (email: string): boolean => {

  const emailRegex = /^\w+([\.-]?\w+)*@\w+([\.-]?\w+)*(\.\w{2,3})+$/;

  return emailRegex.test(email);

};



const sendVerificationCode = async () => {

  if (!isEmailValid(registerForm.value.email)) {

    notification.error({ message: '请输入有效的邮箱地址' });

    return;

  }



  if (countdown.value > 0) return;



  // 原有的发送验证码逻辑保持不变

  // ...

};

总结

它现在能做到的已经非常棒了，未来会更加可期。

不过，从体验角度来说，我们需要在开发工具和ChatGPT之间来回切换，还是有些麻烦，什么时候，开发工具中，可以支持就太好。

还有一点儿，现在还需要我们自己去发现问题，与它沟通，指出问题，让它修正问题。如果有一个良好的产品，可以使用测试驱动开发，先让它生成测试代码，根据测试代码，生成逻辑代码。如果测试代码跑不通，自动的把错误消息反馈给它，它再修改，再跑测试代码，这体验简直逆天。

期望

希望一个体验非常完美的平台赶快到来：

如果有这样一个平台，那么，开发效率将是巨大的提升。

嗨，如果你像我一样，总是热衷于寻找新的方法让开发工作更轻松，那么你一定不能错过这篇文章！我精心挑选了 10 个 超级酷炫 的工具，可以让你效率倍增。无论是 API 管理、数据库操作还是调试最新项目，这里总有一款适合你。 而且，我还分享了一些你可能从未听过的全新工具。 让我们马上开始吧！

1. Hoppscotch — API 测试变得更简单 🐦

如果你曾经需要测试 API（谁没做过呢？），那么 Hoppscotch 就是你的新伙伴。它就像 Postman，但速度更快且开源。你可以用它测试 REST、GraphQL 甚至 WebSockets。它轻量级、易于使用，不会像一些臃肿的替代方案那样拖慢你的速度。

它为何如此酷炫: 它速度极快，非常适合测试 API，无需额外的功能。如果你追求速度，这就是你的不二之选。

🌍 网站: hoppscotch.io

2. Zed — 专业级代码协作 👩‍💻👨‍💻

让协作变得简单！Zed 是一款超级炫酷的代码编辑器，专为实时协作而设计。 如果你喜欢结对编程，或者仅仅需要与你的编码伙伴远程合作，这款工具会让你感觉就像并肩作战一样。 此外，它还拥有无干扰界面，让你专注于代码。

你为何会爱上它: 想象一下，你和你的团队就像坐在同一个房间里一样进行编码，即使你们相隔千里。 非常适合远程团队！

🌍 网站: zed.dev

3. Mintlify — 自动化文档，省时省力 📚

让我们面对现实：编写文档可不是什么让人兴奋的事情。 这就是 Mintlify 的用武之地。 它使用人工智能自动生成代码库文档，这意味着你可以专注于有趣的事情——编码！ 此外，它会随着代码的更改而更新，因此你无需担心文档过时。

它为何是救星: 无需再手动编写文档！ 该工具可以节省你的时间和精力，同时让你的项目文档井井有条。

🌍 网站: mintlify.com

4. Infisical — 安全保管秘密 🔐

管理敏感的环境变量可能很棘手，尤其是在不同团队之间。 Infisical 使这变得轻而易举，它可以安全地存储和管理秘密，例如 API 密钥和密码。 它开源且以安全性为中心构建，这意味着你的所有秘密都将安全且加密。

它为何如此方便: 安全，安全，安全。 Infisical 负责所有秘密管理，让你专注于构建酷炫的东西。

🌍 网站: infisical.com

5. Caddy — 带有自动 HTTPS 的 Web 服务器 🌐

如果你曾经不得不处理 Web 服务器配置，你就会知道这可能是一场噩梦。 Caddy 是一款现代 Web 服务器，它负责处理设置 HTTPS 自动化等繁琐工作。 它简单、快速且安全——相信我，使用这款工具设置 SSL 证书非常容易。

它为何如此赞: 无需再与服务器配置或安全设置作斗争。 Caddy 仅需点击几下即可为你处理所有事宜。

🌍 网站: caddyserver.com

6. TablePlus — 专业级数据库管理 🗄️

处理数据库？ TablePlus 是一款时尚、超级易于使用的数据库管理工具，支持所有主要数据库，例如 MySQL、PostgreSQL 等。 它拥有简洁的界面，管理数据库查询从未如此简单。 此外，它速度很快，因此你可以快速完成任务，无需等待。

它为何如此酷炫: 支持多种数据库类型，并拥有出色的 UI，TablePlus 让数据库管理变得轻而易举。

🌍 网站: tableplus.com

7. JSON Crack — 以全新视角可视化 JSON 数据 🧩

JSON 很快就会变得混乱不堪。 这就是 JSON Crack 的用武之地。 它允许你将 JSON 数据可视化为交互式图表，使其更易于理解、调试，甚至与团队分享。 告别在嵌套数据中无限滚动。

它为何如此酷炫: 就像 JSON 数据的 X 光透视！ 你只需一瞥就能看到复杂的数据结构。

🌍 网站: jsoncrack.com

8. Signoz — DevOps 的开源监控工具 💻

如果你处理的是后端应用程序或从事 DevOps 工作，那么 Signoz 是必不可少的工具。 它提供应用程序的全面可观察性，包括日志、指标和分布式跟踪——所有这些都在一个地方。 此外，它是开源的，如果你喜欢自行托管，这非常棒。

它为何如此重要: 就像监控和调试应用程序的瑞士军刀。 你可以在问题变得严重之前捕捉到错误和性能问题。

🌍 网站: signoz.io

9. Warp — 更智能的终端 🖥️

终端多年来几乎没有变化，但 Warp 正在改变这一现状。 它是一款现代终端，具有富文本、命令共享和协作功能。 你甚至可以实时查看你的团队在输入什么内容。 此外，它快速直观——非常适合所有终端高级用户。

你为何会爱上它: 如果你常在终端工作，Warp 会让你的生活更轻松。 协作功能也是一个不错的加分项！

🌍 网站: warp.dev

10. Gleek.io — 文本绘图工具 ✏️➡️📊

需要快速绘制图表，但又不想使用拖放工具？ Gleek.io 允许你仅通过输入文本创建图表。 它非常适合那些习惯写作而不是绘画的开发者，并且支持 UML、流程图和实体关系图等。

它为何如此赞: 就像魔法一样。 输入几行文本，然后——你就会得到一张图表。 它超级快，非常适合规划下一个大项目。

🌍 网站: gleek.io

总结

以上就是我推荐的 10 个工具，我相信它们会让你的开发者生活 无比 轻松。 无论你是独自工作还是与团队合作，这些工具旨在节省你的时间、提高你的效率，而且说实话，它们能让你编码更加愉快。 赶快试试吧，告诉我你最喜欢哪些工具！

我们在各大 App 活动页面，经常会看到循环播放的通知栏。比如春节期间，我就在今日头条 App 中看到了如下通知：「春节期间，部分商品受物流影响延迟发货，请耐心等待，祝你新春快乐！」。

那么，这种循环播放的通知栏如何实现呢？本文我会先介绍它的布局、再介绍它的逻辑，并给出完整的代码。最终我实现的效果如下：

拳打 H5，脚踢小程序。我是「小霖家的混江龙」，关注我，带你了解更多实用的 H5、小程序武学。

布局代码

我们先看布局，如下图所示，循环播放的布局不是普通的左中右布局。可以看到，当文字向左移动时，左边的通知 Icon 和右边的留白会把文字挡住一部分。

为了实现这样的效果，我们给容器 box 设置一个相对定位，并把 box 中的 HTML 代码分为三部分：

• 第一部分是 content，它包裹着需要循环播放的文字；


• 第二部分是 left，它是左边的通知 Icon，我们给它设置绝对定位和 left: 0;；


• 第三部分是 right，它是右边的留白，我们给它设置绝对定位和 right: 0;。

<div class="box">

  <div class="content">

    <!-- ... 省略 -->

  </div>

  <div class="left">🔔</div>

  <div class="right"></div>

</div>

.box {

  position: relative;

  overflow: hidden;

  /* ... 省略 */

}

.left {

  position: absolute;

  left: 0;

  /* ... 省略 */

}

.right {

  position: absolute;

  right: 0;

  /* ... 省略 */

}

现在我们来看包裹文字的 content。content 内部包裹了三段一模一样的文字 notice，每段 notice 之间还有一个 space 元素作为间距。

<!-- ... 省略 -->

<div id="content">

  <div class="notice">春节期间，部分商品...</div>

  <div class="space"></div>

  <div class="notice">春节期间，部分商品...</div>

  <div class="space"></div>

  <div class="notice">春节期间，部分商品...</div>

</div>

<!-- ... 省略 -->

为什么要放置三段一模一样的文字呢？这和循环播放的逻辑有关。

逻辑代码

我们并没有实现真正的循环播放，而是欺骗了用户的视觉。如下图所示：

• 播放通知时，content 从 0 开始向左移动。


• 向左移动 2 * noticeWidth + spaceWidth 时，继续向左移动便会露馅。因为第 3 段文字后不会有第 4 段文字。
  
  

  如果我们把 content 向左移动的距离强行从 2 * noticeWidth + spaceWidth 改为 noticeWidth，不难看出，用户在 box 可视区域内看到的情况基本一致的。

  
  

  然后 content 继续向左移动，向左移动的距离大于等于 2 * noticeWidth + spaceWidth 时，就把距离重新设为 noticeWidth。循环往复，就能欺骗用户视觉，让用户认为 content 能无休无止向左移动。

欺骗视觉的代码如下：

• 我们通过修改 translateX，让 content 不断地向左移动，每次向左移动 1.5px；


• 当 translateX >= noticeWidth * 2 + spaceWidth 时，我们又会把 translateX 强制设为 noticeWidth；


• 为了保证移动动画更丝滑，我们并没有采用 setInterval，而是使用 requestAnimationFrame。

const content = document.getElementById("content");

const notice = document.getElementsByClassName("notice");

const space = document.getElementsByClassName("space");

const noticeWidth = notice[0].offsetWidth;

const spaceWidth = space[0].offsetWidth;



let translateX = 0;

function move() {

  translateX += 1.5;

  if (translateX >= noticeWidth * 2 + spaceWidth) {

    translateX = noticeWidth;

  }

  content.style.transform = `translateX(${-translateX}px)`;

  requestAnimationFrame(move);

}



move();

完整代码

完整代码如下，你可以在 codepen 或者码上掘金上查看。

• codepen: codepen.io/lijunlin202…


• 码上掘金：
  

总结

本文我介绍了如何用 H5 实现循环播放的通知栏：

• 布局方面，我们需要用绝对定位的通知 Icon、留白挡住循环文字的左侧和右侧；此外，循环播放的文字我们额外复制 2 份。


• 逻辑方面，通知栏向左移动 2 * noticeWidth + spaceWidth 后，我们需要强制把通知栏向左移动的距离从 2 * noticeWidth + spaceWidth 变为 noticeWidth，以此来欺骗用户视觉。

拳打 H5，脚踢小程序。我是「小霖家的混江龙」，关注我，带你了解更多实用的 H5、小程序武学。

Medium 原文

最近朋友问了我一个问题：“JavaScript 中的 return 是什么意思？”

function contains(px, py, x, y) {

  const d = dist(px, py, x, y);

  if (d > 20) return true; // 这行是什么意思？

  else return false; // 那这一行呢？

}

一开始我觉得这个问题很简单，但它背后其实蕴藏了一些重要且有趣的概念！

因为我朋友是艺术背景，所以本篇文章的结论是一些很基础的东西，大家感兴趣可以继续看下去。

两种函数

我先解释了有 return 和没有 return 的函数的区别。函数是一组指令，如果你需要这组指令的执行结果，就需要一个 return 语句，否则不需要。

例如，要获得两个数的和，你应该声明一个带有 return 语句的 add 函数：

function add(x, y) {

  return x + y; // 带有 return 语句

}

然后你可以这样使用 add 函数：

const a = 1;

const b = 2;

const c = add(a, b); // 3

const d = add(b, c); // 5

如果你只是想在控制台打印一条消息，则不需要在函数中使用 return 语句：

function great(name) {

  console.log(`Hello ${name}!`);

}

你可以这样使用 great 函数：

great('Rachel');

我原以为我已经解答了朋友的问题，但她又提出了一个新问题：“为什么我们需要这个求和函数？我们可以在任何地方写 a + b，那为什么还要用 return 语句？”

const a = 1;

const b = 2;

const c = a + b; // 3

const d = b + c; // 5

此时，我意识到她的真正问题是：“我们为什么需要函数？”

为什么需要函数？

为什么要使用函数？尽管有经验的程序员有无数的理由，这里我只关注一些与我朋友问题相关的原因

可重用的代码

她的确有道理。我们可以轻松地在任何地方写 a + b。然而，这仅仅因为加法是一个简单的操作。如果你想执行一个更复杂的计算呢？

const a = 1;

const b = 2;



// 这是否易于在每个地方写？

const c = 0.6 + 0.2 * Math.cos(a * 6.0 + Math.cos(d * 8.0 + b));

如果你需要多个语句来获得结果呢？

const a = 1;

const b = 2;



// t 是一个临时变量

const t = 0.6 + 0.2 * Math.cos(a * 6.0 + Math.cos(d * 8.0 + b));

const c = t ** 2;

在这两种情况下，重复编写这些代码会很麻烦。对于这种可重用的代码，你可以将其封装在一个函数中，这样每次需要它时就不必重新实现了！

function theta(a, b) {

  return 0.6 + 0.2 * Math.cos(a * 6.0 + Math.cos(d * 8.0 + b));

}



const a = 1;

const b = 2;

const c = theta(a, b);

const d = theta(b, c);

易于维护

在讨论可重用性时，你无法忽视可维护性。唯一不变的是世界总是在变化，这对于代码也一样！你的代码越容易修改，它就越具可维护性。

如果你想在计算结果时将 0.6 改为 0.8，没有函数的情况下，你必须在每个执行计算的地方进行更改。但如果有一个函数，你只需更改一个地方：函数内部！

function theta(a, b) {

  // 将 0.6 更改为 0.8，你就完成了！

  return 0.8 + 0.2 * Math.cos(a * 6.0 + Math.cos(d * 8.0 + b));

}

毫无疑问，函数增强了代码的可维护性。就在我以为我解答了她的问题时，她又提出了另一个问题：“我理解了函数的必要性，但为什么我们需要写 return？”

为什么需要 return？

真有意思！我之前没有考虑过这个问题！她随后提出了一些关于 return 的替代方案，这些想法非常有创意！

为什么不直接返回最后一条语句？

第一个建议的方案是“为什么不直接返回最后一条语句？”

function add(a, b) {

  a + b

}



const sum = add(1, 2); // undefined

我们知道，在 JavaScript、Java、C 或许多其他语言中，这样是不允许的。这些语言的规范要求显式的 return 语句。然而，在某些语言中，例如 Rust，这是允许的：

fn add(a: i32, b: i32) -> i32 {

    a + b

}



let sum = add(1, 2); // 3

然而值得注意的是，JavaScript 中的另一种函数类型不需要 return 语句！那就是带有单个表达式的箭头函数：

const add = (x, y) => x + y;

const sum = add(1, 2); // 3

如果我们将结果赋值给局部变量呢？

然后她提出了另一个有创意的解决方案：“如果我们将结果赋值给一个局部变量呢？”

function add(x, y) {

  let sum = x + y;

}



add(1, 2);

sum; // Uncaught ReferenceError: sum is not defined

她很快注意到我们无法访问 sum 变量。这是因为使用 let 关键字声明的变量只在其定义的作用域内可见——在这个例子中是函数作用域。

可以将函数视为黑盒子。你将参数放入盒子中，期待获得一个输出（返回值）。只有返回值对外部世界（父作用域）是可见的（或可访问的）。

将结果赋值给全局变量呢？

如果我们在函数作用域之外访问这个值呢？将其赋值给一个全局变量怎么样？

let sum;



function add(x, y) {

  sum = x + y;

}



add(1, 2);

sum; // 3

啊，修改全局变量！副作用！非纯函数！这些想法在我脑海中浮现。但我如何在一分钟内解释为什么这是一个糟糕的选择呢？

避免这种方法的一个关键原因是，别人很难知道具体的全局变量是在哪个函数中被修改的。他们需要去查找结果在哪儿，而不是直接从函数中获取！

总结

简而言之，我们需要 return，因为我们需要函数，而在 JavaScript 中的标准函数中没有可行的替代方案。

函数的存在是为了使代码具有可重用性和可维护性。由于 JavaScript 的规范、函数作用域的限制以及修改全局变量带来的风险，我们在 JavaScript 的标准函数中必须使用 return 语句。

这次讨论非常有趣！我从未想过看似简单的问题背后竟然蕴含着如此多的有趣的思考。与不同视角的人交流总能带来新的见解！

我在编写一个撰写日常的网站，需要用到自定义字体，在网上找到一ttf的字体，发现体积很大，需要进行压缩

如何压缩

目前我们的字体是.ttf字体，其实我们需要把字体转换成.woff字体

WOFF本质上是包含了基于SFNT的字体（如TrueType、OpenType或其他开放字体格式），且这些字体均经过WOFF的编码工具压缩，以便嵌入网页中。[3]WOFF 1.0使用zlib压缩，[3]文件大小一般比TTF小40%。[11]而WOFF 2.0使用Brotli压缩，文件大小比上一版小30%

CloudConvert在线字体转换

可以看下实际效果

20M 转换为 9M 大小，效果还是很明显

transfonter

这个网站transfonter.org/只接受转换15M以下的字体

工具压缩

先下载这个工具字体压缩工具下载，这个工具是从Google的代码编译而来，是用Cygwin编译的，Windows下可以使用

解压出来后大概包含以下几个文件

下载后打开，其中包括woff2_compress.exe和woff2_decompress.exe，使用方法很简单使用命令行：

woff2_compress myfont.ttf

woff2_decompress myfont.woff2

实测效果还不错

前言

无论是开发性能优化还是生产性能优化如果你想找资料那真是一抓一大把，而且方案万变不离其宗并已趋于成熟，但是有一个点很多人没有关注到，在铺天盖地的性能优化文章中几乎很少出现它的影子，它就是桶文件（barrel files），今天我们就来聊一聊。

虽然大家都没怎么提及过，但是你肯定都或多或少地在项目中使用过，而且还对你的项目产生不小的影响！

那么什么是桶文件？

桶文件 barrel files

桶文件是一种将多个模块的导出汇总到一个模块中的方式。具体来说，桶文件本身是一个模块文件，它重新导出其他模块的选定导出。

原始文件结构

// demo/foo.ts

export class Foo {}



// demo/bar.ts 

export class Bar {}



// demo/baz.ts

export class Baz {}

不使用桶文件时的导入方式:

import { Foo } from '../demo/foo';

import { Bar } from '../demo/bar';

import { Baz } from '../demo/baz';

使用桶文件导出(通常是 index.ts)后:

// demo/index.ts

export * from './foo';

export * from './bar';

export * from './baz';

使用桶文件时的导入方式:

import { Foo, Bar, Baz } from '../demo';

是不是很熟悉，应该有很多人经常这么写吧，尤其是封装工具时 utils/index。

还有这种形式的桶文件：

// components/index.ts

export { default as Button } from './Button';

export { default as Input } from './Input';

export { default as Select } from './Select';

export {foo} from './foo';

export {bar} from './bar';

export {baz} from './baz';

这都是大家平常很常用到的形式，那么用桶文件到底怎么了？

桶文件的优缺点

先来说结论：

优点：

• 集中管理，简化代码
• 统一命名，利于多人合作

缺点：

1. 增加编译、打包时间
2. 增加包体积
3. 不必要的性能和内存消耗
4. 降低代码可读性

嗯，有没有激起你的好奇心？我们一个一个来解释。

增加编译、打包时间

桶文件对打包工具的影响

我们都知道 tree-shaking ，他可以在打包时分析出哪些模块和代码没有用到，从而在打包时将这些没有用到的部分移除，从而减少包体积。

以 rollup 为例，tree-shaking 的实现原理（其他大同小异）是：

1.静态分析

• Tree-shaking 基于 ES Module 的静态模块结构进行分析
• 通过分析 import/export 语句，构建模块依赖图
• 标记哪些代码被使用，哪些未被使用
• 使用 /#PURE/ 和 /@NO_SIDE_EFFECTS/ 注释来标记未使用代码

2. 死代码消除

• 移除未使用的导出
• 移除未使用的纯函数
• 保留有副作用的代码

tree-shaking 实现流程

1. 模块分析阶段

// 源代码

import { a, b } from './module'

console.log(a) 



// 分析:b 未被使用

2. 构建追踪

// 构建依赖图

module -> a -> used

module -> b -> unused 

3. 代码生成

// 最终只保留使用的代码

import { a } from './module'

console.log(a)

更多细节可以看我的另一篇文章关于tree-shaking，这不是这篇文章的重点 。

接着说回来，为什么桶文件会增加编译、打包时间？

如果你使用支持 tree-shaking 的打包工具，那么在打包时打包工具需要分析每个模块是否被使用，而桶文件作为入口整合了模块并重新导出，所以会增加分析的复杂度，你重导出的模块越多，它分析的时间就越长。

那有聪明的小伙伴就会问，既然 tree-shaking 分析、标记、删除无用代码会降低打包效率，那我关闭 tree-shaking 功能怎么样？

我只能说，不怎么样，有些情况你关闭 tree-shaking 后，打包时间反而更长。为啥？

关闭 Tree Shaking 意味着 Rollup 会直接将所有模块完整打包，即使某些模块中的代码未被使用。结果是：

• 打包体积增大：更多的代码需要进行语法转换、压缩等步骤。
• I/O 操作增加：较大的输出文件需要更多时间写入磁盘。
• 模块合并工作量增加：Rollup 在关闭 Tree Shaking 时仍会尝试将模块合并到一个文件中（尤其是 output.format 为 iife 或 esm 时）。

所以，虽然 Tree Shaking 的静态分析阶段可能较慢，但其最终生成的 bundle 通常更小、更优化，反而会减少后续步骤（如 压缩 和 代码生成）的负担。

又跑题了，我其实想说的是，问题不在于是否开启 tree-shaking，而在于你使用了桶文件，导致打包工具苦不堪言。

这个很好理解，你就想下面的桶文件重导出了100个模块，相当于这个文件里包含了100个模块的代码，解析器肯定一视同仁每一行代码都得照顾到，但其实你就用了其中一个方法 import { Foo } from '../demo';，想想都累...

// demo/index.ts

export * from './foo';

export * from './bar';

export * from './baz';

...

下面这两种形式，比上面的稍微强点

// components/index.ts

export { default as Button } from './Button';

export { default as Input } from './Input';

export { default as Select } from './Select';

假设 ./Button 文件导出多个具名导出和一个默认导出，那么这段代码意味着只使用其中的默认导出，而 export * 则是照单全收。

export {foo} from './foo';

export {bar} from './bar';

export {baz} from './baz';

同理，假设 ./foo 中有100个具名导出，这行代码就只使用了其中的 foo。

即使这比export * 强，但是当重导出的模块较多较复杂时对打包工具依然负担不小。

好难啊。。。，那到底要怎么样打包工具才舒服？

最佳建议

1. 包或者模块支持通过具体路径引入即所谓的“按需导入” 如：

import Button from 'antd/es/button';

import Divider from 'antd/es/divider';

不知道有没有人用过 babel-plugin-import，它的工作原理大概就是

import { Button, Divider } from 'antd';

帮你转换为

import Button from 'antd/es/button';

import Divider from 'antd/es/divider';

1. 减少或避免使用桶文件，将模块按功能细粒度分组，且要控制单个文件的导出数量

例如：

import {formatTime} from 'utils/timeUtils';

import {formatNumber} from 'utils/numberUtils';

import {formatMoney} from 'utils/moneyUtils';

...

而不是使用桶文件统一导出

import { formatTime, formatNumber, formatMoney } from 'utils/index';

其实这和生产环境的代码拆分一个意思，你把一个项目的所有代码都放在一个文件里搞个几M，浏览器下载和解析肯定是慢的

另外，不止打包阶段，本地开发也是一样的，无论是 vite 还是 webpack ，桶文件都会影响解析编译速度，你的桶文件搞得很多很复杂页面初始加载时间就会很长。

这一点 vite 的官方文档中也有说明。

增加包体积

有的小伙伴可能想，桶文件只影响开发和打包时的体验？那没事，我不差那点时间。

肯定没那么简单，桶文件也会影响打包后产物的体积，这就切实影响到用户侧的体验了。

如果你在打包时没有刻意关注 treeshaking 的效果，或者压根就没开启，那么你无形之中就打包了很多无用代码进最终产物里去了，这就是桶文件带来的坑。

如果你有计划的想要优化打包体积，那么桶文件会额外给你带来很多心智负担，你要一边看着打包产物一边调试打包工具的各种配置，以确保打包结果符合你的预期。

// components/utils/index.ts (桶文件)

export * from './chart';  // 依赖 echarts

export * from './format'; // 纯工具函数

export * from './i18n';   // 依赖 i18next

export * from './storage'; // 浏览器 API



// 使用桶文件

import { formatDate } from 'components/utils';

// 可能导致加载所有依赖

上面的代码，即使开启了 tree-shaking ，打包工具也无能为力。

好在较新版本的 Rollup 已针对export * from 进行了优化，只要最终代码路径中没有实际使用的导出项，它仍会尝试移除这些未使用的代码。但在以下场景下仍可能有问题：

• 模块间有副作用：如果重新导出的模块执行了副作用代码（如修改全局变量），Rollup 会保留这些模块。
• 与 CommonJS 混用：如果被导入模块是 CommonJS 格式，Tree Shaking 可能会受到限制。

想了解完整的影响 treeshaking 的场景点这里传送 Rollup 的 Tree Shaking

不仅 vite，rollup官网也说明了使用桶文件导入的弊端。

总之就是，使用桶文件如果不开 treeshaking，那么打包产物体积大，开了treeshaking也没办法做到完美（目前），你还得多花很多心思去分析优化，就没必要嘛。

不必要的性能和内存消耗

// demo/index.ts

export * from './foo';

export * from './bar';

export * from './baz';

...

这点就很好理解了，即使你只 import {foo} from 'demo/index'使用了一个模块，其他模块也是被初始化了的，这些初始化是没有任何意义的，但是却可能拖累你的初始加载速度、增加内存占用。

同理，他也会影响你的IDE的性能，例如代码检查、补全等，或者测试框架 jest 等。

降低代码可读性

这一点见仁见智，我个人觉得桶文件增加了追踪实现的复杂性，当然大部分情况我们使用IDE是可以直接跳转到对应文件或者搜索的，不然用桶文件真的很抓狂。

// 使用桶文件

import { something } from '@/utils';

// 难以知道 something 的具体来源



// 直接导入更清晰

import { something } from '@/utils/atool';

总结

看到这里快去你的项目里检查一下，你可能做一个很小的改动就能让旁边小伙伴刮目相看：你做了what？这个项目怎么突然快了这么多？

桶文件实际上产生的影响并不小，只有少量桶文件在您的代码中通常是没问题的，但当每个文件夹都有一个时，问题就大了。

如果的项目是一个广泛使用桶文件的项目，现在可以应用一项免费的优化，使许多任务的速度提高 60-80%，让你的IDE和构建工具减减负：

删除所有桶文件！

作者：CoderLiu
来源：juejin.cn/post/7435492245912551436

🍄 大家好，我是风筝

🌍 个人博客：【古时的风筝】。

本文目的为个人学习记录及知识分享。如果有什么不正确、不严谨的地方请及时指正，不胜感激。

每一个赞都是我前进的动力。

公众号：「古时的风筝」

上个月发“微博”的时候说IDE字体已经从 16号调到18号了，主要是一到换季的时候就有点鼻炎，导致眼睛也不舒服，看电脑时间长了就很累，结果我就给字体调大了。

你别说，该认怂就得认怂，调大了不丢人，字体一大果然就没那么累了。刚毕业的时候用12号字，后来改14号，再后来16号，这不，转眼18号字了，如果过两年还写代码的话，就奔着20号去了。

但是问题还是有的，我一般情况下是不怎么用外接显示器的，16寸写代码感觉够用了，除非要做一些大块儿内容的比对，否则，我的外接显示器就是一张风景图，搁旁边就剩下赏心悦目的作用了。

但是这18号字体一上，如果开着控制台的话，一屏也就能显示20行代码了。我之所以用 MacBook Pro，很大的一个原因就是显示屏，但是公司的外接显示器应该是 2K 显示器里最便宜的了，显示效果跟苹果比差了一大截。

看到我发的“微博”后，几个朋友就在群里聊起显示器来，最后一致认为苹果 Studio Display 是最好的显示器，唯一的缺点就是太贵了，最低的27寸 11499起，这你受的了吗？

一个醉心研究显示器和机械键盘的朋友让我看看明基（BenQ）RD280U，说是专业的编程显示器，而且护眼这一块儿做的特别到位，他说，你不是最关心这个吗，肯定对路。他说入手不想要的话可以转给他，他正好想把之前的华为显示器换了呢。

我查了一晚上资料后，这款显示器有两点最吸引我的地方：

然后它就来了，28寸4K，好大一个箱子。快递小哥说这箱子还挺沉，我说是啊，一个显示器怎么这么大这么沉，快递小哥也有点儿惊讶。

拆开后，一个大箱子里面套了一个小箱子，但是是真的沉，好不夸张的说得有20多斤，料真足啊。

但是安装很方便，直接把底座扣上就好了。

这是显示器的上桌效果，28寸，实话说已经很大了，再大的话，全屏写代码就有点儿费脖子了。

一般的显示器都是27寸 16:9 比例的，但是 RD280U 是3:2的，这样显示器更高一点，能多显示几行代码。

目前市面上特殊屏幕比的显示器商家很少，有成本、市场等很多原因，但也有很多程序员喜欢用方一点的屏幕，RD这款考虑到了，还挺贴心。对于我来说，这倒是小事，反正屏幕够大，也不差那几行代码。我最关心的还是显示效果，代码显示的清不清楚。

用惯了苹果的屏幕，其他的显示器一眼就能看出来清晰不清晰，结果，果然没让我失望。文字显示非常清晰，效果非常好。

专门的编码主题

这个显示器内置了几种模式，其中就包括专门的编码主题，一个是深色主题、一个是亮色主题，写代码的时候就直接调成这俩模式就行了。看电影、读书也有专门的主题。

同时还有个专门的背光灯，晚上写代码就直接开背光灯就可以了，不用再单独开个台灯了，也不用开着室内灯了，有时候思路真的不能被打断，晚上背光灯亮起来就不用着急去开灯了，而且氛围感也不错。

另外，在晚上开启猫头鹰模式，也就是夜间保护模式，可以自动调节亮度，在搭配上深色模式，晚上写代码也很舒服。

反光处理

它对定点光源的反光效果处理的也很好，左边是 MacBook Pro，右边是 RD280U，效果还是很明显的。

但是建议写代码、看视频还是不要在强光下，总是对眼睛不好的。

用软件助手直接控制

与显示器配套的还有一个软件控制工具，叫做 「Display Pilot 2」，通过这个软件可以直接更改色彩主题、亮度。

还可以开启 MoonHalo ，MoonHalo 就是背光灯，还有夜间保护、智慧蓝光，还附赠个桌面分区的功能。

软件助手里还有一个 Flow 功能，可以自定义固定时间段里我想要的显示器色彩模式、护眼功能开启状态和其他参数。比如我晚上八点想看会电子书提前设置好Flow， 到点就直接切换了，非常丝滑。

还有一个用处

我家小朋友最近正在学习认表，我就给做了一个认表的网页，没事儿可以拿着大屏练习几分钟。

地址： http://www.moonkite.cn/clock-study…

点击暂停，表盘就会停止，这时候就可以让他看看是几点了，然后点击显示按钮就会出现刚才暂停的时刻。

有小孩子的可以拿来用一用。

然后顺道改了改，做了一个在线时钟，不用大屏的时候可以看时间用。

地址： moonkite.cn/clock.html

大家好，我是农村程序员，独立开发者，前端之虎陈随易。

前面分享了开源编辑器 wangEditor 维护九年终停更，隐藏大佬接大旗的故事。

本文呢，分享开源项目进行商业化盈利的故事。

这个项目叫做 anime，是一个 JavaScript 动画库，目前有 50k star。

我们先来看看它的效果。

怎么样？是不是大呼过瘾。

而这，只是 anime 的冰山一角，更多案例，可以访问下方官网查看。

官网：https://animejs.com

github：https://github.com/juliangarnier/anime

anime 的第一次提交时间是 2016年6月27日，到如今 8年 来，一共提交了 752次，平均每年提交 100次，核心代码 1300行 左右。

从数据上来看，并不亮眼，但是从功能上来说，确是极其优秀。

目前，anime v4 版本已经可以使用了。

v4 版本的功能特点如下：

• 新的 ES 模块优先 API。


• 主要性能提升和减少内存占用。


• 内置类型定义！


• 用于检查和加速动画工作流程的 GUI 界面。


• 带有标签的改进时间轴、更多时间位置语法选项、对子项的循环/方向支持等等！。


• 用于创建附加动画的新附加合成模式。


• 新的可配置内置功能：‘linear(x，x，x)’、‘in(x)’、‘out(x)’、‘inOut(x)’、‘outIn(x)’。


• 更好的 SVG 工具，包括改进的形状变形、线条绘制和运动路径实用程序。


• 支持 CSS 变量动画。


• 能够从特定值进行动画处理。


• 可链接的实用程序函数可简化动画工作流程中的常见任务。


• 新的 Timer 实用程序类，可用作 setInterval 和 setTimeout 的替代方案。


• 超过 300 个测试，使开发过程更轻松且无错误。


• 全新的文档，具有新设计和更深入的解释。


• 新的演示和示例。

可以看到，新版进行了大量的优化和升级。

但是呢，目前只提供给赞助的用户使用。

最低档赞助是 10美元/月，目标是 120个 赞助，目前已经积累了 117个 赞助。

也就是说，每个月都会有至少 1170美元 的赞助收入，折合人民币 8400元/月。

不知道作者所在地区的生活水平怎么样，这个赞助收入，对于生存问题，基本能够胜任了。

我们很多时候都在抱怨开源赚不到钱，那么开源盈利的方案也是有很多的，比如：

希望我们的开源环境更加友好，让更多人可以解决他们的问题，也要让开源作者获得应有的回报。

简介

Fusion 是新一代的混合栈管理框架，用于 Flutter 与 Native 页面统一管理，并支持页面通信、页面生命周期监听等功能。Fusion 即 融合，我们的设计初衷就是帮助开发者在使用 Flutter 与 Native 进行混合开发时尽量感受不到两者的隔阂，提升开发体验。此外，Fusion 彻底解决了混合开发过程中普遍存在的黑屏、白屏、闪屏等问题，更加适合重视用户体验的App使用。

从 4.0 开始，Fusion 已完成纯鸿蒙平台（HarmonyOS Next/OpenHarmony，以下简称 HarmonyOS）的适配，开发者可以在Android、iOS、HarmonyOS上得到完全一致的体验。（HarmonyOS 的 Flutter SDK 可以在这里获取）

Fusion 采用引擎复用方案，在 Flutter 与 Native 页面多次跳转情况下，APP 始终仅有一份 FlutterEngine 实例，因此拥有更好的性能和更低的内存占用。

Fusion 也是目前仅有的支持混合开发时应用在后台被系统回收后，所有Flutter页面均可正常恢复的混合栈框架。

开始使用

0、准备

在开始前需要按照 Flutter 官方文档，将 Flutter Module 项目接入到 Android、iOS、HarmonyOS 工程中。

1、初始化

Flutter 侧

使用 FusionApp 替换之前使用的 App Widget，并传入所需路由表，默认路由表和自定义路由表可单独设置也可同时设置。

void main() {

  runApp(FusionApp(

    // 默认路由表

    routeMap: routeMap,

    // 自定义路由表

    customRouteMap: customRouteMap,

  ));

}



// 默认路由表，使用默认的 PageRoute

// 使用统一的路由动画

final Map<String, FusionPageFactory> routeMap = {

  '/test': (arguments) => TestPage(arguments: arguments),

  kUnknownRoute: (arguments) => UnknownPage(arguments: arguments),

};



// 自定义路由表，可自定义 PageRoute

// 比如：某些页面需要特定的路由动画则可使用该路由表

final Map<String, FusionPageCustomFactory> customRouteMap = {

  '/mine': (settings) => PageRouteBuilder(

      opaque: false,

      settings: settings,

      pageBuilder: (_, __, ___) => MinePage(

          arguments: settings.arguments as Map<String, dynamic>?)),

};

P.S: kUnknownRoute表示未定义路由

注意：如果项目使用了 flutter_screenutil，需要在 runApp 前调用 Fusion.instance.install()，没有使用 flutter_screenutil则无须该步骤。

void main() {

  Fusion.instance.install();

  runApp(FusionApp(

    // 默认路由表

    routeMap: routeMap,

    // 自定义路由表

    customRouteMap: customRouteMap,

  ));

}

Android 侧

在 Application 中进行初始化，并实现 FusionRouteDelegate 接口

class MyApplication : Application(), FusionRouteDelegate {



    override fun onCreate() {

        super.onCreate()

        Fusion.install(this, this)

    }



    override fun pushNativeRoute(name: String?, arguments: Map<String, Any>?) {

        // 根据路由 name 跳转对应 Native 页面

    }



    override fun pushFlutterRoute(name: String?, arguments: Map<String, Any>?) {

        // 根据路由 name 跳转对应 Flutter 页面

        // 可在 arguments 中存放参数判断是否需要打开透明页面

    }

}

iOS 侧

在 AppDelegate 中进行初始化，并实现 FusionRouteDelegate 代理

@UIApplicationMain

@objc class AppDelegate: UIResponder, UIApplicationDelegate, FusionRouteDelegate {

    

    func application(

    _ application: UIApplication,

    didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?

  ) -> Bool {

      ...

      Fusion.instance.install(self)

      ...

    return true

  }

    

    func pushNativeRoute(name: String?, arguments: Dictionary<String, Any>?) {

        // 根据路由 name 跳转对应 Native 页面

    }

    

    func pushFlutterRoute(name: String?, arguments: Dictionary<String, Any>?) {

        // 根据路由 name 跳转对应 Flutter 页面

        // 可在 arguments 中存放参数判断是否需要打开透明页面

        // 可在 arguments 中存放参数判断是 push 还是 present

    }

}

HarmonyOS 侧

在 UIAbility 中进行初始化，并实现 FusionRouteDelegate 代理

export default class EntryAbility extends UIAbility implements FusionRouteDelegate {

  private static TAG = 'EntryAbility'

  private mainWindow: window.Window | null = null

  private windowStage: window.WindowStage | null = null



  override async onCreate(want: Want, launchParam: AbilityConstant.LaunchParam): Promise<void> {

    await Fusion.instance.install(this.context, this)

    GeneratedPluginRegistrant.registerWith(Fusion.instance.defaultEngine!)

  }



  pushNativeRoute(name: string, args: Map<string, Object> | null): void {

    // 根据路由 name 跳转对应 Native 页面

  }



  pushFlutterRoute(name: string, args: Map<string, Object> | null): void {

    // 根据路由 name 跳转对应 Flutter 页面

    // 可在 arguments 中存放参数判断是否需要打开透明页面

  }

}

2、Flutter 容器

普通页面模式

Android 侧

通过 FusionActivity（或其子类） 创建 Flutter 容器，启动容器时需要使用 Fusion 提供的 buildFusionIntent 方法，其中参数 transparent 需设为 false。其 xml 配置参考如下（如果使用 FusionActivity 则不用配置）：

        <activity

            android:name=".CustomFusionActivity"

            android:configChanges="orientation|keyboardHidden|keyboard|screenSize|smallestScreenSize|locale|layoutDirection|fontScale|screenLayout|density|uiMode"

            android:exported="false"

            android:hardwareAccelerated="true"

            android:launchMode="standard"

            android:theme="@style/FusionNormalTheme"

            android:windowSoftInputMode="adjustResize" />

iOS 侧

通过 FusionViewController （或其子类）创建 Flutter 容器，push 和 present 均支持。FusionViewController 默认隐藏了 UINavigationController。

在 iOS 中需要处理原生右滑退出手势和 Flutter 手势冲突的问题，解决方法也很简单：只需在自定义的 Flutter 容器中实现 FusionPopGestureHandler 并在对应方法中启用或者关闭原生手势即可，这样可以实现如果当前 Flutter 容器存在多个 Flutter 页面时，右滑手势是退出 Flutter 页面，而当 Flutter 页面只有一个时则右滑退出 Flutter 容器。

    // 启用原生手势

    func enablePopGesture() {

        // 以下代码仅做演示，不可直接照搬，需根据APP实际情况自行实现

        navigationController?.interactivePopGestureRecognizer?.isEnabled = true

    }



    // 关闭原生手势

    func disablePopGesture() {

        // 以下代码仅做演示，不可直接照搬，需根据APP实际情况自行实现

        navigationController?.interactivePopGestureRecognizer?.isEnabled = false

    }

HarmonyOS 侧

通过 FusionEntry（或其子类） 创建 Flutter 容器，启动容器时需要使用 Fusion 提供的 buildFusionParams 方法，也可直接使用 FusionPage。默认全屏模式。

    const params = buildFusionParams(name, args, false, backgroundColor)

    this.mainLocalStorage?.setOrCreate('params', params)

    router.pushNamedRoute({name: FusionConstant.FUSION_ROUTE_NAME})

透明页面模式

Android 侧

使用方式与普通页面模式相似，只是buildFusionIntent 方法的参数 transparent 需设为 true，其 xml 配置参考如下：

        <activity

            android:name=".TransparentFusionActivity"

            android:configChanges="orientation|keyboardHidden|keyboard|screenSize|smallestScreenSize|locale|layoutDirection|fontScale|screenLayout|density|uiMode"

            android:exported="false"

            android:hardwareAccelerated="true"

            android:launchMode="standard"

            android:theme="@style/FusionTransparentTheme"

            android:windowSoftInputMode="adjustResize" />

iOS 侧

使用方式与普通页面模式相似：

let fusionVc = CustomViewController(routeName: name, routeArguments: arguments, transparent: true)

navController?.present(fusionVc, animated: false)

HarmonyOS 侧

使用方式与普通页面模式相似：

    const params = buildFusionParams(name, args, true, backgroundColor)

    this.windowStage?.createSubWindow(FusionConstant.TRANSPARENT_WINDOW, (_, win) => {

      const record: Record<string, Object> = {

        'params': params

      }

      win.loadContentByName(FusionConstant.FUSION_ROUTE_NAME, new LocalStorage(record))

      win.showWindow()

    })

Flutter 侧

同时Flutter页面背景也需要设置为透明

子页面模式

子页面模式是指一个或多个 Flutter 页面同时嵌入到 Native 容器中的场景，如：使用Tab切换Flutter和原生页面，Fusion 支持多个 Flutter 页面嵌入同一个 Native 容器中

Android 侧

使用 FusionFragment 以支持子页面模式，创建 FusionFragment 对象需要使用 buildFusionFragment 方法

iOS 侧

与页面模式一样使用 FusionViewController

HarmonyOS 侧

与页面模式一样使用 FusionEntry，配合 buildFusionParams方法配置参数

自定义容器背景色

默认情况下容器的背景为白色，这是因为考虑到绝大多数的页面都是使用白色背景，但如果打开的首个Flutter页面的背景是其他颜色，比如夜间模式下页面为深灰色，此时是为了更好的视觉效果，可以自定义容器的背景色与首个Flutter页面的背景色一致。

Android 侧

在 buildFusionIntent 和 buildFusionFragment方法中参数 backgroundColor 设为所需背景色

iOS 侧

在创建 FusionViewController （或其子类）对象时，参数 backgroundColor 设为所需背景色

HarmonyOS 侧

在 buildFusionParams方法中参数 backgroundColor 设为所需背景色

3、路由API（FusionNavigator）

• push：将对应路由入栈，Navigator.pushNamed 与之等同，根据FusionRouteType分为以下几种方式：
  
  
  
  • flutter模式: 在当前Flutter容器中将指定路由对应的Flutter页面入栈，如果没有则跳转kUnknownRoute对应Flutter页面
  
  
  • flutterWithContainer模式: 创建一个新的Flutter容器，并将指定路由对应的Flutter页面入栈，如果没有则跳转kUnknownRoute对应Flutter页面。即执行FusionRouteDelegate的pushFlutterRoute
  
  
  • native模式: 将指定路由对应的Native页面入栈，即执行FusionRouteDelegate的pushNativeRoute
  
  
  • adaption模式: 自适应模式，默认类型。首先判断该路由是否是Flutter路由，如果不是则进入native模式，如果是再判断当前是否是页面是否是Flutter容器，如果是则进入flutter模式，如果不是则进入flutterWithContainer模式
  
  
  
  


• pop：在当前Flutter容器中将栈顶路由出栈，Navigator.pop 与之等同


• maybePop：在当前Flutter容器中将栈顶路由出栈，可被WillPopScope拦截


• replace：在当前Flutter容器中将栈顶路由替换为对应路由，Navigator.pushReplacementNamed 与之等同


• remove：在当前Flutter容器中移除对应路由

路由跳转与关闭等操作既可使用FusionNavigator的 API，也可使用Navigator中与之对应的API（仅上述提到的部分）

4、Flutter Plugin 注册

在 Android 和 iOS 平台上框架内部会自动注册插件，无须手动调用 GeneratedPluginRegistrant.registerWith 进行注册，但 HarmonyOS 必须手动调用该方法。

5、自定义 Channel

如果需要 Native 与 Flutter 进行通信，则需要自行创建 Channel，创建 Channel 方式如下（以 MethodChannel 为例）：

Android 侧

①、与容器无关的方法

在 Application 中进行注册

val channel = Fusion.defaultEngine?.dartExecutor?.binaryMessenger?.let {

    MethodChannel(

        it,

        "custom_channel"

    )

}

channel?.setMethodCallHandler { call, result -> 

}

②、与容器相关的方法

在自实现的 FusionActivity、FusionFragmentActivity、FusionFragment 上实现 FusionMessengerHandler 接口，在 configureFlutterChannel 中创建 Channel，在 releaseFlutterChannel 释放 Channel

class CustomActivity : FusionActivity(), FusionMessengerHandler {

  

    override fun configureFlutterChannel(binaryMessenger: BinaryMessenger) {

        val channel = MethodChannel(binaryMessenger, "custom_channel")

        channel.setMethodCallHandler { call, result -> 

            

        }

    }

  

    override fun releaseFlutterChannel() {

        channel?.setMethodCallHandler(null)

        channel = null

    }

}

iOS 侧

①、与容器无关的方法

在 AppDelegate 中进行注册

var channel: FlutterMethodChannel? = nil

if let binaryMessenger = Fusion.instance.defaultEngine?.binaryMessenger {

    channel = FlutterMethodChannel(name: "custom_channel", binaryMessenger: binaryMessenger)

}

channel?.setMethodCallHandler { (call: FlutterMethodCall, result: @escaping FlutterResult) in

}

②、与容器相关的方法

在自实现的 FusionViewController 上实现 FusionMessengerHandler 协议，在协议方法中创建 Channel

class CustomViewController : FusionViewController, FusionMessengerHandler {

    func configureFlutterChannel(binaryMessenger: FlutterBinaryMessenger) {

        channel = FlutterMethodChannel(name: "custom_channel", binaryMessenger: binaryMessenger)

        channel?.setMethodCallHandler { (call: FlutterMethodCall, result: @escaping FlutterResult) in

            

        }

    }

    

    func releaseFlutterChannel() {

        channel?.setMethodCallHandler(nil)

        channel = nil

    }

}

HarmonyOS 侧

①、与容器无关的方法

在 UIAbility 中进行注册

const binaryMessenger = Fusion.instance.defaultEngine?.dartExecutor.getBinaryMessenger()

const channel = new MethodChannel(binaryMessenger!, 'custom_channel')

channel.setMethodCallHandler({

  onMethodCall(call: MethodCall, result: MethodResult): void {

    

  }

})

②、与容器相关的方法

在自实现的 FusionEntry 上实现 FusionMessengerHandler 接口，在 configureFlutterChannel 中创建 Channel，在 releaseFlutterChannel 释放 Channel

export default class CustomFusionEntry extends FusionEntry implements FusionMessengerHandler, MethodCallHandler {

  private channel: MethodChannel | null = null



  configureFlutterChannel(binaryMessenger: BinaryMessenger): void {

    this.channel = new MethodChannel(binaryMessenger, 'custom_channel')

    this.channel.setMethodCallHandler(this)

  }



  onMethodCall(call: MethodCall, result: MethodResult): void {

    result.success(`Custom Channel：${this}_${call.method}`)

  }



  releaseFlutterChannel(): void {

    this.channel?.setMethodCallHandler(null)

    this.channel = null

  }

}

BasicMessageChannel 和 EventChannel 使用也是类似

P.S.: 与容器相关的方法是与容器生命周期绑定的，如果容器不可见或者销毁了则无法收到Channel消息。

6、生命周期

应用生命周期监听：

• ①、在 Flutter 侧任意处注册监听皆可，并implements FusionAppLifecycleListener


• ②、根据实际情况决定是否需要注销监听

void main() {

  ...

  FusionAppLifecycleBinding.instance.register(MyAppLifecycleListener());

  runApp(const MyApp());

}



class MyAppLifecycleListener implements FusionAppLifecycleListener {

  @override

  void onBackground() {

    print('onBackground');

  }



  @override

  void onForeground() {

    print('onForeground');

  }

}

FusionAppLifecycleListener 生命周期回调函数：

• onForeground: 应用进入前台会被调用（首次启动不会被调用，Android 与 iOS 保持一致）


• onBackground: 应用退到后台会被调用

页面生命周期监听：

• ①、在需要监听生命周期页面的 State 中 implements FusionPageLifecycleListener


• ②、在 didChangeDependencies 中注册监听


• ③、在 dispose 中注销监听

class LifecyclePage extends StatefulWidget {

  const LifecyclePage({Key? key}) : super(key: key);



  @override

  State<LifecyclePage> createState() => _LifecyclePageState();

}



class _LifecyclePageState extends State<LifecyclePage>

    implements FusionPageLifecycleListener {

  @override

  Widget build(BuildContext context) {

    return Container();

  }



  @override

  void didChangeDependencies() {

    super.didChangeDependencies();

    FusionPageLifecycleBinding.instance.register(this);

  }



  @override

  void onPageVisible() {}



  @override

  void onPageInvisible() {}



  @override

  void onForeground() {}



  @override

  void onBackground() {}



  @override

  void dispose() {

    super.dispose();

    FusionPageLifecycleBinding.instance.unregister(this);

  }

}

PageLifecycleListener 生命周期回调函数：

• onForeground: 应用进入前台会被调用，所有注册了生命周期监听的页面都会收到


• onBackground: 应用退到后台会被调用，所有注册了生命周期监听的页面都会收到


• onPageVisible: 该 Flutter 页面可见时被调用，如：从 Native 页面或其他 Flutter 页面 push 到该 Flutter 页面时；从 Native 页面或其他 Flutter 页面 pop 到该 Flutter 页面时；应用进入前台时也会被调用。


• onPageInvisible: 该 Flutter 页面不可见时被调用，如：从该 Flutter 页面 push 到 Native 页面或其他 Flutter 页面时；如从该 Flutter 页面 pop 到 Native 页面或其他 Flutter 页面时；应用退到后台时也会被调用。

7、全局通信

支持消息在应用中的传递，可以指定 Native 还是 Flutter 或者全局接收和发送。

注册消息监听

Flutter侧

• ①、在需要监听消息的类中 implements FusionNotificationListener，并复写 onReceive 方法，该方法可收到发送过来的消息


• ②、在合适时机注册监听


• ③、在合适时机注销监听

class TestPage extends StatefulWidget {



  @override

  State<TestPage> createState() => _TestPageState();

}



class _TestPageState extends State<TestPage> implements FusionNotificationListener {



  @override

  void onReceive(String name, Map<String, dynamic>? body) {

    

  }



  @override

  void didChangeDependencies() {

    super.didChangeDependencies();

    FusionNotificationBinding.instance.register(this);

  }



  @override

  void dispose() {

    super.dispose();

    FusionNotificationBinding.instance.unregister(this);

  }

}

Native侧

• ①、在需要监听消息的类中实现 FusionNotificationListener 接口，并复写 onReceive 方法，该方法可收到发送过来的消息


• ②、在适当时机使用 FusionNotificationBinding 的 register 方法注册监听


• ③、在适当时机使用 FusionNotificationBinding 的 unregister 方法注销监听

发送消息

三端均可使用FusionNavigator 的 sendMessage 方法来发送消息，根据使用FusionNotificationType 不同类型有不同效果：

• flutter: 仅 Flutter 可以收到


• native: 仅 Native 可以收到


• global(默认): Flutter 和 Native 都可以收到

8、返回拦截

在纯 Flutter 开发中可以使用WillPopScope组件拦截返回操作，Fusion 也完整支持该功能，使用方式与在纯 Flutter 开发完全一致，此外使用FusionNavigator.maybePop的操作也可被WillPopScope组件拦截。

9、状态恢复

Fusion 支持 Android 和 iOS 平台 APP 被回收后 Flutter 路由的恢复。

给前端以福利，给编程以复利。大家好，我是大家的林语冰。

00. 观前须知

地球人都知道，JS 中的异步编程是 单线程 的，和其他多线程语言的三观一龙一猪。因此，虽然其他语言的异步模式彼此互通有无，但对 JS 并不友好，比如 Actor 模型等。

这并不是说 JS 被异步社区孤立了，只是因为 JS 天生和多线程八字不合。你知道的，要求 JS 使用多线程，就像要求香菜恐惧症患者吃香菜一样离谱。本质上而言，这是刻在 JS 单线程 DNA 里的先天基因，直接决定了 JS 的“异步性状”。有趣的是，如今 JS 也变异出若干多线程的使用场景，只是比较非主流。

ES6 之后，JS 的异步编程主要基于 Promise 设计，比如人气爆棚的 fetch API 等。因此，最新的 ES2024 功能里，又双叒叕往 Promise 加塞了新型静态方法 Promise.withResolvers()，也就见怪不怪了。

问题在于，我发现这个新方法居然只要 3 行代码就能实现！奥卡姆剃刀原则告诉我们， 若无必要，勿增实体。那么这个鸡肋的新方法是否违背了奥卡姆剃刀原则呢？我决定先质疑、再质疑。

当然，作为应试教育的漏网之鱼，我很擅长批判性思考，不会被第一印象 PUA。经过三天三夜的刻意练习，机智如我发现新方法果然深藏不露。所以，本期我们就一起来深度学习 Promise 新方法的技术细节。

01. 静态工厂方法

Promise.withResolvers() 源自 tc39/proposal-promise-with-resolvers 提案，是 Promise 类新增的一个 静态工厂方法。

静态的意思是，该方法通过 Promise 类调用，而不是通过实例对象调用。工厂的意思是，我们可以使用该方法生成一个 Promise 实例，而无须求助于传统的构造函数 + new 实例化。

可以看到，这类似于 Promise.resolve() 等语法糖。区别在于，传统构造函数实例化的对象状态可能不太直观，而这里的 promise 显然处于待定状态，此外还“买一送二”，额外附赠一对用于改变 promise 状态的“变态函数” —— resolve() 和 reject()。

ES2024 之后，该方法可以作为一道简单的异步笔试题 —— 请你在一杯泡面的时间里，实现一下 Promise.withResolvers()。

如果你是我的粉丝，根本不慌，因为新方法的基本原理并不复杂，参考我下面的实现，简单给面试官表演一下就欧了。

可以看到，这个静态工厂方法的实现难点在于，如何巧妙地将变态函数暴露到外部作用域，其实核心逻辑压缩后有且仅有 3 行代码。

这就引发了本文开头的质疑：新方法是否多此一举？难道负责 JS 标准化的 tc39 委员会也有绩效考核，还是确实存在某些不为人知的极端情况？

02. 技术细节

通过对新方法进行苏格拉底式的“灵魂拷问”和三天三夜的深度学习，我可以很有把握地说，没人比我更懂它。

首先，与传统的构造函数实例化不同，新方法支持无参构造，我们不需要在调用时传递任何参数。

可以看到，构造函数实例化要求传递一个执行器回调，偷懒不传则直接报错，无法顺利实例化。

其次，变态函数的设计更加自由。

可以看到，传统的构造函数中，变态函数能且仅能作为局部变量使用，无法在构造函数外部调用。而新方法同时返回实例及其变态函数，这意味着实例和变态函数处于同一级别的作用域。

那么，这个设计上的小细节有何黑科技呢？

假设我们想要一个 Promise 实例，但尚未知晓异步任务的所有细节，我们期望先将变态函数抽离出来，再根据业务逻辑灵活调用，请问阁下如何应对？

ES2024 之前，我们可以通过 作用域提升 来“曲线救国”，举个栗子：

可以看到，这种方案的优势在于，诉诸作用域提升，我们不必把所有猫猫放在一个薛定谔的容器里，在构造函数中封装一大坨“代码屎山”；其次，变态函数不被限制在构造函数内部，随时随地任你调用。

该方案的缺陷则在于，某些社区规范鼓励“const 优先”的代码风格，即 const 声明优先，再按需修改为 let 声明。

这里的变态函数被迫使用 let 声明，这意味着存在被愣头青意外重写的隐患，但为了缓存赋值，我们一开始就不能使用 const 声明。从防御式编程的角度，这可能不太鲁棒。

因此，Promise.withResolvers() 应运而生，该静态工厂方法允许我们：

• 无参构造


• const 优先


• 自由变态

03. 设计动机

在某些需要封装 Promise 风格的场景中，新方法还能减少回调函数的嵌套，我把这种代码风格上的优化称为“去回调化”。

举个栗子，我们可以把 Node 中回调风格的 API 转换为 Promise 风格，以 fs 模块为例：

可以看到，由于使用了传统的构造函数实例化，在封装 readFile() 的时候，我们被迫将其嵌套在构造函数内部。

现在，我们可以使用新方法来“去回调化”。

可以看到，传统构造函数嵌套的一层回调函数就无了，整体实现更加扁平，减肥成功！

粉丝请注意，很多 Node API 现在也内置了 Promise 版本，现实开发中不需要我们手动封装，开箱即用就欧了。但是这种封装技巧是通用的。

举个栗子，瞄一眼 MDN 电子书搬运过来的一个更复杂的用例，将 Node 可读流转换为异步可迭代对象。

可以看到，井然有序的代码中透露着一丝无法形容的优雅。我脑补了一下如何使用传统构造函数来实现上述功能，现在还没缓过来......

04. 高潮总结

从历史来看，Promise.withResolvers() 并非首创，bluebird 的 Promise.defer() 或 jQuery 的 $.defer() 等库就提供了同款功能，ES2024 只是换了个名字“新瓶装旧酒”，将其标准化为内置功能。

但是，Promise.withResolvers() 的标准化势在必行，比如 Vite 源码中就自己手动封装了同款功能。

无独有偶，Axios、Vue、TS、React 等也都在源码内部“反复造轮子”，像这种回头率超高的代码片段我们称之为 boilerplate code（样板代码）。

重复乃编程之大忌，既然大家都要写，不如大家都别写，让 JS 自己写，牺牲小我，成全大家。编程里的 DRY 原则就是让我们不要重复，因为很多 bug 就是重复导致的，而且不好统一管理和维护，《ES6 标准入门教程》科普的 魔术字符串 就是其中一种反模式。

兼容性方面，我也做过临床测试了，主流浏览器广泛支持。

总之，Promise.withResolvers() 通过将样板代码标准化，达到了消除重复的目的，原生实现除了性能更好，是一个性价比较高的静态工厂方法。

参考文献

粉丝互动

本期话题是：你觉得新方法好评几颗星，为什么？你可以在本文下方自由言论，文明科普。

欢迎持续关注“前端俱乐部”，给前端以福利，给编程以复利。

坚持阅读的小伙伴可以给自己点赞！谢谢大家的点赞，掰掰~

分享一下，最近使用 React 封装的一个 Skus 组件，主要用于处理商品的sku在受到库存的影响下，sku项的选中和禁用问题；

需求分析

需要展示商品各规格下的sku信息，以及根据该sku的库存是否为空，判断是否禁用该sku的选择。

以下讲解将按照我的 Skus组件 来，我这里放上我组件库中的线上 demo 和码上掘金的一个 demo 供大家体验；由于码上掘金导入不了组件库，我就上传了一份开发组件前的一份类似的代码，功能和代码思路是差不多的，大家也可以自己尝试写一下，可能你的思路会更优；

线上 Demo 地址

码上掘金

传入的sku数据结构

需要传入的商品的sku数据类型大致如下：

type SkusProps = { 

  /** 传入的skus数据列表 */

  data: SkusItem[]

  // ... 其他的props

}



type SkusItem = {

  /** 库存 */

  stock?: number;

  /** 该sku下的所有参数 */

  params: SkusItemParam[];

};



type SkusItemParam = {

  name: string;

  value: string;

}

转化成需要的数据类型：

type SkuStateItem = {

  value: string;

  /** 与该sku搭配时，该禁用的sku组合 */

  disabledSkus: string[][];

}[];

生成数据

定义 sku 分类

首先假装请求接口，造一些假数据出来，我这里自定义了最多 6^6 = 46656 种 sku。

下面的是自定义的一些数据:

const skuData: Record<string, string[]> = {

  '颜色': ['红','绿','蓝','黑','白','黄'],

  '大小': ['S','M','L','XL','XXL','MAX'],

  '款式': ['圆领','V领','条纹','渐变','轻薄','休闲'],

  '面料': ['纯棉','涤纶','丝绸','蚕丝','麻','鹅绒'],

  '群体': ['男','女','中性','童装','老年','青少年'],

  '价位': ['<30','<50','<100','<300','<800','<1500'],

}

const skuNames = Object.keys(skuData)

页面初始化

• checkValArr: 需要展示的sku分类是哪些；


• skusList: 接口获取的skus数据；


• noStockSkus: 库存为零对应的skus（方便查看）。

export default () => {

  // 这个是选中项对应的sku类型分别是哪几个。

  const [checkValArr, setCheckValArr] = useState<number[]>([4, 5, 2, 3, 0, 0]);

  // 接口请求到的skus数据

  const [skusList, setSkusList] = useState<SkusItem[]>([]);

  // 库存为零对应的sku数组

  const [noStockSkus, setNoStockSkus] = useState<string[][]>([])



  useEffect(() => {

    const checkValTrueArr = checkValArr.filter(Boolean)

    const _noStockSkus: string[][] = [[]]

    const list = getSkusData(checkValTrueArr, _noStockSkus)

    setSkusList(list)

    setNoStockSkus([..._noStockSkus])

  }, [checkValArr])

  

  // ....



  return <>...</>

}

根据上方的初始化sku数据，生成一一对应的sku，并随机生成对应sku的库存。

getSkusData 函数讲解

先看总数（total）为当前需要的各sku分类的乘积；比如这里就是上面传入的 checkValArr 数组 [4,5,2,3] 共 120种sku选择。对应的就是 skuData 中的 [颜色前四项，大小前五项，款式前两项，面料前三项] 即下图的展示。

遍历 120 次，每次生成一个sku，并随机生成库存数量，40%的概率库存为0；然后遍历 skuNames 然后找到当前对应的sku分类即 [颜色，大小，款式，面料] 4项；

接下来就是较为关键的如何根据 sku的分类顺序 生成对应的 120个相应的sku。

请看下面代码中注释为 LHH-1 的地方，该 value 的获取是通过 indexArr 数组取出来的。可以看到上面 indexArr 数组的初始值为 [0,0,0,0] 4个零的索引，分别对应 4 个sku的分类；