Skip to content
This repository has been archived by the owner on Apr 12, 2024. It is now read-only.

How about using require() and define() for modules? #9267

Closed
alexewerlof opened this issue Sep 25, 2014 · 9 comments
Closed

How about using require() and define() for modules? #9267

alexewerlof opened this issue Sep 25, 2014 · 9 comments

Comments

@alexewerlof
Copy link

The current pattern for defining (or getting) a module is rather error-prone:

angular.module('foo', ['dependencies']); //creates a module object and returns it
angular.module('foo', []); //creates a module object and returns it
angular.module('foo'); //returns a module if it exists

There are at least two issues:

  1. The same verb (module) is used for reading and writing. This is kinda similar to JQuery attr() function which can read or write depending on how it is called, but it's error prone and not very intuitive.
  2. That empty array is just ugly. Why create an extra object just to indicate that this is a special call? It is easy to miss (because empty array has a tendency in our mind to be omitted since it is "nothing" but in this context it makes a big difference).

How about using a pattern that already exists? require() and define():

angular.define('foo', ['dependencies'] )   //defines a module. The dependencies array is optional
angular.require('moduleName')        //returns the module
@Narretz
Copy link
Contributor

Narretz commented Sep 26, 2014

I like the idea, but it's really just a convenience thing. Once you understood how it works, it's not that difficult.

@Earl-Brown
Copy link

I might be missing something, but this seems like it could be implemented as a bit of a polyfill; define our own angular.define() and angular.require() - and they just alias angular.module():

angular.define = function(name, dependencies) {
  return angular.module(name, dependencies || []);
]

angular.require = function(name) { return angular.module(name);}

Am I missing something?

@gkalpak
Copy link
Member

gkalpak commented Dec 20, 2015

@Earl-Brown, the general idea sounds about right.

A couple of things to note:

  1. angular.module has an additional optional argument (configFn), so be careful when changing from angular.module to the define/require helpers. (It's rarely used though.)
  2. You will still need to use the global module() in tests (which is an alias for angular.mock.module() and not angular.module()). If you want to define similar global aliases for your define()/require() helpers, make sure you delegate to angular.mock.module() too.

@Earl-Brown
Copy link

@gkalpak:

#1 - wouldn't

angular.require = function(name, config) {
  if (typeof(config) == "function") return angular.module(name, config);
  return angular.module(name);
}

do the job, then?

#2 - good point to remember ... does it invalidate my idea?

(honest, I'm asking for information, not pushing a personal agenda...sometimes people mistake my approach for that)

@gkalpak
Copy link
Member

gkalpak commented Jan 19, 2016

(1) Nope. configFn is an optional third argument (something to be handled in the define() helper).

(2) Nope (it doesn't invalidate your idea - it's just something to take into account).

@Earl-Brown
Copy link

So ...

angular.require = function(name, config) {
  if (typeof(config) == "function") return angular.module(name, undefined, config);
  return angular.module(name);
}

@gkalpak
Copy link
Member

gkalpak commented Jan 19, 2016

No, it's something that only affects the define() helper. (See #9267 (comment) .)

Something like:

angular.require = function require(moduleName) {
  return angular.module(moduleName);
};

angular.define = function define(moduleName, deps, configFn) {
  return angular.module(moduleName, deps || [], configFn);
};

@Earl-Brown
Copy link

Ah...OK.

Thanks!

@Narretz
Copy link
Contributor

Narretz commented Feb 17, 2016

I do think that this more useful as a 3rd party module. In core, this would be just another way to do something you can already do. And the module concepts are pretty fixed and won't change in 1.x anyway.

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

No branches or pull requests

4 participants