orcale可視化建立用戶

by Sushrut Shivaswamy

通過(guò)Sushrut Shivaswamy

建立動(dòng)態(tài)可視化的新方法 (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架構(gòu)后，該架構(gòu)開始流行。 這是一種管理React組件狀態(tài)的方法，因此通過(guò)應(yīng)用程序的數(shù)據(jù)流是單向的。

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.

這種方法的優(yōu)勢(shì)在于，該應(yīng)用程序由幾個(gè)有狀態(tài)的組件組成，這些組件將狀態(tài)向下傳遞給嵌套的子組件。 實(shí)際上，React的一個(gè)功能是對(duì)該狀態(tài)管理方法的補(bǔ)充，它使我們能夠?qū)I編寫為狀態(tài)的函數(shù)。 這意味著，隨著狀態(tài)滲透到應(yīng)用程序的組件層次結(jié)構(gòu)中，組件會(huì)自動(dòng)更改視圖以反映狀態(tài)的變化。

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

JSX是React使用的模板系統(tǒng)，允許創(chuàng)建可重用的單個(gè)文件組件。

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

它還非常適合在DOM的結(jié)構(gòu)和與其關(guān)聯(lián)的行為之間創(chuàng)建界線。

• 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結(jié)構(gòu)的清晰視圖，比創(chuàng)建相同DOM結(jié)構(gòu)所需的幾行JavaScript更直觀。
• The behaviours associated with the DOM structure — eventHandlers like onClick, onHover — are handled as member functions of the component.
  與DOM結(jié)構(gòu)相關(guān)的行為(如onClick，onHover之類的eventHandlers)將作為組件的成員函數(shù)進(jìn)行處理。

• 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.

  對(duì)DOM結(jié)構(gòu)的任何更改都要求用戶調(diào)用setState來(lái)更改組件的狀態(tài)，而不是直接更改DOM 。 這使調(diào)試應(yīng)用程序變得更加容易，并且還確保了應(yīng)用程序始終處于定義狀態(tài)。

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

但是，隨著應(yīng)用程序復(fù)雜性的提高，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.

對(duì)于小型應(yīng)用程序，很少有狀態(tài)組件將狀態(tài)傳遞給子組件。 但是，隨著組件層次結(jié)構(gòu)的復(fù)雜性增加，有狀態(tài)組件必須彼此共享狀態(tài)。

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.

盡管可以通過(guò)公共變量或最好是Observer模式在JavaScript中的不同組件/類之間共享狀態(tài)，但是隨著組件數(shù)量的增加，維護(hù)應(yīng)用程序變得更加困難。

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

組件對(duì)狀態(tài)變化做出React的簡(jiǎn)單性與面向?qū)ο笤O(shè)計(jì)的復(fù)雜性混為一談。

