61–70 of 90 posts
This is definitely the best charting library I've worked with so far, mostly because of its flexibility. However, being afraid that I'm not aware of some other, maybe more powerful, libraries out there, I'm asking here are there good alternatives? Also, there were some rumors lately regarding the layoffs in Palantir, which makes me worry about the future of the project.
Can someone enlighten me on why they're doing two declarations, one empty returning `this` and the other, implemented, returning `any`? public connectorsEnabled(enabled: boolean): this; public connectorsEnabled(enabled?: boolean): any { if (enabled == null) { return this._connectorsEnabled; } this._connectorsEnabled = enabled; return this; } https://github.com/palantir/plottable/blob/develop/src/plots...
The odd thing is that they are not using three: public connectorsEnabled(enabled: boolean): this; public connectorsEnabled(): boolean; public connectorsEnabled(enabled?: boolean): any { if (enabled == null) { return this._connectorsEnabled; } this._connectorsEnabled = enabled; return this; } In that way, typescript will use the most specific overload to do type checking, so you'll get an actual boolean when doing con…
Earlier quoted context omitted.
x.connectorsEnabled() on line 24 is a getter, returning the boolean. x.connectorsEnabled(boolean) on line 31 is a setter, return `this` for the benefit of method chaining. That then leaves the actual definition which goes through to the JavaScript: it has an optional argument to satisfy both plausible signatures and starts on line 32. In short, the first two are basically hints for TypeScript (if the signature is suc…
It feels complicated due to not using separate getter and setter functions. By splitting it into two functions the annotations could be reduced as well. I wonder what the reason for not taking that approach was.
I really dislike these simple charting libraries, because I always have some kind of issue that just wastes my time in the end. For example with plottable, there is a hover event function that is extremely expensive that will trigger for every pixel movement with your mouse. With just a few hundred datapoints every chart we rendered ran horribly slow. With D3.js you have instead full flexibility and the only performa…
Seriously... I was just reading the examples and thinking to myself "why would I use this over vanilla D3"? The syntax isn't more concise and offers less control, and introduces a whole new api to learn. To me this is like writing a DOM manipulation framework on top of jQuery...
Earlier quoted context omitted.
The odd thing is that they are not using three: public connectorsEnabled(enabled: boolean): this; public connectorsEnabled(): boolean; public connectorsEnabled(enabled?: boolean): any { if (enabled == null) { return this._connectorsEnabled; } this._connectorsEnabled = enabled; return this; } In that way, typescript will use the most specific overload to do type checking, so you'll get an actual boolean when doing con…
There are all three. Just look up a bit.
How well does this handle large datasets (thousands of datapoints)? That's a problem that, having worked mainly with Chartist, I have struggled with.
If you need 10000> points and interactivity you could try my own: http://generalsarsby.github.io/mjs_plot/
Earlier quoted context omitted.
What is the maximum number of datapoints that plotting library should be excepted to handle at the same time? I think 10,000 datapoints is the limit in 2d visualization but even 1000-2000 datapoints is often acceptable limit. It's usually reasonable to reasonable to downsample and decimate data before presenting it. If user zooms into data, it should be handled in some other ways than keeping all data.
Displaying up to 1000 datapoints at once seems like a reasonable limit. But if the library supports zooming, I highly appreciate it if I can just put my 10,000 to 100,000 datapoints into the library, specify a simple filter function (avg, sum, min, max) and let the library pick the points it wants to display at each zoom level. Beyond ~100,000 datapoints any filtering is likely better done in the database than on the…
A 100,000 data point file would be about 500kb transfered to the client. This is still a tiny amount of data to play around with in JS. It is possible to build an array of image tiles, and zoom around like google maps. But keeping the image tiles in memory could be worse than just replotting if the plot function is fast and optimized enough.
Earlier quoted context omitted.
Surely if it's a bug that affects everyone then file an issue? If there's a bug in a library then that doesn't invalidate the entire concept of 'simple charting libraries'. How many have you tried? d3 is robust because it's great code that's widely used - not because of it's other design choices.
d3 is robust because it's practically a language, whereas all of these charting libraries that wrap it are essentially "d3 frameworks".
Earlier quoted context omitted.
Unless this has changed, you need the $9,950/year plan to serve it "behind your own firewall". I.e. otherwise plots on done on their systems by uploading data.
That used to be the case until the end of last year, but it has been open-sourced and you can render a plot entirely on the client side, without a roundtrip to Plot.ly's servers (no rate limits anymore, custom integrations to your existing stuff, etc.), for free. https://plot.ly/javascript/open-source-announcement/
See https://github.com/plotly/plotly.js/issues/16
Maybe there is a way of rolling your own, but there isn't any documentation...
We ended up using (Django-)NVD3 instead, which worked fine.