orcale可视化建立用户

by Sushrut Shivaswamy

通过Sushrut Shivaswamy

建立动态可视化的新方法 (A new way of building dynamic visualisations)

The Flux architecture gained popularity after Facebook adopted it. It’s a way of managing the state of React components so that the flow of the data through the app is unidirectional.

Facebook采纳Flux架构后，该架构开始流行。 这是一种管理React组件状态的方法，因此通过应用程序的数据流是单向的。

The advantages of this approach are that the app is comprised of few stateful components that passes state down to nested child components. A feature of React that really complements this approach to state management is that React allows us to write UI as a function of state. This means that, as state percolates down the app’s component hierarchy, components automatically change the view to reflect the changes in state.

这种方法的优势在于，该应用程序由几个有状态的组件组成，这些组件将状态向下传递给嵌套的子组件。 实际上，React的一个功能是对该状态管理方法的补充，它使我们能够将UI编写为状态的函数。 这意味着，随着状态渗透到应用程序的组件层次结构中，组件会自动更改视图以反映状态的变化。

JSX, a templating system used by React, allows for the creation of reusable single file components.

JSX是React使用的模板系统，允许创建可重用的单个文件组件。

It also lends itself really well to creating a demarcation between the structure of the DOM and the behaviours associated with it.

它还非常适合在DOM的结构和与其关联的行为之间创建界线。

• JSX gives a clean view of the DOM structure that is more intuitive than the several lines of JavaScript required to create the same DOM structure.
  JSX给出了DOM结构的清晰视图，比创建相同DOM结构所需的几行JavaScript更直观。
• The behaviours associated with the DOM structure — eventHandlers like onClick, onHover — are handled as member functions of the component.
  与DOM结构相关的行为(如onClick，onHover之类的eventHandlers)将作为组件的成员函数进行处理。

• Any changes to the DOM structure require the user to call setState to change the state of the component instead of directly mutating the DOM. This makes it easier to debug the application, and it also ensures that the application is always in a defined state.

  对DOM结构的任何更改都要求用户调用setState来更改组件的状态，而不是直接更改DOM 。 这使调试应用程序变得更加容易，并且还确保了应用程序始终处于定义状态。

As the complexity of the app grew, however, the Flux approach also began to show its limitations.

但是，随着应用程序复杂性的提高，Flux方法也开始显示其局限性。

Few stateful components passing state down to child components seem fine for small apps. But, as the complexity of the component hierarchy increases, stateful components have to share state with each other.

对于小型应用程序，很少有状态组件将状态传递给子组件。 但是，随着组件层次结构的复杂性增加，有状态组件必须彼此共享状态。

While it is possible to share state across different components/classes in JavaScript through common variables or, preferably, the Observer pattern, as the number of components increases it becomes harder to maintain the application.

尽管可以通过公共变量或最好是Observer模式在JavaScript中的不同组件/类之间共享状态，但是随着组件数量的增加，维护应用程序变得更加困难。

The simplicity of components reacting to changes in state is muddled with the complexities of object-oriented design.

组件对状态变化做出React的简单性与面向对象设计的复杂性混为一谈。

图表-为什么很难制作？ (Charts — why are they hard to make?)

The advances that web apps have benefited from have not changed the way that charting libraries are made. A chart is also a presentational component, and can technically be termed as UI. A chart is also composed of DOM elements that control its visual appearance.

Web应用程序受益的进步并未改变制图库的制作方式。 图表也是一个表示性组件，在技术上可以称为UI。 图表还由控制其外观的DOM元素组成。

However, charts differ in one key aspect: developers don’t treat SVG as DOM. Technically, the <svg> tag is not even an HTMLElement like other DOM elements, and sits in a separate namespace. SVG is only known for its ability to scale to any viewport size and maintain the resolution of the image at a constant level. That’s the extent to which most developers know about it.

但是，图表在一个关键方面有所不同：开发人员不会将SVG视为DOM。 从技术上讲， <s vg>标记甚至不是像其他DOM元素一样HTMLElement，而是位于单独的命名空间中。 SVG仅以能够缩放到任何视口大小并将图像分辨率保持在恒定水平的能力而闻名。 这就是大多数开发人员对此了解的程度。

