ES6 - assignments to exported members

[kum-deepak]

Ref #1520

Rollup generated js does not allow reassigning any exported members. Currently test cases fail that use reassigning:

• disableTransitions (one spec)
• redrawAll - two specs put a spy on this call (which try to replace this function)

[gordonwoodhull]

There will probably be a long tail of things that no longer work because they rely on reassignment.

There are a few global settings on the dc namespace. We might have to make these into global setters.

Not sure what to do about spies.

[kum-deepak]

My thinking is not firmed yet. However my current thinking is like the following:

• Currently there are few settings which are somewhat global
• Package all these settings into a class - say Config or DcConfig
• Attach an instance of this object (with default values) to the Chart Group
• A chart will always know which chart group it is linked to
• The config can be assigned to a chart group or to a chart
• If no config has been assigned to a chart (which is likely to be the case), it will use config from the chart group

However before this we will need to discuss how much refactoring and breakage of existing API is acceptable.

[kum-deepak]

As of now commented out these 3 specs via b741b1a

[kum-deepak]

I have been reading about ES6 and tree shaking. It seems a proper structure would be like following:

• No top level exported API should manipulate state or depend on state.
• No mutable state should be a top level exported symbol.
• Mutable state should be part of an Object (preferably of a defined Class). If not possible than wrapped inside a class as static members (e.g., utils.uniqueId).
• All stateless helper methods can become top level exports (e.g., utils.arraysEqual)
• Some larger, limited use, methods can go to their own modules (e.g., utils.toHierarchy)

[gordonwoodhull]

Seems like there needs to be a third level: look for config

1. on chart, then if there's none set
2. on chart group, or finally
3. on dc itself, as demonstrated in Refactoing #1553.

Or does the third one violate "No mutable state should be a top level exported symbol"?

I hope not, since it would be handy. I guess if all else fails we could make dc.config immutable and only contain defaults, but that's not as convenient for users.

[gordonwoodhull]

Probably would not want to cascade individual settings, just look for a config object at each level, which will have some value for every setting.

[kum-deepak]

Makes sense.

[kum-deepak]

I think we can close this task for this version. More changes than the current state would cause interface breakage.

[gordonwoodhull]

Agreed. I looked over src/core and any function anyone would want to replace is under the filters, utils, or config namespace and therefore still assignable.

Removing the spies on dc.redrawAll to close this out

[gordonwoodhull]

spies removed in 78b4c13