引言

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

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

一、需求说明

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

有如下初始代码:

• 一个自适应的表格
• 每个单元格的宽度固定 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文档

嗨，如果你像我一样，总是热衷于寻找新的方法让开发工作更轻松，那么你一定不能错过这篇文章！我精心挑选了 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

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

前面分享了开源编辑器 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元/月。

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

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

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

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

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的分类；

• 第一次遍历:

indexArr: [0,0,0,0] -> skuName.forEach -> 红，S，圆领，纯棉

看LHH-2标记处: 索引+1 -> indexArr: [0,0,0,1];

• 第二次遍历:

indexArr: [0,0,0,1] -> skuName.forEach -> 红，S，圆领，涤纶

看LHH-2标记处: 索引+1 -> indexArr: [0,0,0,2];

• 第三次遍历:

indexArr: [0,0,0,2] -> skuName.forEach -> 红，S，圆领，丝绸

看LHH-2标记处: 由于已经到达该分类下的最后一个，所以前一个索引加一，后一个重新置为0 -> indexArr: [0,0,1,0];

• 第四次遍历:

indexArr: [0,0,1,0] -> skuName.forEach -> 红，S，V领，纯棉

看LHH-2标记处: 索引+1 -> indexArr: [0,0,1,1];

• 接下来的一百多次遍历跟上面的遍历同理

function getSkusData(skuCategorys: number[], noStockSkus?: string[][]) {

  // 最终生成的skus数据；

  const skusList: SkusItem[] = []

  // 对应 skuState 中各 sku ，主要用于下面遍历时，对 product 中 skus 的索引操作

  const indexArr = Array.from({length: skuCategorys.length}, () => 0);

  // 需要遍历的总次数

  const total = skuCategorys.reduce((pre, cur) => pre * (cur || 1), 1)

  for(let i = 1; i <= total; i++) {

    const sku: SkusItem = {

      // 库存：60%的几率为0-50，40%几率为0

      stock: Math.floor(Math.random() * 10) >= 4 ? Math.floor(Math.random() * 50) : 0,

      params: [],

    }

    // 生成每个 sku 对应的 params 

    let skuI = 0;

    skuNames.forEach((name, j) => {

      if(skuCategorys[j]) {

        // 注意：LHH-1

        const value = skuData[name][indexArr[skuI]]

        sku.params.push({

          name,

          value,

        })

        skuI++;

      }

    })

    skusList.push(sku)



    // 注意: LHH-2

    indexArr[indexArr.length - 1]++;

    for(let j = indexArr.length - 1; j >= 0; j--) {

      if(indexArr[j] >= skuCategorys[j] && j !== 0) {

        indexArr[j - 1]++

        indexArr[j] = 0

      }

    }



    if(noStockSkus) {

      if(!sku.stock) {

        noStockSkus.at(-1)?.push(sku.params.map(p => p.value).join(' / '))

      }

      if(indexArr[0] === noStockSkus.length && noStockSkus.length < skuCategorys[0]) {

        noStockSkus.push([])

      }

    }

  }

  return skusList

}

Skus 组件的核心部分的实现

初始化数据

需要将上面生成的数据转化为以下结构：

type SkuStateItem = {

  value: string;

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

  disabledSkus: string[][];

}[];



export default function Skus() {

  // 转化成遍历判断用的数据类型

  const [skuState, setSkuState] = useState<Record<string, SkuStateItem>>({});

  // 当前选中的sku值

  const [checkSkus, setCheckSkus] = useState<Record<string, string>>({});

  

  // ...

}

将初始sku数据生成目标结构

根据 data （即上面的假数据）生成该数据结构。

第一次遍历是对skus第一项进行的，会生成如下结构：

const _skuState = {

  '颜色': [{value: '红', disabledSkus: []}],

  '大小': [{value: 'S', disabledSkus: []}],

  '款式': [{value: '圆领', disabledSkus: []}],

  '面料': [{value: '纯棉', disabledSkus: []}],

}

第二次遍历则会完整遍历剩下的skus数据，并往该对象中填充完整。