Also the tags used to create an SVG image like <point>, &lt;rect />, and <polyline /> sound very “math like.” This makes developers shy away from how SVG structures actually work.

还有用于创建SVG图像的标签，例如<poi nt >, &l t; rect />, and <polyline />声音 非常“像数学”。 这使开发人员避开了SVG结构的实际工作方式。

Even those involved with applications that make heavy use of SVG are usually unaware of its inner workings. They utilise other libraries like snap or d3 to avoid the hassle of understanding what goes on under the hood.

即使是那些涉及大量使用SVG的应用程序的人员，通常也不会意识到其内部工作原理。 他们利用其他库(例如snap或d3)来避免了解幕后情况的麻烦。

Having avoided the underlying complexity of the SVG tag, it feels easy to model complex SVG constructs.

避免了SVG标签的潜在复杂性，为复杂的SVG结构建模很容易。

几何 (Geometry)

Consider a bar chart, for example.

例如，考虑一个条形图。

We traditionally adopt a cookie cutter approach and split a chart into parts:

传统上，我们采用千篇一律的方法，将图表分为几个部分：

• x-axis
  X轴
• y-axis
  y轴
• bars
  酒吧

A seasoned developer would notice that the word axis was written twice in the above list. So lets create an abstraction layer called Axis that subclasses can inherit from.

经验丰富的开发人员会注意到单词轴在上面的列表中写了两次。 因此，让我们创建一个称为Axis的抽象层，子类可以从中继承。

To render the bars, we can create a separate class called Bar that utilises the scale provided by the axis class. As charts come in various shapes, it makes more sense to have an abstraction layer called Geometry that other classes can inherit from, namely Bar, Point, Line, and Area. As more complex charts are made, several new geometry types can be added to render different kinds of charts.

为了渲染条形图，我们可以创建一个单独的类Bar ，该类利用axis 类 提供的比例尺 。 由于图表具有各种形状，因此有一个名为 其他类可以继承的 Geometry ，即 Bar ， Point ， Line和Area 。 制作更复杂的图表时，可以添加几种新的几何类型以呈现不同种类的图表。

Following the above methodology, a chart comprises three or more stateful components that utilise each others’ properties to render a meaningful chart.

按照上述方法，图表包含三个或更多有状态的组件，这些组件利用彼此的属性来呈现有意义的图表。

To update or enhance the chart, a developer is expected to know the state to mutate in each of these components. Since state is scattered across various components, even simple changes take a lot of time for new developers. The ordering of the state changes also becomes relevant.

要更新或增强图表，开发人员应了解这些组件中每个组件的状态变化 。 由于状态分散在各个组件中，因此即使是简单的更改，新开发人员也要花费大量时间。 状态更改的顺序也变得相关。

In the above example, the geometry utilises the scale of the axes. For the chart to be resized, the range of each axis has to be updated before updating the Geometry.

在上面的示例中，几何图形利用了轴的比例。 为了调整图表的大小，必须在更新Geometry 之前更新每个轴的范围。

Not following this ordering will lead to visual artefacts — because the geometry would be distorted due to an invalid scale. At worst, failure to carry out this ordered sequence of operations could leave the chart in an undefined state.

不遵循此顺序将导致视觉伪影-因为几何将因比例尺无效而变形。 最坏的情况是，如果无法执行此有序的操作序列，则可能会使图表处于未定义状态。

Having cross-connectivity between charts further compounds this problem. The orchestration of state changes spans multiple charts/interacting components.

图表之间的交叉连接进一步加剧了这个问题。 状态更改的编排跨越多个图表/交互组件。

Having so many interacting components with directed relationships can also lead to cyclic dependencies between components.

具有如此直接关系的交互组件如此之多，也可能导致组件之间的循环依赖性。

This was a problem that plagued UI development frameworks as well until developing web applications with a single source of truth became the standard. The most influential library in directing the shift to single source of truth webapps was Redux.

在使用单一事实来源开发Web应用程序成为标准之前，这也是困扰UI开发框架的问题。 Redux是引导向单一来源的Webapp转移的最有影响力的库。

