Open tbranyen opened 10 years ago
The basic idea is that a module may need use-case specific data, outside of actual inter-module API concerns, and may even be needed for the module to complete its definition.
My normal example is a module that deals with the twitter API but needs a twitter API key. This can be passed via config, and nothing really needs this except that specific module. Example:
requirejs.config({
config: {
'twitterApi': {
'apiToken': 'SDVVscvds3822'
}
}
});
//then later in the twitterApi.js file:
define(function(require, exports, module) {
var apiToken = module.config().apiToken;
});
You could also argue that could be done via a function call to the twitterApi exports, but this way, it fits better with general, declarative configuration for the app.
It is also used by the text plugin to configure XHR behavior. This is something specific to how that loader plugin loads resources, and makes sense to do outside of the modules themselves.
Do those use cases seem justify the feature for you?
https://github.com/amdjs/amdjs-api/blob/master/CommonConfig.md#config-
While reading through the CommonConfig file, I noticed that modules can have special configuration options set. What's the use case for this? Are developers actively using this feature now? I ask because I've never seen it used in production or any third-party AMD code I've come across.
My worry is that this feature makes the baseline configuration more convoluted and pollutes the Simplified CommonJS form.
If a module needs a configuration, why not expose a mechanism within the module itself to receive such configuration? Why is this a concern of the module loader? So many questions, is there a resource I can read to get more background on this feature?