How to configure options on the loader at runtime
tomdye opened this issue · 6 comments
An issue has been raised on the loader relating to the use of crossOrigin='anonymous' on script tags which has revealed a larger question of how we could enable the configuring of options on the loader at runtime. In the above example (#39) It would be useful to enable the passing of a cross-origin-stack-trace flag which could add / remove the crossOrigin attribute.
What Dojo 1x does
https://dojotoolkit.org/reference-guide/1.10/loader/amd.html#id4
Dojo 1.x has 2 approaches that we could adopt
dojoConfigvar defined before the loader is required -loaderConfigdata-dojo-configattribute on the script tag -data-loader-config
What CurlJS does
https://github.com/cujojs/curl#very-simple-example
Curl uses a global object named curl which specifies pre-load config
What RequireJS does
http://requirejs.org/docs/api.html#config-context
RequireJS seems to allow you to pass it's custom config via the require.config function. So it is not restraining the use of this config function to only the passing of values from the AMD spec as we are https://github.com/amdjs/amdjs-api/wiki/Common-Config.
Summary
What approach do people think we should take (if any)?
For the issue we had above relating to crossOrigin calls we can remove it via a has flag which would require a custom build to re-enable. I believe this is the first issue we have came across where we may need runtime configurable config outside the scope of require.config.
Originally, I had thought that the only configuration of this type would be a build step, but the cross-origin behaviour does seem to be something that should be dynamic at run-time.
I think it is logical to have a "magic" variable that is in same scope the IIFE is called in and that we should contain that to be non-AMD configuration (e.g. only configuration specific to the Dojo Loader).
Thoughts from @bryanforbes, @edhager, @kfranqueiro would be appreciated too.
I am in favor of the Dojo 1 approach plus Kit's suggestion of making it specific to the loader. Could we only support a data-loader-config attribute on the script tag and forgo the global variable? I think the goal should be the typical in-production use of the loader will not need the loader config.
@edhager I am not opposed to that. The only problem I see is that it can be a bit of a challenge to express complex configuration values in an attribute value and if you want to strictly enforce JSON, then you have to use single quotes on the attribute value. I guess the benefit would be that it makes it clear what the configuration is for.
Coming from a real-world development team here.
The global dojoConfig object has been extremely useful for dynamically swapping between test environments e.g. dev/QA/prod. It can also be more easily manipulated by Javascript before Dojo is loaded on the page.
Being forced to do string concatenation would be a pain.
PR to address configuration via a script attribute,
With this PR we'll support both require.config and the script attribute, which seems like it'll probably be sufficient?