Ersetzen oder Behalten: Wie DataLens von Highcharts migrierte

Hallo, mein Name ist Evgeny Alayev, ich bin Interface-Entwickler im Team von Yandex DataLens. Das ist ein cloudbasiertes BI-Tool zur Datenanalyse und Erstellung von Dashboards — und Diagramme darin sind nicht “eines der Features”, sondern das Herzstück des Produkts. Der Nutzer öffnet ein Dashboard und das Erste, was er sieht, sind Visualisierungen. Genau sie beantworten die Frage: “Was passiert mit meinen Daten?”

DataLens läuft in zwei Installationen — für Yandex selbst und für externe Nutzer. Insgesamt wurden bisher mehr als 18,3 Millionen Diagramme erstellt. Jedes dieser Diagramme ist das Ergebnis der Arbeit genau jener Visualisierungsbibliothek, über die es in diesem Artikel gehen wird.

Lange Zeit wurden Diagramme in DataLens mit Highcharts erstellt. Zunächst war das eine vernünftige Wahl: schneller Einstieg, umfangreicher Typenumfang, große Community. Aber ein BI-Tool wird mit der Zeit komplexer — es entstehen nicht-standardmäßige Anforderungen an das Verhalten, ein Design-System, das in einem einheitlichen Stil gehalten werden muss. Und irgendwann fing Highcharts an, mehr zu behindern als zu helfen.

In diesem Artikel erkläre ich, wie und warum wir die Entscheidung getroffen haben, eine eigene Open-Source-Bibliothek für Visualisierungen zu entwickeln — @gravity‑ui/charts. Mein Kollege und ich sind Core-Contributor dieser Bibliothek, daher werde ich ausführlich berichten, was uns an Highcharts nicht gefiel, welche Alternativen wir in Betracht zogen, wie die Architektur aufgebaut ist und mit welchen konkreten technischen Herausforderungen wir dabei konfrontiert wurden.

Von der Bequemlichkeit zu den Grenzen

Lizenz und Vendor-Lock

Highcharts ist eine kommerzielle Bibliothek. Für nicht-kommerzielle Nutzung ist sie kostenlos, aber sobald ein Produkt monetarisiert wird, wird eine Lizenz benötigt. Das ist an sich kein Problem — viele Teams arbeiten mit kostenpflichtigen Tools. Das Problem beginnt dort, wo das Nutzungsmodell komplexer wird.

DataLens hat drei Vertriebsformate: Cloud, Open Source und On-Premises. Eine nicht-freie Lizenz in den Abhängigkeiten — auch eine optionale — erschwert für uns die Auslieferung jedes einzelnen davon.

Neben der Lizenz besteht eine starke Abhängigkeit von der fremden Roadmap. Du willst einen neuen Diagrammtyp? Warte, bis ihn der Anbieter implementiert. Du hast einen Bug im Tooltip-Verhalten gefunden? Erstelle ein Ticket und hoffe, dass es Priorität bekommt. Du brauchst ein nicht-standardmäßiges Verhalten beim Klick auf die Legende? Suche nach Workarounds in der Dokumentation oder auf Stack Overflow. Wenn sich ein Produkt aktiv weiterentwickelt und die Anforderungen an die Visualisierung nicht trivial sind, fängt eine solche Abhängigkeit an zu bremsen.

Eine eigene Geschichte sind Major-Updates. Wir nutzten die letzte Version von Highcharts im Rahmen des achten Majors. Der Wechsel zum nächsten Major erschien für sich genommen schon teuer, aber besonders schwierig machte ihn eine Besonderheit von DataLens: Wir haben einen Editor — einen Modus, in dem Nutzer JavaScript-Code zur Konfiguration des Diagramms schreiben. Faktisch arbeiten sie direkt mit Highcharts, indem sie die Konfiguration über Code erstellen. Solchen Nutzercode lässt sich nicht automatisch migrieren: Es ist unmöglich, einen Codemod zu schreiben, der beliebiges JS sicher von einem Interface auf ein anderes überträgt.

Kontrolle über das Verhalten

In einem BI-Tool interagieren Nutzer aktiv mit Diagrammen: Sie klicken auf die Legende, um eine Reihe auszublenden, hovern über Datenpunkten und fixieren Tooltips. Jedes dieser Szenarien erforderte in Highcharts eine Feinabstimmung über Callbacks und Events — wobei diese nicht immer dokumentiert und nicht immer stabil zwischen Versionen waren.

