CRM-21179 - Provide copies of dc.js, etal, for use by extensions
#11005
Conversation
totten
force-pushed
the
master-visual-bundle
branch
from
31ce815
to
2e7ddc0
Compare
CRM/Utils/VisualBundle.php
Outdated
| */ | ||
|
|
||
| /** | ||
| * This class defines teh `visual-bundle.js` asset, which combines `dc.js`, |
This defines an asset named `visual-bundle.js`. It creates a custom build
of `dc.js` + `crossfilter.js` + `d3.js` which loads all the services into
the namespace `CRM.visual.{foo}`, which allows it to coexist with other
copies of the library.
totten
force-pushed
the
master-visual-bundle
branch
2 times, most recently
from
5250630
to
3229d04
Compare
…her ext's == Before == In `hook_civicrm_angularModules`, the `js` resources are assumed to be file-blobs relative to the declared extension. == After == In `hook_civicrm_angularModules`, the `js` resources can be: * `assetBuilder://NAME?PARAMS`; in which case the JS file is loaded from the `asset_builder` service * `ext://EXTKEY/FILE`; in which case the JS file is loaded form another extension * Otherwise, the resource is assumed to be file-blob relative to the declared extension
totten
force-pushed
the
master-visual-bundle
branch
from
3229d04
to
e5c376e
Compare
totten
changed the title
dc.js, etal, for use by extensionsdc.js, etal, for use by extensions
|
@totten - IMO we should not be newly adopting old versions of libraries without good reason. And since you are continuing to include the old version as before to maintain Civivisualize support, I don't see the reason our new visual bundle shouldn't be up-to-date. |
|
Agree. Lets go new. Also any views of using c3 as its a nice wrapper for d3 and looks nice? http://c3js.org/ ? |
|
@colemanw This uses the latest stable version of
@jamienovick We had mockups and discussions in
|
|
Hi,
Would it be useful to show how we would implement a feature needed in the
core using dc/civi and compucorp does it on c3 to compare?
X+
…On 27 September 2017 at 17:19, Tim Otten ***@***.***> wrote:
@colemanw <https://github.com/colemanw> This uses the latest stable
version of dc (2.1.x) along with its dependencies.
d3 v3=>v4 is a major change -- more akin to Drupal 6=>7 or Angular 1=>2.
Both dc and c3 are based on d3 v3.x. They are not currently compatible
with d3 v4.x. (See eg this <dc-js/dc.js#1173>
and this <https://github.com/c3js/c3/blob/master/bower.json#L29> and this
<https://github.com/dc-js/dc.js/blob/develop/bower.json#L21>.)
@jamienovick <https://github.com/jamienovick> We had mockups and
discussions in cases about trade-offs between dc.js and c3.js. Recap:
- dc.js keeps us aligned with Civisualize - so that we're using the
same concepts/terminology/etc. It's better for implementing
interactive/multipart panels. Trade-off: it's documentation is more arcane.
- c3.js has nicer documentation and more stylized defaults. Trade-off:
it's harder to undo/remove bits that you don't want (which posed immediate
issues in their donut chart), and it diverges from Civisualize
community-of-practice.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#11005 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAH1qjEX4UPbUJ1iLjxliJk1I7d28ADaks5smmd2gaJpZM4PdbKN>
.
|
|
Good impulse. For some context -- the impetus here is to support CRM-21179 and civicrm/org.civicrm.civicase#45 (which is now already implemented on the The fiddles were: Note that those fiddles are not apples-to-apples -- I continued iterating on the |
Overview
This PR adds a new asset,
visual-bundle.{js,css}, which combines together dc.js, d3.js and crossfilter.js. The aim is to build on key elements of Civisualize in a way that allows broader community-of-practice. The libraries and versions are carefully chosen to match Civisualize.visual-bundle.{js,css}is provided as a resource for developers -- but this PR doesn't actively use the resource within core.Note: This is the product of a fairly long conversation with @colemanw, @jamienovick, and @guanhuan about how to manage the dependencies on these libraries. I'll try to recapture that conversation below.
Before
civicrm-coreincludes a copy ofd3v3.4.x. It can be manually loaded as[civicrm.bower]/d3/d3.js.civisualizeincludes a copy ofd3v3.5.x,dcv2.1.x, andcrossfilterv1.3.x.After
d3, etal, are still available.civicrm-coreprovides an optionalvisual-bundle.{js,css}:d3v3.5.x,dcv2.1.x, andcrossfilterv1.3.x. (These basically matchcivisualize, but they include small patch-level updates.)visual-bundle.jsto coexist with other libraries, all JS services are namespaced (much likeCRM.$orCRM._). Speciifcally:d3=>CRM.visual.d3dc=>CRM.visual.dccrossfilter=>CRM.visual.crossfilterCivi::service('asset_manager')->getUrl('visual-bundle.js')) and include that file.Comments
Several points were raised during the previous discussion. (Note: I'm acting as a rapporteur in trying to capture these points -- not every person agrees completely with every point, but mostly they're valid points.)
dc.jsandd3.jsandcrossfilter.jsorg.civicrm.civicase, you should also install Civisualize. This doesn't require any new packaging work, but it exposes pure-CiviCase users to the contribution/membership/etc reporting.civisualize_reportsandcivisualize_sdk. However, this is a big ask, and it creates a significant impact on sysadmins when they upgrade, and we still have issues with dependency management in core.composerfor distribution: This is potentially elegant, but it puts major design questions and downstream impacts on the critical-path for CiviCase.civicrm-core: This allows multiple extensions to load the same copy+versions of the libraries. However, it puts core in the hotseat if anyone wants to upgrade or mix-in different versions.dc/d3/crossfilterare namespaced underCRM.visual.*.visual-bundle.jsis not loaded by default. It's purely opt-in.d3v4 plus some future version ofdcthat's compatible with it), then that can be packaged separately (egvisual-bundle-2.jsandCRM.visual2.*). Thevisual-bundle.jsandvisual-bundle-2.jscan coexist.