Note: The next section explains how using Redux makes web app development easier. Feel free to skip it if you already know about Redux.

注意 ：下一部分将说明如何使用Redux简化Web应用程序的开发。 如果您已经了解Redux，请随时跳过。

Redux (Redux)

Redux is a library developed by Dan Abhramov. It helps ease the burden of developers by providing an easy way to maintain the state of an application.

Redux是由Dan Abhramov开发的库。 通过提供一种维护应用程序状态的简便方法，它有助于减轻开发人员的负担。

Redux introduced the concept of a state store that acted as the single source of truth for the entire application. Instead of components directly mutating the state, each component would dispatch an action that would commit a change to the unified state store.

Redux引入了状态存储的概念，该状态存储充当整个应用程序的单一事实来源。 代替直接改变状态的组件，每个组件将调度一个动作，该动作将更改提交给统一状态存储。

Each action was identified by a unique enum that would be logged every time a change was committed to the state store. This made it easy to track how the state store was being mutated.

每个动作都由一个唯一的枚举标识， 每次更改提交给状态存储区时，该枚举都会记录下来。 这使得跟踪状态存储的更改方式变得很容易。

Once a change was committed to the state store, the new state would percolate down the component hierarchy. Components would re-render or ignore the change depending on whether the part of the state that changed was relevant to them. Components could no longer mutate the state in isolation. It had to be at a global level.

一旦将更改提交给状态存储，新状态就会渗透到组件层次结构中。 组件将重新呈现或忽略更改，具体取决于更改的状态部分是否与它们相关。 组件不再可以孤立地更改状态。 它必须在全球范围内。

The main purpose is to isolate state management from side effects like rendering and fetching data from the server. Always leave the application in a defined state.

主要目的是将状态管理与副作用隔离开，例如从服务器渲染和获取数据。 始终使应用程序处于定义状态。

This lays the foundation for a deterministic view render. Given a sequence of state changes, you will always end up with the same rendered view.

这为确定性视图渲染奠定了基础。 给定一系列状态更改，您将总是最终获得相同的渲染视图。

This level of deterministic view rendering is especially helpful for offline applications. Here, the sequence of state mutations that happen while user is offline can be stored and replayed when connectivity is re-established to get back the same view.

这种确定性的视图呈现级别对于脱机应用程序特别有用。 在这里，当用户脱机时发生的状态突变序列可以被存储并在重新建立连接以返回相同视图时重放。

The success of of the React-Redux model spawned a number of other libraries like Vue and Cycle, as well as several other implementations of the state store like MobX and Vuex.

React-Redux模型的成功产生了许多其他库，例如Vue和Cycle ，以及状态存储的其他几种实现，例如MobX和Vuex 。

深入了解SVG (A closer look at SVG)

SVG stands for scalable vector graphics. The svg tag can optionally house various kinds of geometry, which expose a number of DOM attributes.

SVG代表可缩放的矢量图形。 svg标签可以选择容纳各种几何图形，这些几何图形可以显示许多DOM属性。

Circle: <circle />

圆 ： <circle />

Attributes:

属性：

• cx: x offset of circle in viewport

  cx ：视口中圆的x偏移量

• cy: y offset of circle in viewport

  cy ：视口中圆的y偏移

• r : radius of circle

  r ：圆半径

Polyline: <polyline />

折线 ： <polyline />

Attributes:

属性：

• points: array of points (x, y) through which a line is drawn.

  points：画一条线的点(x，y)的数组。

Polygon: <polygon />

多边形 ： <polygon />

Attributes:

属性：

• points: array of points (x, y) to construct a polygon.

  points ：用于构造多边形的点(x，y)的数组。

Text: <text />

文字 ： <text />

Attributes:

属性：

• x: x offset of text in viewport

  x ：视口中文本的x偏移量

• y: y offset of text in viewport

  y ：视口中文本的y偏移量

• innerText: The text to show.

  innerText ：要显示的文本。

Many more geometry types are available in the SVG standard, but for the purposes of charts, the above will suffice. These geometric elements can also be styled with normal CSS.

