Progettazione della libreria di grafici javascript

Question

Progettazione della libreria di grafici javascript

#1 da (2 voti)

3

Ho iniziato a codificare una libreria di grafici su d3js: La mia libreria di grafici . Ho letto la riusabilità dell'API JavaScript e Campetti riutilizzabili di Towards . Tuttavia, NON sto seguendo realmente i suggerimenti perché non ne sono veramente convinto.

Ecco come è possibile utilizzare la mia libreria per creare un grafico a bolle:

    var chart = new XYBubbleChart();
    chart.data = [{"xValue":200,"yValue":300},{"xValue":400,"yValue":200},{"xValue":100,"yValue":310}];  //set data
    chart.dataKey.x = "xValue";
    chart.dataKey.y = "yValue";
    chart.elementId = "#chart";
    chart.createChart();

Ecco le mie domande:

Non usa il concatenamento. È un grosso problema?
Ogni proprietà e funzione sono esposte pubblicamente. (Esempio: larghezza, altezza sono esposti in Chart.js ). L'OOP è tutto basato sull'astrazione e il nascondimento, ma io non vedo proprio il punto in questo momento. Penso che esporre tutto dia la flessibilità di cambiare proprietà e funzionalità all'interno di sottoclassi e oggetti senza scrivere molto codice. Quali potrebbero essere le insidie di tale esposizione?
Ho implementato funzioni come: zoomare, "mostrare box informazioni quando il punto dati è cliccato" come "abilità". (esempio: XYZoomingAbility.js ). Fondamentalmente, tali "abilità" accettano l'oggetto "grafico", giocano con le variabili pubbliche di "grafico" per aggiungere funzionalità. Ciò che questo mi permette di fare è aggiungere un'abilità scrivendo:
```
activateZoomAbility(chartObject);
```
Il mio obiettivo è separare la "visualizzazione" da "interattività". Voglio "interattività" come: zoom per essere inserito nel grafico piuttosto che costruito all'interno del grafico. Ad esempio, non voglio che il mio grafico a bolle sappia qualcosa sullo "zoom". Tuttavia, voglio grafico a bolle zoomabile. Qual è il modo migliore per farlo?
Come testare e cosa testare? Ho scritto test misti: jasmine e file html effettivi per poterli testare manualmente sul browser.

api-design javascript chart

posta coolscitist 11.05.2014 - 13:54

fonte

1 risposta

Leggi altre domande sui tag api-design javascript chart

Adapter Pattern: Design Patterns Diagramma di classe UML: come annotare la relazione soggetto-osservatore?

score 2 · Accepted Answer

Le mie opinioni:

It does not use chaining. Is it a big issue?

Non è un grosso problema, ma lo rende più difficile da usare per gli altri. Una volta che uno stile viene implementato, le persone iniziano ad aspettarselo, e quando non funziona, alcuni buttano il lavoro come "rotto". Le persone non leggono la documentazione.

Every property and function is exposed publicly. (Example: width, height are exposed in Chart.js).

Uno dei grandi vantaggi di nascondere i dettagli è che, una volta espulso qualcosa, devi supportarlo quando riscrivi il codice per renderlo migliore. Un altro vantaggio è che, ma rendendo tutto funziona, puoi reagire quando una variabile cambia valori senza che l'utente cambi una variabile e poi chiama una funzione.

I have implemented functions like: zooming, "showing info boxes when data point is clicked" as "abilities". (example: XYZoomingAbility.js). Basically, such "abilities" accept "chart" object, play around with public variables of "chart" to add functionality. What this allows me to do is to add an ability by writing:

activateZoomAbility(chartObject);

Un concetto che stiamo cercando di evitare qui sta avendo nomi di funzioni in conflitto nello spazio dei nomi globale. Guarda le librerie che hanno dei plugin ma espongono solo una variabile globale (jQuery è una, ma di gran lunga non l'unica, anche se potrebbe essere la più documentata su come creare i plugin correttamente).

How to test and what to test? I have written mixed tests: jasmine and actual html files so that I can test manually on browser.

Guarda per vedere cosa testano gli altri e come lo fanno. Onestamente, ci sono un sacco di librerie rotte là fuori, quindi il test migliore è quello che fai, più possibilità hai di farlo bene e di non rompere nulla sugli aggiornamenti.

Grazie per aver offerto il codice che altri possono usare. Insieme, tutti noi possiamo creare una rete migliore.