export default function Skus() {

  // ...

  useEffect(() => {

    if(!data?.length) return

    // 第一次对skus第一项的遍历

    const _checkSkus: Record<string, string> = {}

    const _skuState = data[0].params.reduce((pre, cur) => {

      pre[cur.name] = [{value: cur.value, disabledSkus: []}]

      _checkSkus[cur.name] = ''

      return pre

    }, {} as Record<string, SkuStateItem>)

    setCheckSkus(_checkSkus)



    // 第二次遍历

    data.slice(1).forEach(item => {

      const skuParams = item.params

      skuParams.forEach((p, i) => {

        // 当前 params 不在 _skuState 中

        if(!_skuState[p.name]?.find(params => params.value === p.value)) {

          _skuState[p.name].push({value: p.value, disabledSkus: []})

        }

      })

    })

    

    // ...接下面

  }, [data])

}

第三次遍历主要用于为每个 sku的可点击项 生成一个对应的禁用sku数组 disabledSkus ，只要当前选择的sku项，满足该数组中的任一项，该sku选项就会被禁用。之所以保存这样的一个二维数组，是为了方便后面点击时的条件判断（有点空间换时间的概念）。

遍历 data 当库存小于等于0时，将当前的sku的所有参数传入 disabledSkus 中。

例：第一项 sku（红，S，圆领，纯棉）库存假设为0，则该选项会被添加到 disabledSkus 数组中，那么该sku选择时，勾选前三个后，第四个 纯棉 的勾选会被禁用。

export default function Skus() {

  // ...

  useEffect(() => {

    // ... 接上面

    // 第三次遍历

    data.forEach(sku => {

      // 遍历获取库存需要禁用的sku

      const stock = sku.stock!

      // stockLimitValue 是一个传参 代表库存的限制值，默认为0

      // isStockGreaterThan 是一个传参，用来判断限制值是大于还是小于，默认为false

      if(

        typeof stock === 'number' && 

        isStockGreaterThan ? stock >= stockLimitValue : stock <= stockLimitValue

      ) {

        const curSkuArr = sku.params.map(p => p.value)

        for(const name in _skuState) {

          const curSkuItem = _skuState[name].find(v => curSkuArr.includes(v.value))

          curSkuItem?.disabledSkus?.push(

            sku.params.reduce((pre, p) => {

              if(p.name !== name) {

                pre.push(p.value)

              }

              return pre

            }, [] as string[])

          )

        }

      }

    })



    setSkuState(_skuState)

  }, [data])

}

遍历渲染 skus 列表

根据上面的 skuState，生成用于渲染的列表，渲染列表的类型如下：

type RenderSkuItem = {

  name: string;

  values: RenderSkuItemValue[];

}

type RenderSkuItemValue = {

  /** sku的值 */

  value: string;

  /** 选中状态 */

  isChecked: boolean

  /** 禁用状态 */

  disabled: boolean;

}



export default function Skus() {

  // ...

  /** 用于渲染的列表 */

  const list: RenderSkuItem[] = []

  for(const name in skuState) {

    list.push({

      name,

      values: skuState[name].map(sku => {

        const isChecked = sku.value === checkSkus[name]

        const disabled = isChecked ? false : isSkuDisable(name, sku)

        return { value: sku.value, disabled, isChecked }

      })

    })

  }

  // ...

}

html css 大家都会，以下就简单展示了。最外层遍历sku的分类，第二次遍历遍历每个sku分类下的名称，第二次遍历的 item（类型为：RenderSkuItemValue），里面会有sku的值，选中状态和禁用状态的属性。

export default function Skus() {

  // ...

  return list?.map((p) => (

    <div key={p.name}>

      {/* 例：颜色、大小、款式、面料 */}

      <div>{p.name}</div>

      <div>

        {p.values.map((sku) => (

          <div 

            key={p.name + sku.value} 

            onClick={() => selectSkus(p.name, sku)}

          >

            {/* classBem 是用来判断当前状态，增加类名的一个方法而已 */}

            <span className={classBem(`sku`, {active: sku.isChecked, disabled: sku.disabled})}>

              {/* 例：红、绿、蓝、黑 */}

              {sku.value} 

            </span>

          </div>

        ))}

      </div>

    </div>

  ))

}