SVG标准中提供了更多的几何类型，但是出于图表目的，上述内容就足够了。 这些几何元素也可以使用普通CSS设置样式。

寻找一座桥 (Finding a bridge)

These are the guiding principles behind modern web application development and development of charting libraries. Let’s try to isolate where developing charting libraries differs from web applications:

这些是现代Web应用程序开发和图表库开发背后的指导原则。 让我们尝试隔离开发图表库和Web应用程序的地方：

• web apps are composed of DOM nodes. Charts are composed of SVG geometries.

  Web应用程序由DOM节点组成。 图表由SVG几何组成。

• web apps can be broken down into reusable sections of DOM that can be modelled as components. Charts aren’t modelled as reusable set of geometries.

  Web应用程序可以细分为DOM的可重用部分，这些部分可以建模为组件。 图表未建模为可重复使用的一组几何图形。

• web app frameworks are always coupled with a templating engine so that DOM structure can be modelled in markup and the behaviours can be separated from it and written in JavaScript. Charts have no such framework available.

  Web应用程序框架始终与模板引擎结合使用，以便可以在标记中对DOM结构进行建模，并可以将行为与标记分离并用JavaScript编写。 图表没有此类可用框架。

• web app frameworks allow for a state store to be incorporated through the use of a plugin. Charts are usually modelled as stateful components.

  Web应用程序框架允许通过使用插件来合并状态存储。 图表通常建模为有状态的组件。

重塑图表复杂度 (Remodelling chart complexity)

A chart is a visual tool that showcases variation across fields in the data using geometry.

图表是一种可视化工具，可显示使用几何图形的数据中各个字段的变化。

So how does that work?

那如何运作？

Looking at the chart above, what do we see? Circles offset in the viewport based on fields present in the data.

查看上图，我们看到了什么？ 根据数据中存在的字段，视口中的圆偏移。

What else?

还有什么？

• Ticks offset along the bottom based on a field in the data.
  刻度线根据数据中的字段沿底部偏移。
• Text labels offset along the bottom based on a field in the data.
  文本标签基于数据中的字段沿底部偏移。
• Same as above along the left side of the chart.
  与图表左侧的上方相同。

Let’s break it down to the level of geometries.

让我们将其分解为几何级别。

How do we render the circles in the scatterplot?

我们如何在散点图中绘制圆圈？

<circle cx=”horsepowerScale()” cy=”milesPerGallonScale()” cr=”const” />

<circle cx=”horsepowerScale()” cy=”milesPerGallonScale()” cr=”const” />

What about the axes? X-Axes: Text + Ticks

轴呢？ X轴：文字+刻度

<text x=”horsepowerScale()” y=”0”>{{ text value }}&lt;/text>

<text x=”horsepowerScale()” y=”0”>{{ text value }}& lt; / text>

<tick x=”horsepwerScale()” y=”0” />

<tick x=”horsepwerScale()” y=”0” />

There is a similar SVG structure for the y-axis, except that the scale function changes and the x, y fields are inverted.

y轴具有类似的SVG结构，除了比例函数发生变化并且x，y字段被反转。

The common theme above is that the chart is viewed as a meaningful arrangement of geometry:

上面的共同主题是， 图表被视为有意义的几何排列：

• each geometry in the SVG namespace exposes visual attributes
  SVG名称空间中的每个几何都公开了视觉属性
• the value of these attributes is bound to a calculated value
  这些属性的值绑定到计算值
• the calculated value depends on the scale
  计算值取决于比例尺
• the scale depends on a field in the data and the range
  小数位数取决于数据中的字段和范围

规模是多少？ (What is a scale?)

A scale is a function that maps data to a position in the viewport.

比例尺是一种将数据映射到视口中某个位置的功能。

What is the input to scale?

规模输入是什么？

• the domain of the field
  领域的领域
• the length of the viewport to map to
  要映射到的视口的长度

Let R be the length of viewport and D be the domain of the data.

设R为视口长度， D为数据域。

• Then we can define a scaling function S as:

  然后我们可以将缩放函数S定义为：

• S = f(D, R) + b

  S = f(D，R)+ b