Hier sind einige typische Beispiele:

• Tooltip-Fixierung. Der Standard-Tooltip von Highcharts verschwindet beim Verlassen der Maus. Nativ unterstützter 'haftender' Tooltip war im 8. Major nicht vorhanden — er erschien erst in Version 12. Wir implementierten dies über das Überschreiben interner Methoden: Wir fingen Mausereignisse ab und ersetzten die Ausblende-Logik. Der Code funktionierte, war aber fragil.

• Benutzerdefiniertes Tooltip-Rendering. Der Formatter gibt einen HTML-String zurück, was die manuelle Zusammensetzung des Markups durch String-Konkatenation bedeutet. Kein React, keine Komponenten. Am Ende wurde das Tooltip-Rendering zu einer eigenen Schicht mit eigener Template-Logik.

• Klick auf die Legende. Das Standardverhalten schaltet die Sichtbarkeit einer Reihe um. Es vollständig zu überschreiben, ohne den Rest zu beschädigen, ist nicht trivial: Der Handler musste über interne Events gehängt und das Standard-Verhalten sorgfältig deaktiviert werden.

• Themisierung. Farben, Schriften und Abstände in Highcharts werden über JavaScript-Konfiguration gesetzt und als Inline-Styles angewendet. Darüber hinaus pflegten wir eine separate SCSS-Datei zum Überschreiben der Basisstile, die bei jeder Aktualisierung der Palette in Gravity UI manuell synchronisiert werden musste.

Jeder solche Umweg ist kein isoliertes Problem, sondern ein Beitrag zur allgemeinen technischen Schuld. Ein Hack lebt für sich, zwei kann man im Kopf behalten, aber ab dem zehnten beginnen sie zu interagieren: Man repariert eine Stelle und eine andere bricht. Die Wartungskomplexität wächst nichtlinear, und jedes Highcharts-Update wird zur Prüfung: Was von unseren Workarounds ist diesmal still kaputt gegangen.

Bewertung von Alternativen

Bevor wir etwas Eigenes entwickelten, haben wir ehrlich die bestehenden Lösungen durchgegangen. Die Hauptkriterien waren:

• Offene Lizenz — MIT oder kompatibel, keine kostenpflichtigen Tiers und OEM-Vereinbarungen.

• Vollständige Anpassung von Rendering und Stilen — die Möglichkeit, das Erscheinungsbild jedes Elements ohne Umwege zu steuern.

• HTML-Einbettung — Tooltip, Beschriftungen im Diagramm und Achsenbeschriftungen müssen als vollwertiges HTML gerendert werden, nicht als SVG-Text oder String-Templates.

Wir schauten uns ECharts, Recharts, Plotly, Chart.js und D3 an.

Chart.js und Plotly fielen schnell weg: Das standardmäßige Canvas-Rendering schließt die Möglichkeiten der CSS-Stilanpassung aus, und das Einbetten von beliebigem HTML in Diagrammelemente ist dort nicht vorgesehen.

Recharts — React-first, SVG, MIT. Gut geeignet für einfache Dashboards, aber tiefgreifende Anpassung von Formen und Verhalten stößt schnell an die Grenzen der internen API.

ECharts war die vielversprechendste Option: umfangreicher Typenumfang, flexible Konfiguration, Unterstützung für benutzerdefinierte Renderer. Bei näherer Betrachtung deckte es jedoch eines der Schlüsselkriterien nicht ab: die vollständige HTML-Einbettung in beliebige Teile des Diagramms. Für unsere Anwendungsfälle war das entscheidend. Dazu kam — der Vendor-Lock verschwand nirgends: Die MIT-Lizenz löste die rechtliche Frage, aber die Abhängigkeit von der fremden Roadmap und dem Update-Zyklus blieb.

D3 — das ist keine Diagrammbibliothek, sondern ein Satz von Primitiven: Skalen, Formgeneratoren, Datentransformationen. Löst das Problem nicht für sich allein, liefert aber das ideale Fundament, um eine eigene Lösung darauf aufzubauen.

Die Schlussfolgerung war logisch: D3 als Basis zu nehmen und darüber eine eigene Bibliothek zu entwickeln — das gab uns sowohl Freiheit als auch Kontrolle und beseitigte die Abhängigkeit von jedwedem Anbieter vollständig.

