Open jaygray0919 opened 5 years ago
Currently each amp-script element is self-contained.
This example would not work as written, however if the second resource was a combination of the first and second then it should.
We're investigating a method to declare mutual shared dependencies for amp script elements, would this be an interesting option for you?
@kristoferbaxter we'll go with whatever solution works for AMP. As you know, D3
works similarly to a jQuery
"main" and a local JavaScript
app: initialize jQuery
, then load the app. Per your comment, that ain't gonna work using the current design. Combining the D3
prerequisite libraries with the app-logic is not impossible, but it means that we would have to re-write all of out D3 apps. So i'm not sure how "to declare mutual shared dependencies" but it sounds good and workable.
Update: as with jQuery
there are several flavors of base D3
functionality, and then variations designed for different visualizations (dendrogram, fiboni, classes, directed graphs, ...). Then users add function; in our case its a third library that customizes the visualization-specific library.
Do you envision a scenario where we would submit a base d3.js
(e.g. 1.0.6) and a visualization-specific library for 'vetting'? Once vetted, we could invoke our customization
as illustrated in the canvas.js
example?
@kristoferbaxter did you have an opportunity to work with the d3.js
repo we provided before your Australia trip? Anything else we can do here to test d3.js
variations with amp-script
? We did see in an amp.dev
thread from @sebastianbenz that another developer also may be working on d3.js
implmentations (have misplaced the name).
d3.js is awesome, but my guess is that you'd have to substantially expand the subset of the DOM API that WorkerDOM supports to make d3 work out of the box.
So, for d3 to work in <amp-script>
, you'd have to rewrite d3 to use the supported DOM API. Not a small project, either.
It looks to me that d3.js is currently about 77K minified. Would it be feasible to wrap it into an AMP component? Or is it too hefty?
Thanks for revisiting this issue. Bottom line for us: too expensive to engineer a solution for d3.js using amp-script
at this time. Since amp-script
is/will be stretched to handle other vanilla JavaScript issues, we'll watch how that plays out. Hopefully d3.js (and amp-viz-vega
) is on an assessment/development plan. ITMT, we have an amp-iframe
solution in a tabbed interface that works well. We can feature a visualization, and - in another iFrame tab - the science article that is the subject of the visualization.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.
Am guessing that a solution for this class of JavaScript processing is to use Bento for the AMP-components used on the target d3.js page.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.
Our goal is to run JavaScript data visualization libraries using
amp-script
-- avoiding need to useamp-iframe
.This example implements
canvas.js
withamp-script
https://afdsi.org/amp-script-03/ Source is Weston Ruter and his experiment here: https://github.com/westonruter/javascriptforwp-conference-amp-examples using this technique:We would like to implement our
d3.js
applications using a similar technique. A simple stand-alone D3 version is shown here: https://afdsi.org/amp-script/reference.htmlOur experiment follows
canvas.js
example, but uses ad3.js
library as follows:The experiment is here: https://afdsi.org/amp-script-01/ We see the following error message:
Are we doing something wrong? Is there an alternative way to invoke a
d3.js
library?We see these discussions: https://github.com/ampproject/amphtml/issues/23579 https://github.com/ampproject/amphtml/pull/23658 https://github.com/ampproject/amphtml/issues/18830 https://github.com/ampproject/amphtml/issues/13471