This fork is a branch which is on top of the right-y-axis branch. This means it adds everything that the right-y-axis branch does PLUS a new axis type (multiscaling linear y axis).

This new axis is used to represent multiple scales on the same axis. Both this and the right-y-axis feature are coded in such a way as to not affect any existing deployments unless they choose to use the new features.

Jaime -- if you would like I would be happy to walk you through these changes, how to configure the new chart types, and what the new chart types look like (and do)

A lot of changes. I tried to do the messy change of removing and re-indenting files on the first commit and then fixes on the following commits to make it a bit easier to see, but it is still hard to see the changes :(

This allows to specify any configuration option as a function. This functions will be called just before the rendering starts. Some functions are not "materialized" as they expect to be called with some data within the context of the render cycle for example data formatters expect to be called for each point in the data set. These functions are not materialized before the render starts and are called in the context of the specific visualization.

Changing data and re-rendering causes ticks to break, Error: Invalid value for <g> attribute transform="translate(0,NaN)"

I'm using a grouped bar chart as in this fiddle: http://jsfiddle.net/gh/get/jquery/1.11.0/forio/contour/tree/master/examples/showcase/bar/bar-grouped

To reproduce, modify the fiddle to call setData and render like so:

chart = new Contour({
    ...
})
.cartesian()
.horizontal()
.bar(data)
.legend(data)
.tooltip()
.render();

chart.setData(data).render();  // just  re-rendering using the original data, nothing funny here

You'll see the most of the ticks disappear...

Contour relies on lodash being on the global namespace which it then alters to add utility functions. Requiring lodash in other app modules would reset lodash breaking future instances of Contour. Found that putting utilitities in own namespace nw resolves this issue.

Future We should still consider:

• not relying on libraries in global space.
• registering forio-contour with npm

Filter data to a desired num pts (configurable with new data object ({filter:true, filterNumPts:1000}))

Always keeps first/last -- and then for all the ones in the middle it grabs the high/low per interval

For issue #252 - allow user to pass in function to yAxis:tickValues parameter. See the following jsfiddle for usage - http://jsfiddle.net/a5L7x0c5/6/.

this pr was opened a year ago:

https://github.com/forio/contour/pull/237

relying on _ not to be touched is dangerous and its breaks in my use case.

can we rename nwUtils to avoid this conflict or suggest a better path forward.

we want to continue to use contour, and not have to work on a stale version nor constantly have to merge diverged branches.

• distanceX and distanceY, if given overrides the distance option.
• change clampPosition to the edge and not opposite. ie. if you go distanceY = 400 it will max out on the top of the graph.

Demo: http://jsfiddle.net/ucstdgsa/

Add new centeredAxis option for y-axis - focus is on dynamically centering y axis around data. Unlike default axis scaling, this option ignores the zeroAnchor option (meaning that the y axis will not be anchored at zero by default).

This PR also includes the changes from branch y-axis-scaling.

Here is a jsfiddle that illustrates the use of the centeredAxis option - http://jsfiddle.net/a5L7x0c5/1/

For #217 - upgrading to latest version of lodash (4.17.2). The following functions have changed since lodash 2.4.2 (changes are visible in https://lodash.com/docs/3.10.1):

_.all -> _.every _.any -> _.some _.contains -> _.includes _.invoke -> _.invokeMap _.pluck -> _.map _.select -> _.filter _.unique -> _.uniq

Also, the 'this' argument (3rd parameter) has been removed from most methods - from docs: Removed thisArg params from most methods because they were largely unused, complicated implementations, & can be tackled with _.bind, Function#bind, or arrow functions.

In this PR, I've replaced all instances of the above functions which are out of date, and tried to address every instance of the thisArg being used (by replacing it with Function#bind) - possible that I missed some, but unlikely - I've tested a basic line graph locally to sanity check.

Bumps lodash from 4.17.2 to 4.17.19.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

yAxis tick value generation uses a niceTicks function that seems to generate some not so nice ticks on certain datasets:

_.nw.niceTicks(-16575919.58, 0, undefined)
//  creates [-16575919.6, -12575919.6, -8575919.6, -4575919.6, -575919.6, 3424080.4]

Found while testing with data set: [-16575919.58, 0, 0, 0]

Reference in code, using Y-Axis as example:

The spacing calculated for the left padding:

_getAdjustedLeftPadding: function(options) {
    var yDomainScaled = this._getYScaledDomain(this.yDomain, this.options);
    var tmpScale = d3.scale.linear().domain(yDomainScaled);
    var yLabels = tmpScale.ticks(options.ticks);
    var format = options.labels.formatter || d3.format(options.labels.format || ",.0f");
    var yAxisText = _.map(yLabels, format).join("<br>");
    var yLabelBounds = _.nw.textBounds(yAxisText, ".y.axis");
    return maxTickSize(this.options.yAxis) + (this.options.yAxis.tickPadding || 0) + yLabelBounds.width;
},

^ Uses tmpScale.ticks(options.ticks) to generate approximated tick values for spacing calculation

The actual tick value calculation for the y-axis:

axis: function() {
    /*jshint eqnull:true */
    var options = this.options.yAxis;
    var domain = this.domain;
    var dMin = options.min != null ? options.min : options.zeroAnchor ? Math.min(0, domain[0]) : domain[0];
    var dMax = options.max != null ? options.max : domain[1];
    var tickValues = options.tickValues || _.nw.niceTicks(dMin, dMax, options.ticks);
    var numTicks = this.numTicks(domain, options.min, options.max);
    var format = options.labels.formatter || d3.format(options.labels.format);
    return d3.svg.axis().scale(this._scale).tickFormat(format).tickSize(options.innerTickSize, options.outerTickSize).tickPadding(options.tickPadding).ticks(numTicks).tickValues(tickValues);
},

^ Uses options.tickValues || _.nw.niceTicks(dMin, dMax, options.ticks); to generate the actual tick values to be rendered.

This will occasionally cause the the ticks labels to be rendered with an inaccurate amount of space for them. We managed to produce this issue with a standard column chart using the data: [{"x":"AGM","y":12.125990845966125},{"x":"Supercapacitor","y":-12.39133198369404}]

Setting offset in the options for the chart will display the bar/column correctly, however the tooltip will still render in the position it would be if the bar/column was not offset.

{
    ...options,
    column: {
        offset: 20,
    }
}

Column without offset:

Column with offset:

Only occurs for charts with points that have the same X and Y values (but differing Z). The tooltip calls a findOriginalDataPoint function which finds the first point that has the matching x and y, and uses that point to generate the tooltip text message; points with the same x and y values but different Z, or other values will not be correctly picked up.

Snippet from contour.js

            function findOriginalDataPoint(d) {
                var res = [];
                _.each(data, function(series, seriesIndex) {
                    var name = series.name;
                    _.each(series.data, function(point) {
                        if (point.x === d.x && d.y === point.y) {
                            res.push(_.extend(point, {
                                series: name,
                                seriesIndex: seriesIndex
                            }));
                        }
                    });
                });
                return res;
            }