-
Notifications
You must be signed in to change notification settings - Fork 1.8k
Closed
Description
@gordonwoodhull, I was going through open issues marked for dc-v5. It seems we can close quite a lot of those - which are small work each. However, at this stage, it will good to have some decisions that will impact some of those.
I have started work on updating examples, the docs, and the migration guide. These I have hosted at https://kum-deepak.github.io/dc.js/, https://kum-deepak.github.io/dc.js/html2/, and https://kum-deepak.github.io/dc.js/html2/pages/Guides/dc-v5-upgrade-guide.html. Please go through the migration guide, it will give an idea of stuff that is removed or is getting moved to the compat layer.
Decision points (some of these we have discussed already):
- The library has been written in a way to facilitate releasing with and without the compat layer. We will need to decide which one we call the dc@5, what we call the other?
- Alternatively, I have not tried, however, it should be possible to split into dc@5 and dc-4-compat. Users needing the compat version will need to make two includes.
- Do we need to bring anything back from compat into the main release? This will become clearer once we start moving examples to the newer syntax.
- Compatibility with existing add-on libraries #1734 - I am not hopeful that many will work with the new release. It should not be difficult to migrate these. I can port the most important ones.
- Remoting capabilities ([PoC] Remote data Provider - not to be merged #1801) - There is a small set of classes and server samples. Server samples would definitely be distributed as samples as a separate repo. The client additional code may be distributed as separate UMD and ES6 modules inside or outside the main repo. We will need to make consideration for documentation accordingly,
- Should we support only d3@6 with dc-v5. This will hardly impact users who are using dc standalone, however, will allow cleaner library code?