圖表-為什么很難制作？ (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應(yīng)用程序受益的進(jìn)步并未改變制圖庫(kù)的制作方式。 圖表也是一個(gè)表示性組件，在技術(shù)上可以稱為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.

但是，圖表在一個(gè)關(guān)鍵方面有所不同：開發(fā)人員不會(huì)將SVG視為DOM。 從技術(shù)上講， <s vg>標(biāo)記甚至不是像其他DOM元素一樣HTMLElement，而是位于單獨(dú)的命名空間中。 SVG僅以能夠縮放到任何視口大小并將圖像分辨率保持在恒定水平的能力而聞名。 這就是大多數(shù)開發(fā)人員對(duì)此了解的程度。

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.

還有用于創(chuàng)建SVG圖像的標(biāo)簽，例如<poi nt >, &l t; rect />, and <polyline />聲音 非常“像數(shù)學(xué)”。 這使開發(fā)人員避開了SVG結(jié)構(gòu)的實(shí)際工作方式。

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的應(yīng)用程序的人員，通常也不會(huì)意識(shí)到其內(nèi)部工作原理。 他們利用其他庫(kù)(例如snap或d3)來(lái)避免了解幕后情況的麻煩。

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

避免了SVG標(biāo)簽的潛在復(fù)雜性，為復(fù)雜的SVG結(jié)構(gòu)建模很容易。

幾何 (Geometry)

Consider a bar chart, for example.

例如，考慮一個(gè)條形圖。

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

傳統(tǒng)上，我們采用千篇一律的方法，將圖表分為幾個(gè)部分：

• 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.

經(jīng)驗(yàn)豐富的開發(fā)人員會(huì)注意到單詞軸在上面的列表中寫了兩次。 因此，讓我們創(chuàng)建一個(gè)稱為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.

為了渲染條形圖，我們可以創(chuàng)建一個(gè)單獨(dú)的類Bar ，該類利用axis 類 提供的比例尺 。 由于圖表具有各種形狀，因此有一個(gè)名為 其他類可以繼承的 Geometry ，即 Bar ， Point ， Line和Area 。 制作更復(fù)雜的圖表時(shí)，可以添加幾種新的幾何類型以呈現(xiàn)不同種類的圖表。

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

按照上述方法，圖表包含三個(gè)或更多有狀態(tài)的組件，這些組件利用彼此的屬性來(lái)呈現(xiàn)有意義的圖表。

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.

要更新或增強(qiáng)圖表，開發(fā)人員應(yīng)了解這些組件中每個(gè)組件的狀態(tài)變化 。 由于狀態(tài)分散在各個(gè)組件中，因此即使是簡(jiǎn)單的更改，新開發(fā)人員也要花費(fèi)大量時(shí)間。 狀態(tài)更改的順序也變得相關(guān)。

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.

在上面的示例中，幾何圖形利用了軸的比例。 為了調(diào)整圖表的大小，必須在更新Geometry 之前更新每個(gè)軸的范圍。

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.

不遵循此順序?qū)?dǎo)致視覺偽影-因?yàn)閹缀螌⒁虮壤邿o(wú)效而變形。 最壞的情況是，如果無(wú)法執(zhí)行此有序的操作序列，則可能會(huì)使圖表處于未定義狀態(tài)。

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

圖表之間的交叉連接進(jìn)一步加劇了這個(gè)問(wèn)題。 狀態(tài)更改的編排跨越多個(gè)圖表/交互組件。

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

具有如此直接關(guān)系的交互組件如此之多，也可能導(dǎo)致組件之間的循環(huán)依賴性。

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.

在使用單一事實(shí)來(lái)源開發(fā)Web應(yīng)用程序成為標(biāo)準(zhǔn)之前，這也是困擾UI開發(fā)框架的問(wèn)題。 Redux是引導(dǎo)向單一來(lái)源的Webapp轉(zhuǎn)移的最有影響力的庫(kù)。

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

注意 ：下一部分將說(shuō)明如何使用Redux簡(jiǎn)化Web應(yīng)用程序的開發(fā)。 如果您已經(jīng)了解Redux，請(qǐng)隨時(shí)跳過(guò)。

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開發(fā)的庫(kù)。 通過(guò)提供一種維護(hù)應(yīng)用程序狀態(tài)的簡(jiǎn)便方法，它有助于減輕開發(fā)人員的負(fù)擔(dān)。

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引入了狀態(tài)存儲(chǔ)的概念，該狀態(tài)存儲(chǔ)充當(dāng)整個(gè)應(yīng)用程序的單一事實(shí)來(lái)源。 代替直接改變狀態(tài)的組件，每個(gè)組件將調(diào)度一個(gè)動(dòng)作，該動(dòng)作將更改提交給統(tǒng)一狀態(tài)存儲(chǔ)。

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.

每個(gè)動(dòng)作都由一個(gè)唯一的枚舉標(biāo)識(shí)， 每次更改提交給狀態(tài)存儲(chǔ)區(qū)時(shí)，該枚舉都會(huì)記錄下來(lái)。 這使得跟蹤狀態(tài)存儲(chǔ)的更改方式變得很容易。

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.

一旦將更改提交給狀態(tài)存儲(chǔ)，新狀態(tài)就會(huì)滲透到組件層次結(jié)構(gòu)中。 組件將重新呈現(xiàn)或忽略更改，具體取決于更改的狀態(tài)部分是否與它們相關(guān)。 組件不再可以孤立地更改狀態(tài)。 它必須在全球范圍內(nèi)。

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.

主要目的是將狀態(tài)管理與副作用隔離開，例如從服務(wù)器渲染和獲取數(shù)據(jù)。 始終使應(yīng)用程序處于定義狀態(tài)。

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.

這為確定性視圖渲染奠定了基礎(chǔ)。 給定一系列狀態(tài)更改，您將總是最終獲得相同的渲染視圖。

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.