Architektur von @gravity‑ui/charts

Einstiegspunkt — das Konfigurationsobjekt

Der Nutzer übergibt dem Komponenten ein einziges Objekt mit Daten und Einstellungen: Reihen, Achsen, Titel, Legende, Tooltip. Das ist eine bewusste Entscheidung zugunsten des deklarativen Ansatzes — der größte Teil der Konfiguration lässt sich einfach serialisieren, loggen und zwischen Systemen übertragen.

Wo eine deklarative Beschreibung nicht ausreicht, akzeptiert die Konfiguration Funktionen: einen benutzerdefinierten Tooltip-Renderer, Click-Handler, Achsenbeschriftungsformatter. Das ist kein Widerspruch, sondern eine bewusste Grenze — die Datenstruktur bleibt vorhersehbar und die Erweiterungspunkte explizit.

Datenfluss

Innerhalb der Bibliothek durchläuft die Konfiguration mehrere Verarbeitungsstufen:

• Normalisierung. Die Eingabedaten werden in ein einheitliches internes Format gebracht. In dieser Phase werden Standardwerte gesetzt, Mehrdeutigkeiten aufgelöst und die Daten jeder Reihe typisiert.

• Reihenvorbereitung. Jeder Diagrammtyp (Linie, Bar, Pie usw.) wird von seinem eigenen Modul verarbeitet. Farben werden zugewiesen, Metadaten für die Legende erstellt.

• Aufbau von Skalen und Achsen. Auf Basis der Daten erstellt D3 Skalen: lineare, logarithmische, zeitbasierte, kategoriale. Skalen legen fest, wie Werte aus den Daten in Pixelkoordinaten umgewandelt werden.

• Rendering der Formen. Jeder Reihentyp zeichnet seine SVG-Elemente: Linien, Rechtecke, Bögen, Punkte. D3 liefert die Formgeneratoren, React verwaltet den Lebenszyklus der Elemente.

SVG + HTML: hybrides Rendering

Das primäre Rendering ist SVG. Das ermöglicht klare Grenzen, verlustfreie Skalierung und vollständige Kontrolle über die Positionierung.

Aber SVG kann keinen Text umbrechen und unterstützt kein reichhaltiges HTML innerhalb von Elementen. Für Data Labels mit Umbrüchen, benutzerdefinierte Tooltips und interaktive Elemente über dem Diagramm wird eine separate HTML-Schicht verwendet — ein absolut positioniertes Div, das über das SVG gelegt und mit dessen Koordinaten synchronisiert wird.

Ereignissystem

Nutzerinteraktionen mit dem Diagramm — Hover, Klick, Mausbewegung — werden über einen zentralisierten Ereignisbus auf Basis von d3.dispatch verarbeitet. Das ermöglicht es verschiedenen Teilen der Oberfläche (Tooltip, Crosshair, Legende), unabhängig und konsistent auf dasselbe Ereignis zu reagieren, ohne direkte Abhängigkeiten zwischen Komponenten.

Aber dieser Ansatz hat noch eine weitere wichtige Konsequenz — die Performance. Mausbewegungen über dem Diagramm erzeugen Ereignisse mit hoher Frequenz. Wenn bei jedem solchen Ereignis ein React-Render ausgelöst wird, führt das zu kostspieligen Neuberechnungen des gesamten Komponentenbaums. Stattdessen werden einige Aktualisierungen — z. B. das Hovern über Formen, die Suche nach dem nächstgelegenen Punkt zur Mausposition — direkt über D3 angewendet, ohne React zu durchlaufen. Die Komponente wird nicht neu gerendert: D3 aktualisiert einfach die notwendigen DOM-Attribute. React kommt nur dort ins Spiel, wo es wirklich notwendig ist — bei Änderungen der Struktur oder des Zustands, die den gesamten Graphen beeinflussen.

Migration ohne Produktstopp

Der Weg der Daten von der Quelle zum Diagramm

Bevor wir über den Wechsel der Bibliothek sprechen, ist es wichtig zu verstehen, wie das Diagramm-Rendering in DataLens grundsätzlich aufgebaut ist — denn genau diese Architektur hat bestimmt, wie wir migrieren konnten.

