Yaml dependencies from a cdn? about htmlwidgets HOT 10 CLOSED

As of now, there is no support for this in htmlwidgets, but there are some hacks. See #1 as the only reference that I remember. The desire to support multiple contexts in htmlwidgets makes this very difficult.

from htmlwidgets.

However, I should note that htmltools does support url assets, but href does not work in YAML for the htmlwidget.

library(htmltools)

tg <- tags$div()
tg <- attachDependencies(
  tg,
  htmlDependency(
    name="d3"
    ,version = 3.4
    ,src = c(href = "http://d3js.org")
    ,script = "d3.v3.min.js"
  )
)

from htmlwidgets.

@timelyportfolio I understand the implications of supporting multiple contexts, but it does not seem to me a blocking issue.
On the other hand a R function could - just when shiny is running - call a tags$script as appropriate, right?

from htmlwidgets.

Yes, but tags$script does not handle multiple synonymous dependencies, such as different versions of jquery or d3 that will inevitably come with different packages/widgets/themes, so I would use it very carefully, and recommend strongly against making it part of the behavior of your htmlwidget. As to "not a blocking issue", Pandoc (on which rmarkdown relies) will not work with these url assets, so I would say that it is a blocking issue.

from htmlwidgets.

@smartinsightsfromdata I would like to better understand the compelling reasons to load from a CDN. The design decision to have everything reside locally was made so that widgets work seamlessly in multiple contexts without any issues. If there are strong reasons where loading from a CDN is preferred, I would like to understand the use cases in depth.

from htmlwidgets.

@ramnathv It is very simple: I have done the wrapper for the js library pivottable by Nicolas Kruchten. The author has implemented a renderer using GoogleCharts, which does not allow for local storing of the library.
Originally I thought not to implement any renderer beyond the standard one (as similar results can be achieved with other packages).
Then users showed interest in the D3 renderer for Treemap, implemented very simply. This made me think to find ways to add - probably optionally - the Google Chart renderer.
I'm perfectly aware that this renderer would work only on shiny - and when an online connection is available. To be clear because of these reasons I wouldn't consider this high priority but a "nice to have" feature: it may well be that applies only to the Google Charts use case.

from htmlwidgets.

The GoogleCharts loader is a hot mess--it really foils the htmltools/htmlwidgets dependency loader. It's really quite tricky to combine a page of GoogleCharts visualizations that don't know about each other, since their loader wants to be called a single time with all the plugins you want to use.

from htmlwidgets.

@jcheng5 please consider that most of the "mechanism" is fully transparent for the widget: it is the pivottable code that manages the calling etc. The only thing it needs is the actual library loaded. An example here.

from htmlwidgets.

I am closing this issue, since allowing cdn based assets can create problems as outlined above. If there is a strong need to revisit this issue, feel free to reopen.

from htmlwidgets.

@ramnathv, I am a relative htmlwidgets noob, but I have one more use case to add to this issue. In order to support install_github, right now I believe the built JS library needs to be checked into the Git repository. It is not a good practice in general to place built resources in a Git repo, since they can accumulate over time with different versions and make cloning/installing more resource intensive. Supporting CDN scripts would resolve this issue for me.

from htmlwidgets.