selectSkus 点击选择 sku

通过 checkSkus 设置 sku 对应分类下的 sku 选中项，同时触发 onChange 给父组件传递一些信息出去。

const selectSkus = (skuName: string, {value, disabled, isChecked}: RenderSkuItemValue) => {

  const _checkSkus = {...checkSkus}

  _checkSkus[skuName] = isChecked ? '' : value;

  const curSkuItem = getCurSkuItem(_checkSkus)

  // 该方法主要是 sku 组件点击后触发的回调，用于给父组件获取到一些信息。

  onChange?.(_checkSkus, {

    skuName,

    value,

    disabled,

    isChecked: disabled ? false : !isChecked,

    dataItem: curSkuItem,

    stock: curSkuItem?.stock

  })

  if(!disabled) {

    setCheckSkus(_checkSkus)

  }

}

getCurSkuItem 获取当前选中的是哪个sku

• isInOrder.current 是用来判断当前的 skus 数据是否是整齐排列的，这里当成 true 就好，判断该值的过程就不放到本文了，感兴趣可以看 源码。

由于sku是按顺序排列的，所以只需按顺序遍历上面生成的 skuState，找出当前sku选中项对应的索引位置，然后通过 乘 就可以直接得出对应的索引位置。这样的好处是能减少很多次遍历。

如果直接遍历原来那份填充所有 sku 的 data 数据，则需要很多次的遍历，当sku是 6^6 时， 则每次变换选中的sku时最多需要 46656 * 6 (data总长度 * 里面 sku 的 params) 次。

const getCurSkuItem = (_checkSkus: Record<string, string>) => {

  const length = Object.keys(skuState).length

  if(!length || Object.values(_checkSkus).filter(Boolean).length < length) return void 0

  if(isInOrder.current) {

    let skuI = 0;

    // 由于sku是按顺序排列的，所以索引可以通过计算得出

    Object.keys(_checkSkus).forEach((name, i) => {

      const index = skuState[name].findIndex(v => v.value === _checkSkus[name])

      const othTotal = Object.values(skuState).slice(i + 1).reduce((pre, cur) => (pre *= cur.length), 1)

      skuI += index * othTotal;

    })

    return data?.[skuI]

  }

  // 这样需要遍历太多次

  return data.find(s => (

    s.params.every(p => _checkSkus[p.name] === getSkuParamValue(p))

  ))

}

isSkuDisable 判断该 sku 是否是禁用的

该方法是在上面 遍历渲染 skus 列表 时使用的。

const isCheckValue = !!Object.keys(checkSkus).length



const isSkuDisable = (skuName: string, sku: SkuStateItem[number]) => {

  if(!sku.disabledSkus.length) return false

  // 1.当一开始没有选中值时，判断某个sku是否为禁用

  if(!isCheckValue) {

    let checkTotal = 1;

    for(const name in skuState) {

      if(name !== skuName) {

        checkTotal *= skuState[name].length

      }

    }

    return sku.disabledSkus.length === checkTotal

  }



  // 排除当前的传入的 sku 那一行

  const newCheckSkus: Record<string, string> = {...checkSkus}

  delete newCheckSkus[skuName]



  // 2.当前选中的 sku 一共能有多少种组合

  let total = 1;

  for(const name in newCheckSkus) {

    if(!newCheckSkus[name]) {

      total *= skuState[name].length

    }

  }



  // 3.选中的 sku 在禁用数组中有多少组

  let num = 0;

  for(const strArr of sku.disabledSkus) {

    if(Object.values(newCheckSkus).every(str => !str ? true : strArr.includes(str))) {

      num++;

    }

  }



  return num === total

}

至此整个商品sku从生成假数据到sku的选中和禁用的处理的核心代码就完毕了。还有更多的细节问题可以直接查看 源码 会更清晰。