This is an update to how we handle the (currently JS-only) feature of supporting custom JS scripts. Until now, these have been specifiable at the data source level, using the scripts keyword, which accepts an array of URLs for external scripts. The original intention was to make these scripts available in the execution scope for the source transform feature.
However, it makes sense to broaden this scope for two reasons:
Any such scripts are loaded into the entire page/worker thread context, meaning that regardless of which data source they were specified for, they are actually globally for any JS function in the scene file, including other data source transform functions, but also any color, filter, etc. functions that may appear in the scene. (While this was an initially unintended implementation detail, it's also not an easy one to work around in practice.)
We already had a desire to expand the use of these scripts in other scene functions. For instance, by using scripts such as D3 or Color Brewer in color functions, it is easier to support data visualization use cases. It also provides the ability to define scene components/fragments that include their own external script dependencies, suitable for import/reuse in other scenes; this use case has been desired, but previously required coupling to an assumed data source name, that might not always exist in the scene being imported into.
To address the above, scripts are now also specifiable at the scene level. Additionally, the syntax has been revised (with backwards compatibility for existing sources) to provide better merge/import behavior, and reduce ambiguity/conflicts.
Instead of an array of script URLs, scripts are now specified as a mapping, with the key being a user-defined library name, and the value being the URL. For example:
scene:
scripts:
d3: https://d3js.org/d3.v5.min.js
This defines a d3 library at the specified URL. If the scene is imported into another scene that specifies the same d3 script name, the overriding URL will be used to load the library. (The previous syntax would have tried to load both scripts, which could lead to run-time errors depending on the script's behavior.)
For backwards compatibility, any array values for scripts in a data source are converted to a mapping, with each script URL used as both the key and value. Note that array values are not accepted for the scene-level scripts, since these are an entirely new feature/syntax.
This is an update to how we handle the (currently JS-only) feature of supporting custom JS scripts. Until now, these have been specifiable at the data source level, using the
scripts
keyword, which accepts an array of URLs for external scripts. The original intention was to make these scripts available in the execution scope for the sourcetransform
feature.However, it makes sense to broaden this scope for two reasons:
transform
functions, but also anycolor
,filter
, etc. functions that may appear in the scene. (While this was an initially unintended implementation detail, it's also not an easy one to work around in practice.)color
functions, it is easier to support data visualization use cases. It also provides the ability to define scene components/fragments that include their own external script dependencies, suitable forimport
/reuse in other scenes; this use case has been desired, but previously required coupling to an assumed data source name, that might not always exist in the scene being imported into.To address the above, scripts are now also specifiable at the
scene
level. Additionally, the syntax has been revised (with backwards compatibility for existing sources) to provide better merge/import behavior, and reduce ambiguity/conflicts.Instead of an array of script URLs, scripts are now specified as a mapping, with the key being a user-defined library name, and the value being the URL. For example:
This defines a
d3
library at the specified URL. If the scene is imported into another scene that specifies the samed3
script name, the overriding URL will be used to load the library. (The previous syntax would have tried to load both scripts, which could lead to run-time errors depending on the script's behavior.)For backwards compatibility, any array values for
scripts
in a data source are converted to a mapping, with each script URL used as both the key and value. Note that array values are not accepted for thescene
-level scripts, since these are an entirely new feature/syntax.