1

When creating AMD modules you can export whatever you like whether it be an object or a function. I vaguely recall reading a recommendation somewhere to export just one thing; the idea being "keep it small."

Using this philosophy means that one might go as far as to export single functions. And when this is coupled with the idea of composition, one will very likely use one function to build up another function. As a result, when loading a page that uses a highly-composed function one might end up asynchronously downloading a handful of little modules in order to build up a composed function.

Take underscore.js which has many functions built in. There are web pages where I just need one or two of it's functions but I find myself a little at odds with pulling the whole library in as a module just for that. I am half tempted to rewrite the one or two functions to avoid that, but that goes against the idea of reuse. Still, because underscore has several dozen function, pulling it down with an AMD loader like RequireJS is often going to mean pulling down more than necessary. If one goes to the other extreme, decomposing a library like underscore into single function modules, one can run into the aforementioned issue of pulling a couple couple handfuls of tiny modules when highly-composed functions are needed.

So what's the verdict? How does one draw the line when deciding how much to export from an AMD module? A function is the smallest composable unit. An object that gets exported is often really a namespace which offers a suite a functions, many of which won't get used.

I searched online for discussions surrounding this, but apparently I couldn't find the right search terms to locate them. If you're aware of any, please include any links where this has been discussed to support your answer.

Mario T. Lanza
  • 1,700
  • 1
  • 13
  • 22
  • `Using this philosophy means that one might go as far as to export single functions.` Sometimes you can't. If two functions depend on one another, then they can't be exported separately (an object is the most obvious case of this happening.) And sometimes two functions are used together so often, that even if you had the option of exporting them together, you wouldn't want to. Really though, making sure you don't end up with unnecessary code is a linker's job; in the absence of one, you'll just have to exercise your best judgment as to when a group of functions are used together "enough". – Doval Dec 30 '14 at 14:22
  • Even if two functions depend on each other there are ways of exporting just one function. The `define` is a closure. So you export the public function and the private function needed by the public one is not exported. Alternately, each function is exported in its own module; however, the module of the dependent function simply imports reference to its needed function. – Mario T. Lanza Dec 30 '14 at 14:26
  • 1
    I was referring to cases where both are public mutually dependent. But even when that's not the case, there's still functions that are generally used together with varying degrees of frequency. – Doval Dec 30 '14 at 14:42

1 Answers1

1

Don't worry about your exports being too fine-grained or too broad. This is what we have build-time tools for.

If you want to export many small modules (or individual functions), we have tools like RequireJS Optimizer to merge everything into a single resource. If you want to export a large namespace object with some functions that may be unused, we have tools like Closure Compiler to remove the dead code.

Organize your modules in a way you are comfortable with and have each individual script export whatever it needs to export. Let the tooling handle the rest.

Also note that while AMD allows multiple defines in a single source file, via explicitly named modules, this is not recommended. Each source file should only define a single module, and it should be anonymous. Named modules are only intended for use in a compiled script, such as those produced by Optimizer.

Hey
  • 832
  • 7
  • 13
  • If I change a module used by 10 other scripts I can't just deploy the replacement module for asynchronous inclusion, rather I would rebuild and redeploy according to dependencies. Is that right? – Mario T. Lanza Dec 30 '14 at 21:22
  • 1
    @MarioT.Lanza here's how I do it... I have some applications, one version in development, one version in production. The development version usually pulls all modules asynchronously so I know they are up to date. The production version is "compiled" using a specific version of the modules (whatever the newest version was when production was built last). – Hey Dec 30 '14 at 21:25