COMMENCER ICI
Premiers pas
ARCHITECTURE
Vue d'ensemble de l'architecture
Composants write-once
Surface déclarative
Architecture des paquets
Composants
Styles
Localisation
Analytics et GTM
WRITE-ONCE
Stockage
Formulaires
Markdown
Mermaid
Rendu des e-mails
COMPILATION
Résolution des types externes
RUNTIME
Runtime (TypeScript)
Performance
SERVEUR
Assets
BunPackage
Sécurité
ÉCOSYSTÈME
Image
Graphiques
Lottie
DÉVELOPPEMENT
Roadmap
DocsÉcosystème
GraphiquesEdit this page
6 min readUn graphique dans eQuantic.UI est UN composant écrit en C#. Le même BarChart se rend sur le web (côté serveur et dans le navigateur) et sur Photon (bureau et mobile), depuis le même code, dans les couleurs que le thème réserve aux données. La bibliothèque est eQuantic.UI.Charts, et le SDK la met à portée dans chaque projet comme il le fait pour eQuantic.UI.Components : il n'y a rien à installer et aucun using à écrire.
Depuis 0.2.0-preview.50
Le graphique en barres
1
2
3
4
5
6
7
8
9
10
11
BarChart(
title: "Revenue by quarter",
subtitle: "Three regions, side by side",
series:
[
ChartSeries("Europe", [120_000, 138_500, 149_200, 171_000]),
ChartSeries("Americas", [98_400, 104_900, 99_700, 132_300]),
ChartSeries("Asia", [61_200, 72_800, 88_100, 95_500]),
],
categories: CategoryAxis(["Q1", "Q2", "Q3", "Q4"]),
values: ValueAxis(format: "C0", title: "Revenue"))
Les factories sont la surface déclarative : chacune porte le nom de son type et reflète son constructeur paramètre pour paramètre (BarChart, ChartSeries, CategoryAxis, ValueAxis), si bien qu'un tableau de bord se lit sans un seul new.
Trois dispositions, un composant :
vous voulez
vous écrivez
des groupes côte à côte (le défaut)
layout: BarLayout.Grouped
une série au-dessus d'une autre
layout: BarLayout.Stacked
des barres qui courent de gauche à droite, pour de longs noms de catégories
orientation: ChartOrientation.Horizontal
plotHeight fixe la hauteur du tracé seul ; la largeur est celle qu'on donne au graphique, et les barres la remplissent.
Ce que chaque graphique apporte sans qu'on le demande :
•
Une légende quand il y a plus d'une série. Presser une entrée isole cette série ; la presser à nouveau ramène les autres. Une seule série n'affiche pas de légende, parce que le titre la nomme déjà.
•
Une infobulle qui suit le pointeur et nomme la catégorie, la série et la valeur.
•
Une vue en tableau. Le Voir en tableau du pied échange le tracé contre un DataTable des mêmes nombres, et Voir en graphique le rend : les mêmes données pour un lecteur d'écran, un clavier, ou qui veut les chiffres.
•
Des libellés d'axes issus de vos données : les catégories sous (ou à côté de) le tracé, les valeurs sur des graduations propres. ValueAxis(format: "C0") formate chaque libellé de valeur et chaque cellule du tableau avec une format string .NET dans la culture courante : le même "C0" imprime €120,000 à une requête et R$ 120.000 à la suivante. min, max et ticks fixent l'axe quand vous préférez qu'il ne suive pas les données.
•
Un nom accessible : le canvas porte le titre du graphique, donc le tracé est annoncé pour ce qu'il est.
La couleur vient du thème
Un graphique n'énonce jamais une couleur. IAppTheme.Data est une DataPalette avec huit emplacements de séries, des rampes séquentielle et divergente, et quatre paliers d'état, auditée pour le contraste et pour les déficiences de la vision des couleurs : la palette par défaut est livrée auditée, et la vôtre peut être vérifiée de la même façon avec PaletteAudit. Les règles tiennent par construction plutôt que par conseil :
•
La première série porte l'emplacement 0, la deuxième l'emplacement 1, et ainsi de suite ; ChartSeries("Forecast", values, slot: 3) fixe une série à un emplacement pour qu'elle garde sa couleur d'un graphique à l'autre.
•
Une neuvième série lève au build. Huit couleurs distinguables, c'est là que l'audit s'arrête ; un graphique avec plus de séries est un tableau.
•
Les couleurs d'état sont réservées à l'état. Une série qui SIGNIFIE bon ou mauvais porte un état ; "la série 4" jamais.
•
Le texte ne porte jamais une couleur de données : les libellés, les entrées de légende et les infobulles se lisent dans les tokens de texte du thème, et l'échantillon à côté porte la couleur.
Rebrander les couleurs de données consiste à fournir votre propre Data sur votre thème, exactement comme vous fournissez Primary.
Comment cela se rend
Le chrome du graphique (titre, sous-titre, légende, libellés d'axes, le tableau, le pied) est fait de nœuds ordinaires (Text, Row, Column, DataTable), il se met donc en page, enveloppe, se thème et parle aux technologies d'assistance comme le reste de votre écran. Les marques sont un Canvas peint avec les formes propres au moteur : des rectangles arrondis sur le SVG du web, les mêmes rectangles sur le GPU de Photon.
Sur le web le chrome est rendu côté serveur comme le reste de votre page, et les marques sont dessinées au moment où le tracé a été mesuré : un canvas qui remplit sa boîte n'a pas de taille avant que le CSS ne l'ait mis en page, donc le serveur émet le cadre et le navigateur peint dedans.
La géométrie est résolue une fois, dans BarChartLayout : du C# sur le serveur et sur Photon, son jumeau transpilé dans le navigateur. Une fixture épinglée, résolue par les deux compilations, est comparée ligne pour ligne dans les suites de tests, donc une barre que les deux placeraient à un dixième de dp d'écart fait échouer le build. Les valeurs des graduations s'ajustent à 1, 2, 5 et 10 par multiplication plutôt que par logarithmes pour la même raison : les deux runtimes doivent s'accorder sur chaque graduation.
Ce qui arrive
Le graphique en barres est la première tranche d'un plan qui atteint les types de graphiques que couvraient les wrappers ci-dessous : ligne, aire et sparklines avec un axe de temps ; camembert, anneau, jauge, carte de chaleur et nuage de points ; radar et chandeliers, annotations, animation et export via une capacité. Le plan vit dans le dépôt sous docs/CHARTS-PLAN.md, avec ce que chaque tranche livre et ce qui est délimité à dessein (les doubles axes, la 3D et les entonnoirs entre autres).
Wrappers, pour la transition
Deux wrappers uniquement web autour de bibliothèques JavaScript précèdent la bibliothèque native et restent disponibles jusqu'à ce qu'elle couvre leurs types de graphiques, moment où ils sont retirés :
•
eQuantic.UI.Charts.ChartJs, Chart.js sur canvas HTML5 : bar, line, pie, doughnut, radar.
•
eQuantic.UI.Charts.ApexCharts, ApexCharts sur SVG : area, bar, line, heatmap, candlestick.
Ce sont des paquets opt-in, uniquement web (ils ne rendent rien sur Photon), et ils prennent la configuration propre à la bibliothèque sous forme de classes C# qui reflètent son API JavaScript :
1
dotnet add package eQuantic.UI.Charts.ApexCharts
1
2
3
4
5
builder.Services.AddUI(options =>
{
options.UseApexCharts() // ou UseChartJs() ; chacun sert les scripts de sa bibliothèque
.ScanAssembly(typeof(Program).Assembly);
});
1
2
3
4
5
new ApexChart<MyData>
{
Options = new ApexOptions { Chart = new ChartConfig { Type = "bar" } },
Series = [new ApexSeries<MyData> { Name = "Sales", Data = dataList }],
}
Leurs scripts sont déclarés par le système d'assets et injectés là où une page les utilise ; rien n'est ajouté à la main. Une page qui n'a besoin que d'un graphique en barres devrait utiliser le BarChart ci-dessus : il se rend sur chaque cible, et c'est celui qui reste.