where b is a constant.

其中b是常数。

图表需要多少个刻度？ (How many scales does a chart need to have?)

If you’re thinking two, then you’re wrong.

如果您想两个，那就错了。

Scale doesn’t exist only along x- and y-axes. The axes themselves are only present in a chart as visual anchors so that users can line up data variations along multiple dimensions.

缩放不仅沿x轴和y轴存在。 轴本身仅在图表中显示为可视锚点，以便用户可以沿多个维度排列数据变化。

The axis is just geometry that is rendered using a scale.

轴只是使用比例尺渲染的几何。

有多少个尺寸？ (How many dimensions are there?)

It’s not two. The viewport is two-dimensional but that has nothing to do with the dimensionality of the chart. The dimensionality of a chart is defined by the number of scaling functions used.

不是两个 视口是二维的，但与图表的尺寸无关。 图表的维数由使用的缩放功能的数量定义。

The overarching concept comprises of two simple terms: Geometry and Scale.

总体概念由两个简单术语组成： Geometry和Scale 。

Each geometry exposes visual attributes that control its appearance.

每种几何都公开控制其外观的视觉属性。

The value of these attributes can be hooked up to scaling functions. The scaling function is tied to a particular field in the data.

这些属性的值可以连接到缩放函数。 缩放功能与数据中的特定字段相关。

This lends itself to the idea that every visual attribute in a chart can only be tied to one field in the data table.

这使自己的想法是，图表中的每个视觉属性只能与数据表中的一个字段相关联。

Given this decomposition of charts we can model the scatter plot above as follows:

鉴于图表的分解，我们可以如下对散点图进行建模：

The field Horsepower is used to create a scaling function called horsepowerScale().

字段Horsepower用于创建称为horsepowerScale()的缩放函数。

The field Acceleration is used to create a scaling function called accelerationScale().

字段Acceleration用于创建一个称为accelerationScale()的缩放函数。

Since we are not varying the size of the circles, only two scaling functions are required.

由于我们没有改变圆的大小，因此仅需要两个缩放函数。

Any circle i in the scatterplot can be represented as

散点图中的任何圆圈i都可以表示为

<circle cx="horsepowerScale(ti)" cy="accelerationScale(ti)" cr="5" />

<circle cx="horsepowerScale(ti)" cy="accelerationScale(ti)" cr="5" />

where ti is the ith tuple in the Datatable.

其中ti是数据表中的第i个元组。

Given that only two scaling functions were used, the dimensionality of the above chart becomes two.

假设仅使用了两个缩放函数，则上图的维数将变为2。

If we also modulated the size of each circle, using a scaling function tied to another field, then the dimensionality would be three.

如果我们还使用绑定到另一个字段的缩放函数来调制每个圆的大小，则维数将为3。

Doing so would result in what is known as a “bubble chart”.

这样做将导致所谓的“气泡图”。

图形语法 (Grammar of Graphics)

This is similar to the Grammar of Graphics (GOG) approach, where every chart is defined by a mark (geometry) and the visual encodings used by the mark.

这类似于图形语法(GOG)的方法，在该方法中，每个图表都由一个标记(几何形状)和该标记使用的可视编码定义。

In a GOG approach the scatterplot would be represented as:

在GOG方法中，散点图将表示为：

{

mark: 'circle',

encoding: {

x: 'horsepower',

y: 'acceleration'

}

}

Notice that there is a one-to-one mapping between the encoding of a GOG geometry and the visual attributes exposed by the geometry in SVG.

请注意，GOG几何的编码与SVG中的几何公开的视觉属性之间存在一对一的映射 。

The axis can also be rendered similarly:

轴也可以类似地渲染：

• The x-axis is a tick geometry with its x-offset attribute tied to horsepowerScale() and its y-offset set to 0.

  x轴是刻度几何，其x-offset属性与 horsepowerScale()及其y偏移设置为0。

• The y-axis is a tick geometry with its y-offset attribute tied to accelerationScale() and its x-offset set to 0.

  y轴是刻度几何，其y-offset属性绑定到accelerationScale() ，其x-offset设置为0。

