跳到正文
册页

图表

PieChart - 饼图

一个整体的若干部分。

用法

什么时候用它

只回答“大概占多少”，再精确就不行了。要排序或比较扇区——尤其是跨两张饼图比较——那是 BarChart 的活。

来自@misoto22/folio/charts

TSX
import { PieChart } from '@misoto22/folio/charts'

说明

一个整体的若干部分。

有必要说白：饼图只回答“大概占多少”，再精确就不行了。用眼睛比较两个相邻扇区，超过五个左右就不可靠；跨两张饼图比较更糟。当读者需要排序或比较时，<BarChart> 能把同一个问题回答得更好。

结构

PieChart anatomy
部件说明
图框必填ChartFigure 的那个 <figure>，零行数据时带一个空状态。这里没有坐标轴，所以在没有空状态的年代，零行数据的饼图就是一个空盒子上顶着一个名字、隐藏表格返回 null——图和它的文字等价物一起沉默。empty={false} 会把那种状态还回来，留给那种「空本身就是结论」的图。
扇区必填<PieChart.Pie>。每个扇区都由一道以该行 nameKey 取值为键的对角渐变上色，所以 config 的键必须和这些取值完全一致——名字不在 config 里的那一行，指向的是一道从未定义过的渐变，画出来就是没有填色的。
图例<PieChart.Legend>，默认在饼图下方居中。饼图没有一根给扇区命名的分类轴，所以名字就住在这里。
扇区标签<PieChart.Label>，一个以 --chart-surface 反白的 LabelList。它的 dataKey 默认取饼图的 value 键，所以把它组合进来，印出来的就是数字。
提示气泡<PieChart.Tooltip>，标题栏被压掉了：扇区自己的名字就是这一行的标签，再加一个标题等于把它印两遍。

实践建议

推荐

  • 扇区控制在大约五个以内。再多，读者就是在给角度排序了，而这正是饼图最不擅长的比较——BarChart 把同样的占比放到长度刻度上，排名不用额外做什么就从图里出来了。
  • 只要确切占比重要，就组合 <PieChart.Label>。它默认取 value 键，而一个印出来的数字直接消掉了对角度的估计——这是这种图形唯一真正的弱点，也是它最便宜的补救。
  • 给它一个 innerRadius。环形图读的是弧长、不是扇形面积，而眼睛更擅长前者，中间那个洞还是个放总数的地方。

避免

  • 负值没有对应的扇区。一个整体的若干部分里不可能有负的那一份，所以带着退款、或者用流失去抵扩张的拆解，是 WaterfallChart 的事——它就是为带正负号的贡献项造的。
  • 并排两张饼图不构成比较。跨两个圆去读同一个扇区，比在一个圆里读两个扇区还难，而读者照样会去试——把这两个周期放进同一张分组 BarChart。
  • 这张图要是得在强制颜色下活下来，paddingAngle 就要传一个正数。这里只有一种填充 variant，所以八个 --series-* 令牌会全部塌成 CanvasText，每个扇区都是同一块实心形状；把它们分开的只剩几何，而那一两度的缝隙就是全部。描边不是那个机制——它只在 paddingAngle 为负时才画出来，那时扇区互相重叠，用容器色描的边把它们重新分成一叠卡片。0 是唯一两样都没有的取值，于是一张默认的饼图在强制颜色下就是一整块均匀的圆盘，整个读法全压在图例和标签上。

示例

默认

默认的组合方式——扇区、一块 hover 面板和一份图例。饼图是靠角度来读的，而那是所有可选编码里最不精确的一种，所以它回答的是「大概占多少」，再精确就没有了：用眼睛把 275 和 200 排出名次是不可靠的，而超过五个扇区——恰好就是这么多——BarChart 能把同一个问题答得更好。图例在这里不是装饰，因为饼图没有分类轴，也没有别的东西为这些扇区命名；这个图形还附带一张同样行的隐藏表格，而确切的数字就住在那儿。

Visitors by browser
Visitors by browser
browserValue
chrome275
safari200
firefox187
edge173
other90

形状

三个属性——innerRadius、paddingAngle 和 cornerRadius——在同一组四个值上做出四种形状。把 innerRadius 抬到零以上就得到一个环形图，而它是两者里更好读的那个：那个洞拿走了读者本来会去判断的面积，只留下弧。最后一个选项设了一个负的 paddingAngle，让扇区互相重叠，而每个扇区随之带上的那圈表面色描边，正是把它们重新分成一叠卡片的东西——那是一种长相、不是一种读法，因为这四种形状画的是同样四个数字。

Visitors by browser — donut
Visitors by browser — donut
browserValue
chrome275
safari200
firefox187
edge173

标签与强调

针对同一个弱点的两种回答，并排放着。左边，PieChart.Label 把值印在每个扇区上：饼图全部的弱点就在于角度难读，而一个印出来的数字把猜测彻底拿掉了。右边的问题不是排名、而是某一个扇区——glowingSectors 给 Chrome 加了光晕，而在饼图和图例上都开着的 isClickable，让一次点击把其余每个扇区降到 15% 不透明度，于是被选中的那个独自站着。数字要紧时去拿标签，只有其中一个要紧时去拿光晕。

Labelled
Labelled
browserValue
chrome275
safari200
firefox187
edge173
One wedge is the point
One wedge is the point
browserValue
chrome275
safari200
firefox187
edge173

加载中

骨架。isLoading 把标记换成五个等分的扇区，并保住这个图形量出来的高度，所以真实数据落下来时页面不跳。它们是错峰脉动的，正是这一点让那道波绕着饼走，而不是整个饼一起眨眼；在 prefers-reduced-motion 下，它们改为停在一个平的中等不透明度上。你会为有数据时组合的那些部件，在这里照样组合——innerRadius 在这个状态下也会被读取，所以加载中的环形图和取代它的那个是同一个形状。

Visitors by browser
Loading

类型

TSX
export type PieVariant = 'gradient'

无障碍

  • title 必填；数据行同样会渲染成一份视觉隐藏的表格。
  • 图例默认放在饼图下方，因为饼图没有一根给扇区命名的分类轴。
  • 组合一个 Label 把数字印在扇区上：饼图的弱点就是角度难读，印出来的数字直接消掉了这次猜测。
  • 只有一种填充样式，这是刻意的。扇区又小又不规则，往里塞纹理只会读成噪声。

相关组件

RadialChartBarChart