這種確定性的視圖呈現(xiàn)級(jí)別對(duì)于脫機(jī)應(yīng)用程序特別有用。 在這里，當(dāng)用戶脫機(jī)時(shí)發(fā)生的狀態(tài)突變序列可以被存儲(chǔ)并在重新建立連接以返回相同視圖時(shí)重放。

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模型的成功產(chǎn)生了許多其他庫(kù)，例如Vue和Cycle ，以及狀態(tài)存儲(chǔ)的其他幾種實(shí)現(xiàn)，例如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標(biāo)簽可以選擇容納各種幾何圖形，這些幾何圖形可以顯示許多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：畫一條線的點(diǎn)(x，y)的數(shù)組。

Polygon: <polygon />

多邊形 ： <polygon />

Attributes:

屬性：

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

  points ：用于構(gòu)造多邊形的點(diǎn)(x，y)的數(shù)組。

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標(biāo)準(zhǔn)中提供了更多的幾何類型，但是出于圖表目的，上述內(nèi)容就足夠了。 這些幾何元素也可以使用普通CSS設(shè)置樣式。

尋找一座橋 (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:

這些是現(xiàn)代Web應(yīng)用程序開發(fā)和圖表庫(kù)開發(fā)背后的指導(dǎo)原則。 讓我們嘗試隔離開發(fā)圖表庫(kù)和Web應(yīng)用程序的地方：

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

  Web應(yīng)用程序由DOM節(jié)點(diǎn)組成。 圖表由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應(yīng)用程序可以細(xì)分為DOM的可重用部分，這些部分可以建模為組件。 圖表未建模為可重復(fù)使用的一組幾何圖形。

• 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應(yīng)用程序框架始終與模板引擎結(jié)合使用，以便可以在標(biāo)記中對(duì)DOM結(jié)構(gòu)進(jìn)行建模，并可以將行為與標(biāo)記分離并用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應(yīng)用程序框架允許通過(guò)使用插件來(lái)合并狀態(tài)存儲(chǔ)。 圖表通常建模為有狀態(tài)的組件。

重塑圖表復(fù)雜度 (Remodelling chart complexity)

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

圖表是一種可視化工具，可顯示使用幾何圖形的數(shù)據(jù)中各個(gè)字段的變化。

So how does that work?

那如何運(yùn)作？

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

查看上圖，我們看到了什么？ 根據(jù)數(shù)據(jù)中存在的字段，視口中的圓偏移。

What else?

還有什么？

• Ticks offset along the bottom based on a field in the data.
  刻度線根據(jù)數(shù)據(jù)中的字段沿底部偏移。
• Text labels offset along the bottom based on a field in the data.
  文本標(biāo)簽基于數(shù)據(jù)中的字段沿底部偏移。
• Same as above along the left side of the chart.
  與圖表左側(cè)的上方相同。

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

讓我們將其分解為幾何級(jí)別。

How do we render the circles in the scatterplot?

我們?nèi)绾卧谏Ⅻc(diǎn)圖中繪制圓圈？

<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結(jié)構(gòu)，除了比例函數(shù)發(fā)生變化并且x，y字段被反轉(zhuǎn)。

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名稱空間中的每個(gè)幾何都公開了視覺屬性
• the value of these attributes is bound to a calculated value
  這些屬性的值綁定到計(jì)算值
• the calculated value depends on the scale
  計(jì)算值取決于比例尺
• the scale depends on a field in the data and the range
  小數(shù)位數(shù)取決于數(shù)據(jù)中的字段和范圍

規(guī)模是多少？ (What is a scale?)

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

比例尺是一種將數(shù)據(jù)映射到視口中某個(gè)位置的功能。

What is the input to scale?

規(guī)模輸入是什么？

• the domain of the field
  領(lǐng)域的領(lǐng)域
• the length of the viewport to map to
  要映射到的視口的長(zhǎng)度

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

設(shè)R為視口長(zhǎng)度， D為數(shù)據(jù)域。

• Then we can define a scaling function S as:

  然后我們可以將縮放函數(shù)S定義為：

• S = f(D, R) + b

  S = f(D，R)+ b

where b is a constant.

其中b是常數(shù)。

圖表需要多少個(gè)刻度？ (How many scales does a chart need to have?)

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

如果您想兩個(gè)，那就錯(cuò)了。

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軸存在。 軸本身僅在圖表中顯示為可視錨點(diǎn)，以便用戶可以沿多個(gè)維度排列數(shù)據(jù)變化。

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

