Opened 7 years ago
Last modified 4 years ago
#17440 new defect
dojo/has!condition sometimes executes before dojoConfig processed
Reported by: | bill | Owned by: | |
---|---|---|---|
Priority: | undecided | Milestone: | 1.15 |
Component: | Core | Version: | 1.9.1 |
Keywords: | Cc: | Clement Mathieu | |
Blocked By: | Blocking: |
Description
dojo/_base/config.js parses that djConfig global variable, adding the specified has flags in a case like:
djConfig = { has : { "dojo-bidi" : true } };
However, a module dependency like dojo/has!dojo-bidi?myModule
can execute before the code in dojo/_base/config.js has executed, thus returning null instead of loading the specified module. Actually there's no guarantee that the code in dojo/_base/config will load at all. At least when using RequireJS as a loader; I haven't looked into what dojo.js does.
A workaround is to define all of our modules to explicitly load dojo/_base/config first:
require(["dojo/_base/config"], function(){ define([ ... "dojo/has!dojo-bidi?myModule",
However that's pretty onerous and I'm not sure if it would work with the builder.
Change History (7)
comment:1 Changed 7 years ago by
comment:2 Changed 7 years ago by
dojo/_base/config
already depends on dojo/has
, so setting up the reverse dependency would give us a circular dependency.
comment:3 Changed 7 years ago by
Right, it's a true circular dependency. I thought about just putting all the code from config.js into has.js, but config.js has a comment indicating that users may override the module in a build:
By defining user configuration as a module value, an entire configuration can be specified in a build, thereby eliminating the need for sniffing and or explicitly setting in the global variable dojoConfig. Also, when multiple instances of dojo exist in a single application, each will necessarily be located at an unique absolute module identifier as given by the package configuration. Implementing configuration as a module allows for specifying unique, per-instance configurations.
comment:4 Changed 7 years ago by
Cc: | Clement Mathieu added |
---|
comment:5 Changed 7 years ago by
Perhaps we should stop depending on dojoConfig altogether and instead use standard AMD module configuration setting. As documented on stack overflow (and probably other better places), we should be able to do something like:
var require = { config: { 'dojo/has': { 'dojo-bidi': true } } };
The code in dojo/has.js is actually already setup to handle this. Unfortunately it's inside an if() block that doesn't normally execute:
if(!has("dojo-has-api")){ ... cache = (module.config && module.config()) || {};
The code that runs instead is in dojo.js:
hasCache = has.cache = defaultConfig.hasCache;
Actually, I guess if we just fix dojo.js so that hasCache is populated from userConfig in addition to defaultConfig, things should start working.
comment:6 Changed 5 years ago by
Milestone: | tbd → 1.12 |
---|
comment:7 Changed 4 years ago by
Milestone: | 1.13 → 1.15 |
---|
Ticket planning... move current 1.13 tickets out to 1.15 to make it easier to move tickets into the 1.13 milestone.
is it naive to think that adding dojo/_base/config as a dependency to dojo/has will fix this? i haven't looked into it but it sounds like that would do it.