Modèle de données et propriété

Formes de typed-array, règles de validation, trous et transfert de propriété au worker.

Sixtyfold reçoit chaque champ numérique dans son propre Float64Array au lieu de millions d’objets lignes. Cette disposition en colonnes rend le transfert vers un worker et le rendu prévisibles.

Les formes ci‑dessous sont les entrées acceptées par les méthodes line et stock.

Données de ligne

Un jeu de données mono-série comporte une colonne X ordonnée et une colonne Y :

interface TimeSeriesData {
  x: Float64Array;
  y: Float64Array;
  length: number;
}

Les données multi-séries partagent la même X pour chaque série :

interface MultiSeriesData {
  x: Float64Array;
  series: Array<Float64Array | {
    low: Float64Array;
    high: Float64Array;
    y?: Float64Array;
  }>;
  length: number;
  seriesCount: number;
}

N’utilisez l’objet range que pour une série range ou band. low et high définissent l’enveloppe ; l’y optionnelle fournit son trait central explicite. Omettez y, ou réglez la largeur de la série à zéro, lorsqu’un point milieu synthétisé serait trompeur.

Les valeurs X doivent être finies et croissantes. Les timestamps sont des nombres ordinaires ; les millisecondes epoch sont conventionnelles mais non obligatoires. minViewportRange, les valeurs de viewport, les timestamps des marqueurs et toutes les autres options de domaine X utilisent la même unité que X.

Utilisez NaN dans les tableaux Y, range-low ou range-high pour indiquer une observation réelle manquante. Les renderers connectés interrompent le tracé au lieu de dessiner à travers la lacune.

Données OHLCV

interface OHLCVData {
  timestamp: Float64Array;
  open: Float64Array;
  high: Float64Array;
  low: Float64Array;
  close: Float64Array;
  volume: Float64Array;
  length: number;
}

Les six colonnes doivent avoir la même longueur. StockChart.setData utilise normalizeOHLCVData pour déterminer la longueur effective à partir de la colonne des timestamps et valider que les timestamps sont finis et monotone­ment croissants ou décroissants. Des timestamps égaux sont acceptés pour l’historique statique. Une entrée croissante conserve ses tableaux ; une entrée décroissante est copiée et inversée sans muter l’appelant.

Ne synthétisez pas de fermetures d’échange ni d’intervalles de flux absents uniquement pour rendre les horodatages réguliers. timeScale: "market" compresse visuellement les intervalles absents tandis que les étiquettes, événements et marqueurs conservent leurs horodatages réels.

Propriété des tampons

En mode worker, les API de lot setData, setMultiSeriesData, addVectors, StockChart.setData et de lot d’actions transfèrent des tampons de tableaux typés vers le renderer pour la voie la plus rapide. Les tampons transférés deviennent détachés et ne doivent pas être lus ni réutilisés par l’appelant.

Clonez explicitement lorsque l’application doit conserver sa propre copie :

chart.setData({
  x: sourceX.slice(),
  y: sourceY.slice(),
  length: sourceX.length,
});

Ne comptez pas sur le comportement de repli du thread principal pour conserver la propriété. Traitez les entrées en masse comme transférées quel que soit le renderer résolu afin que le changement de navigateur ou de politiques CSP ne puisse pas modifier la correction de l’application.

Streaming

Le streaming de lignes utilise un buffer circulaire de taille fixe initialisé avec initStreaming(seriesCount, maxPoints). Le streaming de type stock utilise initStreaming(maxCandles). Les capacités et le nombre de séries de lignes doivent être des entiers positifs. Une fois la capacité atteinte, les observations les plus anciennes sont remplacées tout en préservant le rendu chronologique.

Utilisez les méthodes de lot vectoriel ou chandelier quand les données arrivent déjà en colonnes. Les méthodes à observation unique mettent en lot via requestAnimationFrame et conservent leur ordre par rapport aux ajouts en masse. La méthode de ligne addVector copie ses valeurs avant de les mettre en file, de sorte qu’un tableau scalaire de valeurs peut être réutilisé immédiatement.

Les ajouts de lignes exigent des horodatages finis et des colonnes de séries alignées. Maintenez X en ordre croissant et ne représentez les lacunes que dans les colonnes Y. Les ajouts de données boursières exigent en outre des horodatages strictement croissants entre les appels, les chandeliers mis en file d’attente et chaque chunk ; répéter un horodatage n’est pas une opération de mise à jour.

La validation en masse s’exécute avant de vider les échantillons en file d’attente ou de transférer l’entrée. Des longueurs ou des horodatages rejetés laissent les échantillons en attente inchangés et les tampons du caller attachés ; addCandleBatches valide tous les chunks avant d’en transférer aucun. Ces contrôles ne remplacent pas la validation côté application des unités, prix, volumes ou autres sémantiques de flux. Voir Line streaming et Stock streaming pour les contrats spécifiques à chaque méthode.