軸只是使用比例尺渲染的幾何。

有多少個(gè)尺寸？ (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.

不是兩個(gè) 視口是二維的，但與圖表的尺寸無(wú)關(guān)。 圖表的維數(shù)由使用的縮放功能的數(shù)量定義。

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

總體概念由兩個(gè)簡(jiǎn)單術(shù)語(yǔ)組成： 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.

這些屬性的值可以連接到縮放函數(shù)。 縮放功能與數(shù)據(jù)中的特定字段相關(guān)。

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

這使自己的想法是，圖表中的每個(gè)視覺屬性只能與數(shù)據(jù)表中的一個(gè)字段相關(guān)聯(lián)。

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

鑒于圖表的分解，我們可以如下對(duì)散點(diǎn)圖進(jìn)行建模：

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

字段Horsepower用于創(chuàng)建稱為horsepowerScale()的縮放函數(shù)。

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

字段Acceleration用于創(chuàng)建一個(gè)稱為accelerationScale()的縮放函數(shù)。

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

由于我們沒有改變圓的大小，因此僅需要兩個(gè)縮放函數(shù)。

Any circle i in the scatterplot can be represented as

散點(diǎn)圖中的任何圓圈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是數(shù)據(jù)表中的第i個(gè)元組。

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

假設(shè)僅使用了兩個(gè)縮放函數(shù)，則上圖的維數(shù)將變?yōu)?。

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

如果我們還使用綁定到另一個(gè)字段的縮放函數(shù)來(lái)調(diào)制每個(gè)圓的大小，則維數(shù)將為3。

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

這樣做將導(dǎo)致所謂的“氣泡圖”。

圖形語(yǔ)法 (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.

這類似于圖形語(yǔ)法(GOG)的方法，在該方法中，每個(gè)圖表都由一個(gè)標(biāo)記(幾何形狀)和該標(biāo)記使用的可視編碼定義。

In a GOG approach the scatterplot would be represented as:

在GOG方法中，散點(diǎn)圖將表示為：

{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.

請(qǐng)注意，GOG幾何的編碼與SVG中的幾何公開的視覺屬性之間存在一對(duì)一的映射 。

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偏移設(shè)置為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設(shè)置為0。

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

要渲染散點(diǎn)圖及其所有元素，以下代碼片段就足夠了：

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

將圖表分解為視覺屬性和縮放功能之間的關(guān)聯(lián)，使我們可以將圖表作為Web應(yīng)用程序查看。

Web Application frameworks model UI as a function of state.

Web應(yīng)用程序框架將UI建模為狀態(tài)的函數(shù)。

Charts Frameworks should model geometry as a function of scale.

圖表框架應(yīng)將幾何建模為比例函數(shù)。

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

因此，使Web應(yīng)用程序易于開發(fā)的想法可以輕松地?cái)U(kuò)展到創(chuàng)建圖表：

• Initially, tabular data is supplied as input.
  最初，提供表格數(shù)據(jù)作為輸入。
• 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.
  對(duì)于數(shù)據(jù)數(shù)組中的每個(gè)字段，都會(huì)創(chuàng)建一個(gè)縮放函數(shù)。 當(dāng)列中的字段與更改綁定在一起時(shí)，縮放功能有選擇地重新計(jì)算值。 整個(gè)應(yīng)用程序都滲透了相同的縮放功能。
• Every geometry is modelled as a component that exposes visual attributes.
  每個(gè)幾何圖形都被建模為公開視覺屬性的組件。
• The value of these visual attributes is tied to a scaling function that reacts to changes in data.
  這些視覺屬性的值與對(duì)數(shù)據(jù)變化做出React的縮放函數(shù)相關(guān)。
• 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，胡須或車把)在標(biāo)記中表示幾何圖形的集合。 理想情況下，應(yīng)將模板引擎作為插件引入，這樣我們就可以避免為React和Angular等不同庫(kù)編寫綁定。
• The state store that selectively computes scales should also be introduced as a plugin.
  選擇性計(jì)算比例的狀態(tài)存儲(chǔ)也應(yīng)作為插件引入。

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作為狀態(tài)存儲(chǔ)。

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

上面的方法只是對(duì)可以將圖表建模為Web應(yīng)用程序的框架想要的框架的粗略實(shí)現(xiàn)。

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