Wenn ein Nutzer ein Chart öffnet (oder dieses Chart auf einem Dashboard gerendert wird), geht eine Anfrage an unser Node.js-Backend für die Daten. Das Node.js-Backend seinerseits ruft unseren Python-Service für die Rohdaten ab. Aber Daten allein sind noch kein Diagramm. In Node findet die Vorbereitung statt: Der Visualisierungstyp wird bestimmt, geprüft, ob die Datenlimits für diesen Typ überschritten wurden, und wenn alles in Ordnung ist — wird die Datenvorbereitungsfunktion ausgewählt, die spezifisch für den jeweiligen Diagrammtyp ist.

Der entscheidende Punkt: Jeder Visualisierungstyp hat seine eigene Datenvorbereitungsfunktion. Für ein Liniendiagramm eine, für ein Balkendiagramm eine andere, für Area eine dritte. Das Ergebnis dieser Funktion ist die Konfiguration, die an den Client gesendet wird. Dort gelangt sie nicht direkt in @gravity‑ui/charts, sondern in @gravity‑ui/chartkit — ein separates Paket, das wir verwenden, um mit mehreren Visualisierungsbibliotheken gleichzeitig zu arbeiten. Es lädt dynamisch nur die Bibliothek, die für den jeweiligen Chart-Typ benötigt wird, und stellt für alle ein einheitliches Interface bereit — der Client-Code weiß nicht und muss nicht wissen, welche Bibliothek genau einen bestimmten Typ rendert.

Neben dem Routing enthält chartkit Wrapper über die eigentlichen Bibliotheken: Logik, die nicht in den Rahmen einer bestimmten Bibliothek passt, in DataLens aber benötigt wird. Zum Beispiel ist das Anzeigen eines Tooltips durch Tippen auf einem Mobilgerät — dieses Verhalten wird sowohl für Highcharts als auch für @gravity‑ui/charts benötigt, daher ist es auf der Ebene von chartkit implementiert.

Solche Dinge sind potenziell nicht nur für DataLens nützlich. Daher verdient eine ausführliche Beschreibung von @gravity‑ui/chartkit einen eigenen Artikel.

Strategie des schrittweisen Übergangs

Diese Architektur gab uns die Möglichkeit, schrittweise zu migrieren, ohne alles auf einmal neu zu schreiben.

Wir führten Feature-Flags auf der Ebene des Visualisierungstyps ein. Die Logik ist einfach: Wenn das Flag für eine bestimmte Visualisierung auf true gesetzt ist — bereitet Node die Daten im Format von @gravity‑ui/charts vor und der Client verwendet die neue Bibliothek. Wenn das Flag nicht gesetzt ist — werden die Daten im Highcharts-Format vorbereitet und der alte Code wird gerendert.

Das bedeutete, dass zu einem bestimmten Zeitpunkt in DataLens beide Bibliotheken gleichzeitig liefen — jede für ihre eigene Gruppe von Diagrammtypen. Dieser Ansatz brachte mehrere Vorteile:

• Isoliertes Risiko. Ein Bug in der neuen Implementierung des Balkendiagramms berührt die Säulendiagramme nicht, die noch auf Highcharts laufen.

• Schrittweise Überprüfung. Jeder Typ durchläuft nach dem Wechsel eine Beobachtungsphase in der Produktion, bevor der nächste migriert.

• Rollback-Möglichkeit. Wenn etwas schiefläuft, reicht es, das Flag auszuschalten.

Die Migration verlief in drei Wellen, und die Reihenfolge war bewusst gewählt — vom Einfachen zum Komplexen.

Welle 1: Pie und Treemap. Der logischste Start — Visualisierungen ohne Achsen. Keine Skalen, kein Crosshair, kein komplexes Koordinatensystem. Das ermöglichte es, die Basisintegration auszuprobieren, die Datenvorbereitung-Pipeline einzurichten und sicherzustellen, dass die Migrationsinfrastruktur korrekt funktioniert, ohne die am stärksten belasteten Typen zu riskieren.

Welle 2: Bar-Y, Bar-Y normalisiert, Scatter. Der nächste Schritt — Diagramme mit Achsen, aber mit einer wichtigen Einschränkung: Diese Typen werden nicht im Split-Modus verwendet (wenn mehrere Diagramme untereinander mit gemeinsamer X-Achse angeordnet werden) und nehmen nicht an kombinierten Diagrammen teil. Das reduzierte die Anzahl der Randfälle erheblich und machte den Übergang vorhersehbar.

