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” />

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” />

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" />

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?

你怎么看？