注意，模板引擎和狀態(tài)存儲(chǔ)與實(shí)際渲染邏輯是分開的。

最后一點(diǎn) (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.

理想情況下，我們創(chuàng)建的幾何圖形/圖表應(yīng)隨用戶的狀態(tài)存儲(chǔ)一起作為用戶選擇的框架中的組件提供。 如果似乎無(wú)法做到這樣的事情，請(qǐng)保持冷靜。 之前已經(jīng)完成了。

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

SkateJS是可創(chuàng)建Web組件但允許用戶切換內(nèi)部渲染引擎的編譯器。

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之間進(jìn)行選擇，或擴(kuò)展Renderer界面以編寫自己的界面。 默認(rèn)渲染器僅直接更改DOM。

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

一旦擁有同步渲染和狀態(tài)管理功能，我們就可以對(duì)選擇的東西更加抱負(fù)。

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.

想象一下一個(gè)TickProvider組件， TickProvider允許在給定的動(dòng)畫幀中渲染幾何的小簇，并且允許我們識(shí)別渲染管道中的瓶頸。

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

鑒于圖表是幾何的有意義的排列方式，因此有意義的幾何簇應(yīng)一起呈現(xiàn)。

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.

在散點(diǎn)圖示例中，對(duì)于渲染的每組圓，x / y軸幾何的相應(yīng)部分也應(yīng)同時(shí)渲染。

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.

如果將渲染分成多個(gè)塊，每個(gè)塊都由一個(gè)有意義的幾何簇組成(如上模型所示)，則我們可以支持漂亮的過(guò)渡效果，從而增加圖表的視覺吸引力。

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另一個(gè)優(yōu)點(diǎn)是我們可以剖析并確保每個(gè)幾何TickProvider在每個(gè)刻度分配的時(shí)間內(nèi)完全呈現(xiàn)。 當(dāng)要渲染的幾何圖形數(shù)量很大時(shí)，這將有助于避免凍結(jié)UI。 無(wú)需在整個(gè)幾何圖形集合上運(yùn)行渲染循環(huán)，我們可以與動(dòng)畫幀同步批處理渲染調(diào)用。

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

我們還可以分解視覺屬性值的計(jì)算。

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

考慮具有上述方法的具有N個(gè)字段的數(shù)據(jù)表用于呈現(xià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.

由于我們使用的是集中式狀態(tài)存儲(chǔ)，因此我們可以計(jì)算N縮放函數(shù)的值并將其存儲(chǔ)起來(lái)。 僅在關(guān)聯(lián)的數(shù)據(jù)表字段更改時(shí)才需要重新計(jì)算它們。

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

此外，請(qǐng)考慮以下方程式，該方程式基于縮放函數(shù)計(jì)算m個(gè)視覺屬性的值。

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

可視屬性V的第0個(gè)值(綁定到N的字段0)可以如下計(jì)算：

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

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

• where d0 is the 0th data tuple from the data table
  其中d0是數(shù)據(jù)表中的第0個(gè)數(shù)據(jù)元組
• R is the range supplied as a prop to the component
  R是作為道具提供的范圍
• b0 is constant
  b0是常數(shù)

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.

比例函數(shù)本身可以表示為線性方程。 我們有一組線性方程式，可以批量計(jì)算以計(jì)算視覺屬性的值。

How so?

為何如此？

The above arrangement looks suspiciously like a matrix.

上述安排可疑地看起來(lái)像一個(gè)矩陣。

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

瀏覽器中的計(jì)算速度很慢，但是可以利用GPU加速來(lái)加快矩陣計(jì)算的速度。

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.

因此，將圖表建模為幾何圖形與比例的函數(shù)可以幫助我們更快地繪制圖表，并通過(guò)快速的首次渲染處理大量數(shù)據(jù)。

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.

數(shù)據(jù)可視化可以幫助我們從大量數(shù)據(jù)中收集見解。 它對(duì)決策的影響正在逐步與多家尋求數(shù)據(jù)驅(qū)動(dòng)決策的組織密切相關(guān)。

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

可以肯定地說(shuō)，我們需要一種更強(qiáng)大，可訪問(wèn)和可維護(hù)的可視化開發(fā)方式。

What do you think?

你怎么看？

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

orcale可視化建立用戶

總結(jié)

以上是生活随笔為你收集整理的orcale可视化建立用户_建立动态可视化的新方法的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。