Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Module configuration within CommonConfig. #19

Open
tbranyen opened this issue Apr 29, 2014 · 1 comment
Open

Module configuration within CommonConfig. #19

tbranyen opened this issue Apr 29, 2014 · 1 comment

Comments

@tbranyen
Copy link

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?

@jrburke
Copy link
Contributor

jrburke commented May 1, 2014

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants