Code structure: extending d3 object about d3-selection HOT 6 CLOSED

Is this strictly to benefit maintainers of standalone.js? That doesn’t seem particularly onerous at the moment, and it’s nice having some flexibility to support the old monolithic API while designing new CommonJS modules.

(If you’re intending this as a mechanism for creating custom builds, I’m expecting people to either concatenate the pre-built files or to use Browserify to require the non-standalone files directly.)

from d3-selection.

Yes, that makes sense to me. Following my suggestion you would be stuck building the new CommonJS modules to match the old API.

from d3-selection.

OK, closing.

from d3-selection.

Following up on this, I’ve made some changes to how the code is structured. I found it confusing to have two different APIs (one if source files are required directly and another for the “standalone” version). So instead this module now just has one source file, index.js, which populates the d3 object directly. Other D3 modules can follow this same approach of decorating the d3 object.

from d3-selection.

The disadvantage of this approach is being able to require smaller components of d3, which is what I have done in the past with Smash, selecting individual files. This could be done with a require('d3-selection/mouse') etc. and keep the code size down if the code was separated into individual files in the repo. This isn't necessarily incompatible with the approach of having a single index.js entry point.

However... for the d3-selection module at least there isn't a lot of sense / need to just require a smaller piece, and perhaps the amount of space/kb saves is not that significant?

from d3-selection.

The ability to require smaller components of D3 is one of the main reasons we are breaking D3 up into different repositories. (Imagine d3-selection, d3-transition, d3-scale, etc.) I don’t believe it is worth it to break it down further than the repository / module level.

from d3-selection.