Welle 3: Area, Area normalisiert, Bar-X, Bar-X normalisiert, Line und ihre Kombinationen. Die komplexeste Phase. Genau diese Typen sind die beliebtesten in DataLens: Sie werden auf den meisten Dashboards verwendet.

Außerdem kommen hier kombinierte Diagramme hinzu (z. B. Line + Bar-X auf einem Graphen), der Split-Modus und alle nicht-trivialen Interaktionsszenarien. Jede dieser Visualisierungen erforderte besondere Aufmerksamkeit beim Testen, und die Feature-Flags gaben die Möglichkeit zum Rollback, falls etwas in der Produktion schiefging.

Technische Lösungen

Konfigurationsobjekt: vertraut, aber besser. Wir haben bewusst das Konfigurationsobjekt als Methode zur Beschreibung eines Diagramms gewählt. DataLens arbeitete bereits mit diesem Ansatz, und ein abrupter Paradigmenwechsel hätte eine unnötige Hürde geschaffen. Die Struktur der Konfiguration ist in vielem dem vertraut, woran Entwickler gewöhnt sind: Reihen, Achsen, Titel, Tooltip — alles an seinem Platz. Aber wo uns das Highcharts-Interface unglücklich erschien, haben wir eigene Entscheidungen getroffen. Nicht aus Originalitätsdrang, sondern weil wir konkrete Probleme oder Unannehmlichkeiten im realen Einsatz erkannt haben.

Ein minimales Beispiel — ein Liniendiagramm mit Zeitachse:

import {Chart} from '@gravity-ui/charts';

<Chart
    data={{
        series: {
            data: [
                {
                    type: 'line',
                    name: 'Umsatz',
                    data: [
                        {x: new Date('2024-01-01').getTime(), y: 120},
                        {x: new Date('2024-02-01').getTime(), y: 145},
                        {x: new Date('2024-03-01').getTime(), y: 132},
                        {x: new Date('2024-04-01').getTime(), y: 178},
                    ],
                },
            ],
        },
        xAxis: {type: 'datetime'},
        yAxis: [{title: {text: 'Tsd. EUR'}}],
    }}
/>

Das Ergebnis sieht so aus:

Aber man kann auch ein komplexeres Liniendiagramm erstellen:

Vernünftige Standardwerte und Anpassung dort, wo nötig. Nach Jahren der Entwicklung eines BI-Tools haben wir ein Verständnis dafür entwickelt, wie sich eine Diagrammbibliothek in einem solchen Produkt verhalten sollte. Typische Szenarien sollten out-of-the-box funktionieren — ohne Konfiguration und ohne Überraschungen. Wo Standardwerte nicht ausreichen, gibt es explizite Anpassungspunkte: eigene React-Komponente als Tooltip-Renderer übergeben, den Achsenbeschriftungsformatter überschreiben, die Linienbreite festlegen. All das — über dasselbe Konfigurationsobjekt, ohne in die Interna der Bibliothek einzugreifen.

Native Integration mit Gravity UI. DataLens basiert auf Gravity UI — einem Design-System mit Komponenten, Icons und CSS-Themisierung. Die Themisierung funktioniert über CSS-Variablen von @gravity‑ui/uikit: Man verbindet ein Theme — und alle Farben der Achsen, Gitter und Beschriftungen passen sich automatisch dem hellen oder dunklen Modus an. Tooltip und Buttons in der Diagrammoberfläche sind Standard-uikit-Komponenten, die Barrierefreiheit, Tastaturnavigation und Ereignisverarbeitung aus dem Design-System erben.

Skalierung ohne Chaos. Wenn es viele Diagrammtypen gibt, entscheidet die Architektur über den Ausgang. Das Hinzufügen eines neuen Typs sollte keine Änderungen im Kern erfordern und keine bereits funktionierenden Typen beeinträchtigen. Wir haben dies durch eine einheitliche Struktur für jeden Typ gelöst: eigene Datenvorbereitung, eigene Render-Komponente, eigene Typen — alles in einem isolierten Modul. Der Bibliothekskern weiß von der Existenz der Typen nur über einen gemeinsamen Vertrag, nicht über konkrete Implementierungen.

Visuelles Testen. Visualisierung ist in erster Linie das, was der Nutzer sieht, daher reichen Unit-Tests hier nicht aus. Jeder Diagrammtyp ist durch Screenshot-Tests mit Playwright abgedeckt, die in Docker für Reproduzierbarkeit ausgeführt werden. Eine Änderung in einem Modul kann das Rendering eines anderen nicht still beschädigen: Das ist sofort am fehlgeschlagenen Snapshot zu erkennen.

