Skip to content

Trace Module Functionality #180

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 30 commits into from
Jan 14, 2016
Merged

Trace Module Functionality #180

Show file tree
Hide file tree
Changes from 12 commits
Commits
Show all changes
30 commits
Select commit Hold shift + click to select a range
7e41625
Removed reference to Plotly
mdtusz Jan 8, 2016
b716568
Removed more references to Plotly
mdtusz Jan 11, 2016
d639a93
Change `module` to `_module`
mdtusz Jan 11, 2016
356d0af
Change `Plotly.Lib` to `Lib`
mdtusz Jan 11, 2016
7a22cff
Modify trace modules to all follow the same format, exporing `plot`
mdtusz Jan 12, 2016
2ac3605
Modify trace modules to work with registry
mdtusz Jan 13, 2016
6e53762
Update tests to require trace modules directly
mdtusz Jan 13, 2016
46b83d8
Modify index and plotly to have register func and traces registered
mdtusz Jan 13, 2016
23519f0
Require pie trace module directly
mdtusz Jan 13, 2016
71db785
Plot register function warns instead of throwing error
mdtusz Jan 13, 2016
06640b4
Update plotting calls to work agnostically using registered modules
mdtusz Jan 13, 2016
4507ec5
Fix eslint warnings for multiple var declarations
mdtusz Jan 13, 2016
6bd4c5b
Removed reference to Plotly
mdtusz Jan 8, 2016
b4793c1
Removed more references to Plotly
mdtusz Jan 11, 2016
48b3803
Change `module` to `_module`
mdtusz Jan 11, 2016
5a2da5c
Change `Plotly.Lib` to `Lib`
mdtusz Jan 11, 2016
4fe8440
Modify trace modules to all follow the same format, exporing `plot`
mdtusz Jan 12, 2016
e46373e
Modify trace modules to work with registry
mdtusz Jan 13, 2016
a7fda91
Update tests to require trace modules directly
mdtusz Jan 13, 2016
43156a3
Modify index and plotly to have register func and traces registered
mdtusz Jan 13, 2016
03232e0
Require pie trace module directly
mdtusz Jan 13, 2016
28def12
Plot register function warns instead of throwing error
mdtusz Jan 13, 2016
f831b66
Update plotting calls to work agnostically using registered modules
mdtusz Jan 13, 2016
4994256
Fix eslint warnings for multiple var declarations
mdtusz Jan 13, 2016
6dd9a41
Fix undefined reference
mdtusz Jan 13, 2016
823ae72
Merge branch 'agnostic-geo-trace' of github.com:plotly/plotly.js into…
mdtusz Jan 13, 2016
75dc282
Change fields used by module registry
mdtusz Jan 14, 2016
b8864eb
Require styleOne directly
mdtusz Jan 14, 2016
5f26169
Use Object.keys instead of for-in
mdtusz Jan 14, 2016
a693bb2
Change register function and add test
mdtusz Jan 14, 2016
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 3 additions & 1 deletion src/components/legend/index.js
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -12,6 +12,8 @@
var Plotly = require('../../plotly');
var d3 = require('d3');

var Pie = require('../../traces/pie');
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's require in pie/style_one.js directly, so that once we split out Pie from the core, legend won't bundle all of Pie into its module.


var legend = module.exports = {};

legend.layoutAttributes = require('./attributes');
Expand Down Expand Up @@ -233,7 +235,7 @@ legend.pie = function(d) {
.attr('transform', 'translate(20,0)');
pts.exit().remove();

if(pts.size()) pts.call(Plotly.Pie.styleOne, d[0], trace);
if(pts.size()) pts.call(Pie.styleOne, d[0], trace);
};

legend.style = function(s) {
Expand Down
19 changes: 19 additions & 0 deletions src/index.js
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -45,3 +45,22 @@ exports.Queue = Plotly.Queue;

// export d3 used in the bundle
exports.d3 = require('d3');

Plotly.register({
traces: {
bar: require('./traces/bar'),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice!

Bringing @bpostlethwaite and @alexcjohnson for some thoughts on the API:

  • I'm thinking that making Plotly.register take an option object might not be necessary.
// this might be sufficient
Plotly.register([require('plotly.js/bar'), require('plotly.js/box')]);

// or even where we would loop over the argument object
Plotly.register(require('plotly.js/bar'), require('plotly.js/box'));

Granted, passing an object with key traces makes the API easily extendible to registering components down the road. But, do users need to know that they are registering trace or component modules? Could we handle the trace / component split behind the scene inside the register function (e.g. by adding a type property to each trace module)?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The trace modules have _type in them right now, but it's more their name - I just followed the names of the arguments for the Plots.register function. I'd be happy to go either way with this though - the object notation allows for easily extending functionality in the future, but it is a bit more verbose. Up to you guys.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd go for the simplest form (loop over arguments). Another reason: you're not using the keys of this object - which is good, because we don't want users making their own names for the trace types, this should come from the module itself. But then why bother having an object with keys?

Re: components - either behind the scenes, or just make a different function like registerComponent. Doesn't make a big difference, I don't think.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 for loop over arguments.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 simplest

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What makes a component registerable? How can users do

Plotly.register(myComponent)

if we want users to be able to do that in the future an object notation may be necessary so we can allow certain requirements to be turned on/off during the registration process.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@bpostlethwaite

it would be nice to make it clear what is registerable though.
What makes a component registerable?

Maybe we could store another meta property in the trace modules? e.g.

var PlotlyBar = require('plotly.js/lib/bar');

console.log(PlotlyBar.moduleType);  // => 'trace'

and down the road, registerable component modules could have moduleType set to 'component'.

Moreover, Plotly.register should error out if given a module without moduleType.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't like using arguments unless it's the only way because it isn't as easily portable (you would have to use Array.spread)

Wouldn't arguments.length by enough?

@mdtusz that said, I'm ok with Plotly.register taken a single array as arguments. Your call.

Can we go with registerTraces as the function name,

I'd vote for a single Plotly.register and taking care of the distinction between trace and component modules behind the scenes.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

I'll add a moduleType field too then.

Do we want to get rid of the _'s though? I'm happy either way, so its up to you.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's get rid of the _'s. No need to add complexity here.

box: require('./traces/box'),
heatmap: require('./traces/heatmap'),
histogram: require('./traces/histogram'),
histogram2d: require('./traces/histogram2d'),
histogram2dcontour: require('./traces/histogram2dcontour'),
pie: require('./traces/pie'),
contour: require('./traces/contour'),
scatter3d: require('./traces/scatter3d'),
surface: require('./traces/surface'),
mesh3d: require('./traces/mesh3d'),
scattergeo: require('./traces/scattergeo'),
choropleth: require('./traces/choropleth'),
scattergl: require('./traces/scattergl')
}
});
Loading