To render the scatterplot with all its elements, the following snippet of code would suffice:

要渲染散点图及其所有元素，以下代码片段就足够了：

Decomposition of charts into an association between visual attributes and a scaling function allows us to view a chart as a web app.

将图表分解为视觉属性和缩放功能之间的关联，使我们可以将图表作为Web应用程序查看。

Web Application frameworks model UI as a function of state.

Web应用程序框架将UI建模为状态的函数。

Charts Frameworks should model geometry as a function of scale.

图表框架应将几何建模为比例函数。

So the idea that makes web applications easy to develop can easily be extended to creating charts:

因此，使Web应用程序易于开发的想法可以轻松地扩展到创建图表：

• Initially, tabular data is supplied as input.
  最初，提供表格数据作为输入。
• For every field in the Data array, a scaling function is created. The scaling function selectively recomputes values when a field in the column is tied to changes. The same scaling function is percolated throughout the application.
  对于数据数组中的每个字段，都会创建一个缩放函数。 当列中的字段与更改绑定在一起时，缩放功能有选择地重新计算值。 整个应用程序都渗透了相同的缩放功能。
• Every geometry is modelled as a component that exposes visual attributes.
  每个几何图形都被建模为公开视觉属性的组件。
• The value of these visual attributes is tied to a scaling function that reacts to changes in data.
  这些视觉属性的值与对数据变化做出React的缩放函数相关。
• The collections of geometry can be represented in markup using a templating engine of choice like hyperHTML, mustache, or handlebars. Ideally, the templating engine should be introduced as a plugin so that we can avoid writing bindings for different libraries like React and Angular.
  可以使用选择的模板引擎(例如hyperHTML，胡须或车把)在标记中表示几何图形的集合。 理想情况下，应将模板引擎作为插件引入，这样我们就可以避免为React和Angular等不同库编写绑定。
• The state store that selectively computes scales should also be introduced as a plugin.
  选择性计算比例的状态存储也应作为插件引入。

Let’s see what putting a chart together using the above principles would look like:

让我们看看使用上述原理将图表组合在一起的样子：

We are using React as a templating engine and Redux as the state store in the above example.

在上面的示例中，我们使用React作为模板引擎，使用Redux作为状态存储。

The above approach is just a rough implementation of what a framework that can model charts as webapps would would like like.

上面的方法只是对可以将图表建模为Web应用程序的框架想要的框架的粗略实现。

Notice the separation of the templating engine and state store from the actual rendering logic.

注意，模板引擎和状态存储与实际渲染逻辑是分开的。

最后一点 (Final points)

Ideally, geometries/charts that we create should be available as components in the framework of the user’s choice along with their state store. If it seems unthinkable that something like this could even be done, stay calm. It’s been done before.

理想情况下，我们创建的几何图形/图表应随用户的状态存储一起作为用户选择的框架中的组件提供。 如果似乎无法做到这样的事情，请保持冷静。 之前已经完成了。

SkateJS is a compiler that creates web components but allows user to switch internal rendering engines.

SkateJS是可创建Web组件但允许用户切换内部渲染引擎的编译器。

Users can choose between React, Preact, lit-html or extend the Renderer interface to write their own. The default renderer just mutates the DOM directly.

用户可以在React，Preact，lit-html之间进行选择，或扩展Renderer界面以编写自己的界面。 默认渲染器仅直接更改DOM。

We can be even more ambitious with what we choose once we have synchronous rendering coupled with state management.

一旦拥有同步渲染和状态管理功能，我们就可以对选择的东西更加抱负。

Imagine a TickProvider component that allows for rendering only small clusters of geometry in a given animation frame as well as allowing us to identify bottlenecks in our rendering pipeline.

想象一下一个TickProvider组件， TickProvider允许在给定的动画帧中渲染几何的小簇，并且允许我们识别渲染管道中的瓶颈。

Given that a chart is meaningful arrangement of geometry, it follows that meaningful clusters of geometry should render together.

鉴于图表是几何的有意义的排列方式，因此有意义的几何簇应一起呈现。

In the scatter plot example, for every group of circles that render, the corresponding sections of the x/y axis geometry should also render simultaneously.