Ergebnisse und Schlussfolgerungen

Der Übergang nahm Zeit in Anspruch und erforderte erhebliche Investitionen. Aber das Ergebnis ist nicht einfach “eine Bibliothek durch eine andere ersetzt”. Das haben wir erreicht:

• Vollständige Kontrolle über den Code. Wenn etwas nicht wie erwartet funktioniert — können wir an jede Stelle gehen, die Ursache verstehen und beheben. Keine Black Boxes, keine Workarounds über fremden Code, kein Warten auf einen Fix vom Anbieter.

• Open Source. Die Bibliothek ist für alle verfügbar — nicht nur für das DataLens-Team. Das bedeutet externe Contributions, öffentliche Issues, transparente Änderungshistorie. Ein Problem, das ein externer Nutzer meldet, hilft, das Produkt für alle zu verbessern.

• Eine einheitliche visuelle Sprache. Die Diagramme sind zu einem organischen Teil der DataLens-Oberfläche geworden, kein eingesetztes Element eines Drittanbieters. Themisierung, Typografie, interaktive Komponenten — alles aus einem Design-System.

Eine eigene Diagrammbibliothek zu entwickeln ist keine Entscheidung, die man leichtfertig treffen sollte. Es ist ein großer Arbeitsaufwand, die Notwendigkeit, ein weiteres Produkt zu pflegen, zu dokumentieren und weiterzuentwickeln.

Aber wenn Ihr Tool rund um Datenvisualisierung aufgebaut ist, wenn Sie nicht-standardmäßige Anforderungen an das Verhalten haben, wenn Sie vollständige Kontrolle über das Erscheinungsbild und tiefe Integration mit dem Design-System wollen — wird der Vendor-Lock an einer fremden Bibliothek irgendwann zur Decke. Wir sind dagegen gestoßen und haben entschieden, sie zu entfernen.

Was kommt als Nächstes

Die Bibliothek entwickelt sich aktiv weiter, und wir haben mehrere Richtungen, an denen wir gerade arbeiten.

Framework-agnostischer Core. Heute ist @gravity‑ui/charts eine React-Bibliothek. Wir planen, den Kern — die Datenvorbereitungslogik, den Aufbau von Skalen, die Koordinatenberechnung — in ein separates Paket ohne Abhängigkeit von einem bestimmten Framework auszulagern. Das eröffnet zwei Wege: Nutzung mit reinem JavaScript ohne React und die Möglichkeit, schlanke Wrapper für Vue, Angular oder andere Frameworks zu entwickeln, ohne die Kernlogik zu duplizieren.

Range-Slider für kategoriale Achsen. Die Range-Slider-Komponente funktioniert derzeit mit numerischen und zeitbasierten Achsen — sie ermöglicht die Auswahl eines Bereichs und das “Hineinzoomen” in den benötigten Datenabschnitt. Aber kategoriale Achsen (z. B. eine Liste von Ländern oder Namen) sind für BI-Analysen nicht weniger wichtig. Wir erweitern den Slider so, dass er auch mit Kategorien arbeiten kann: eine Teilmenge von Werten auswählen und diese an die Datenfilterung übergeben.

Dokumentation für Contributors. Einen neuen Diagrammtyp hinzuzufügen ist derzeit ein verständlicher Prozess für diejenigen, die die Bibliotheksarchitektur von innen kennen. Für einen externen Contributor ist das jedoch nicht so offensichtlich. Wir wollen detaillierte Guides erstellen: Was ist ein Typmodul, welchen Vertrag muss es erfüllen, wie schreibt man Tests, wie verbindet man eine neue Visualisierung mit dem Gesamtsystem. Das Ziel — damit jemand, der noch nie mit der Codebasis gearbeitet hat, anhand der Dokumentation selbstständig einen neuen Diagrammtyp hinzufügen kann.

Die Bibliothek @gravity‑ui/charts ist unter der MIT-Lizenz verfügbar — Sie können sie gerne in Ihrem Projekt ausprobieren.

• Dokumentation → gravity‑ui.github.io/charts

• Storybook → preview.gravity‑ui.com/charts

• GitHub → github.com/gravity‑ui/charts

Wir freuen uns über einen Stern auf GitHub ⭐