HighCharts源码解析之Class体系
HighCharts
是一个默认使用SVG
渲染器的图表引擎,其对内部的DOM
元素都设置了Class
属性以描述其类别和样式。起到了类似ECharts theme的效果。
HighCharts
是一个默认使用SVG
渲染器的图表引擎,其对内部的DOM
元素都设置了Class
属性以描述其类别和样式。起到了类似ECharts theme的效果。
G2
设计了一套规范(Spec) 去描述可以绘制的可视化,使得用户可以通过调用 chart.options(options)
根据指定的满足规范的选项(options) 去渲染图表。
1 | (() => { |
基于底层的 Spec
,为了提供更多样化和灵活地声明图表的能力,G2
也提供了一系列函数式 API 来声明图表,比如声明上面简单的条形图:
1 | (() => { |
本文将探究G2
是如何实现两套语法用于绘制图表的。
首先介绍两个定义:
图表画布:整个用于绘制图表内容的区域,包括图例、轴、以及图表名称。
图表数据映射区域:X
轴与Y
轴框定的,用于将柱子或者折线映射到像素的画布区域。
与ECharts
的Padding
仅解决图元向图表画布映射范围问题不同,G2
的Padding解决的不是图元布局问题而是真正意义上的图表数据映射区域到图表的边界的距离。
我们先来看G2
的解决方案:
G2
当图例、Y轴名称、Y轴标签或其余图元位置或大小发生变化时会挤占图表空间。
优点是:更加智能,且不会产生重叠,用户只需关心一个边距(Padding)的概念即可配置出相对好看的图表,更加易用。
缺点是:当出现极端数据例如10个数量级或者跟大的数值,或者极长的数据项名称时,图表的空间会被过度挤压以至于无法查看。
我们再来看ECharts
的解决方案:
ECharts
当图例、Y轴名称、Y轴标签或其余图元位置或大小发生变化时会不会挤占图表空间,不会更改数据到图表像素映射,如果图例过长一般会发生遮挡,如果轴标签过长则会产生覆盖。
优点:不会破坏图表的布局方式,在图表包含异常值时优先保证图表的正常显示。
缺点:不够智能,具有异常值时会产生遮挡或截断。
本文不讨论这两种实现方案哪种更优,仅尝试从源码的角度分析G2
是如何实现自适应映射范围的。
Observable Plot是一个免费的开源 JavaScript 库,用于可视化表格数据,专注于加速探索性数据分析。
Observable Plot用于探索性数据可视化。它用于快速发现见解。它的 API 不仅富有表现力且可配置,还针对简洁性和易记性进行了优化。我们希望首次绘制图表的时间尽可能快。
而且速度还不止于此:Plot 可帮助您快速调整和优化数据视图。我们希望 Plot 能让您花更少的时间阅读文档、搜索要复制粘贴的代码和调试 — 而花更多时间询问数据问题。
与其他可视化工具(包括 D3 等低级工具和图表模板等表达能力较弱的高级工具)相比,我们认为使用 Plot 探索数据会更有效率。您将花更多时间“用视觉思考”,而花更少的时间处理编程机制。
属性和特性是完全不同的东西
1 | <div foo="bar">…</div> |
本文是《数据可视化之美》的阅读笔记,解构并重组了其原本的组织形式,剔除了部分具体的可视化案例(如词云、纽约地铁、美国民航以及本书后期的大量具体案例)。目的是从中分析和总结一些可视化设计的原则和方法论,以指导未来的可视化设计和开发。
《数据可视化之美》主要讲述了可视化的一些设计准则,如何通过数据可视化来讲述故事,以及一个可视化项目的执行流程,并通过具体案例了解可视化探索的过程和一些有趣的发现。
其中,大多数信息可视化的原始驱动力在于对数据的探索和描述,推动其发展的主要是一些出版机构(如《纽约时报》、《连线》)。可视分析的推动者多为非营利组织或学术组织,而在一些科学可视化和可视化软件中则可以看到商业组织的身影。
针对无限画布这个场景,在业界figma的画布交互体验是公认的比较好的。不过figma
采用的是canvas
方案。本文介绍基于Dom的无限画布实现方案。
1 | <!-- 画布容器 --> |
1 | // 画布的移动属性 |