在散点图示例中，对于渲染的每组圆，x / y轴几何的相应部分也应同时渲染。

If we break the rendering into chunks, where each chunk consists of one meaningful cluster of geometry as modelled above, we can support beautiful transitions that add to the visual appeal of the chart.

如果将渲染分成多个块，每个块都由一个有意义的几何簇组成(如上模型所示)，则我们可以支持漂亮的过渡效果，从而增加图表的视觉吸引力。

Another advantage of a TickProvider is that we can profile and ensure that each cluster of geometry renders completely in the time allotted per tick. This will help avoid freezing of the UI when the geometry count to be rendered is very large. Instead of running a render loop over the entire geometry collection, we could batch the render calls in sync with the animation frames.

TickProvider另一个优点是我们可以剖析并确保每个几何TickProvider在每个刻度分配的时间内完全呈现。 当要渲染的几何图形数量很大时，这将有助于避免冻结UI。 无需在整个几何图形集合上运行渲染循环，我们可以与动画帧同步批处理渲染调用。

We can also break down the calculation of visual attribute values.

我们还可以分解视觉属性值的计算。

Consider a data table that has N fields being used to render dashboards with the above approach.

考虑具有上述方法的具有N个字段的数据表用于呈现仪表板。

Since we are using a centralised state store, we can calculate the values of the N scaling function and memorize them. They only need to be re-calculated when the associated data table field changes.

由于我们使用的是集中式状态存储，因此我们可以计算N缩放函数的值并将其存储起来。 仅在关联的数据表字段更改时才需要重新计算它们。

Also, consider the equation below that computes the value of m visual attributes based on the scaling functions.

此外，请考虑以下方程式，该方程式基于缩放函数计算m个视觉属性的值。

The 0th value for a visual attribute V, that is bound to field 0 of N, can be calculated as follows:

可视属性V的第0个值(绑定到N的字段0)可以如下计算：

V(0) = S(d0, R) + b0

V(0)= S(d0，R)+ b0

• where d0 is the 0th data tuple from the data table
  其中d0是数据表中的第0个数据元组
• R is the range supplied as a prop to the component
  R是作为道具提供的范围
• b0 is constant
  b0是常数

If we write a series of such equations together we see this:

如果我们一起编写一系列这样的方程式，我们将看到：

V(0) = S(d0, R) + b0

V(0)= S(d0，R)+ b0

V(1) = S(d1, R) + b1

V(1)= S(d1，R)+ b1

V(2) = S(d2, R) + b2

V(2)= S(d2，R)+ b2

..

..

V(m) = S(dm, R) + bm

V(m)= S(dm，R)+ bm

The scaling function itself can be expressed as a linear equation. We have a set of linear equations that can be batch computed to calculate the value for visual attributes.

比例函数本身可以表示为线性方程。 我们有一组线性方程式，可以批量计算以计算视觉属性的值。

How so?

为何如此？

The above arrangement looks suspiciously like a matrix.

上述安排可疑地看起来像一个矩阵。

Computations in the browser are slow, but matrix computations can be sped up by leveraging GPU acceleration.

浏览器中的计算速度很慢，但是可以利用GPU加速来加快矩阵计算的速度。

Modelling the chart as geometry as a function of scale could therefore help us render charts much faster, as well handle larger volumes of data with a fast first render.

因此，将图表建模为几何图形与比例的函数可以帮助我们更快地绘制图表，并通过快速的首次渲染处理大量数据。

Data Visualisation is something that help us glean insights from large quantities of data. The impact that it has on decision making is slowly going up with multiple organisations looking to make data driven decisions.

数据可视化可以帮助我们从大量数据中收集见解。 它对决策的影响正在逐步与多家寻求数据驱动决策的组织密切相关。

Safe to say, we need a more robust, accessible and maintainable way of developing visualisations.

可以肯定地说，我们需要一种更强大，可访问和可维护的可视化开发方式。

What do you think?

你怎么看？

翻译自: https://www.freecodecamp.org/news/a-new-way-of-building-dynamic-visualisations-5c732091a3c1/

orcale可视化建立用户