Appcelerator Blog

The Leading Resource for All Things Mobile

CommonJS Module Guide for 1.8

0 Flares 0 Flares ×
As many of you know, as a platform we’re embracing the CommonJS module specification as the preferred means of structuring JavaScript code in Titanium Mobile applications. To help developers properly use our implementation of this spec, we’ve included a guide for using CommonJS modules in Titanium 1.8 in the wiki. If you are using CommonJS modules in your applications, this guide should help you understand how we intend the CommonJS module implementation in Titanium to be used. Thanks!
0 Flares Twitter 0 Facebook 0 Google+ 0 LinkedIn 0 Email -- 0 Flares ×


  1. Mark Burggraf

    CommonJS modules are definitely the way to go — what a huge boon to code organization.

    Has the 1.8 release solved the issues with CommonJS naming problems, namely that public methods cannot begin with “set”, “get”, or “init”?

    It’s a major pain when you spend hours debugging your seemingly-perfect code just to find out that:

    exports.getMyItem = getMyItem;

    is not valid, but:

    exports.GetMyItem = GetMyItem;

    is fine.

  2. Mark Burggraf

    I ran a quick test, and indeed — you can now create methods that begin with get and set. Very cool. Good work, guys.

  3. that’s a good point, Mark. Thanks for the comment!

  4. I still don’t get working functions using get/set/init prefixes. ‘exports.setArticle = function(){};’ is not called, putting a ‘_’ before set, and it works…

  5. Oh wait, I’m not using it on the exports object, I’m attaching my function to a view, but that should also work (right?).

    • Kevin Whinnery

      @Gertjan Unfortunately, that’s not supported behavior. “Native proxy” objects (like the one you get back from Ti.UI.createView) have special magic set up on them to look for calls to setXXX, which will make a call over the bridge into native land to update properties on the native object bound to the JavaScript object you’re modifying. Any custom logic you have set up on those objects will not work if it’s named setXXX or similar. This is true of any function or property with a native equivalent.

      This is still a relatively new piece of knowledge in the Titanium app dev world – today, it can’t be considered safe to add properties to proxy objects. That stinks for a variety of reasons, but the way to work around that is to wrap any custom components which require new functionality added to a View in a plain JavaScript object. We’re working on a few samples which use this technique for the Titanium week webinars.

  6. Can’t wait for the webinars and the Titan Tracks app source code. Most of the real knowledge on how to sucessfully build Apps comes from these comments on the blog and the Q&A section… time to change that. Keep up the good work.

  7. Tim

    Does this latest update negate the need to call the monkeypatch script?

    • Kevin Whinnery

      @Tim yes, my monkeypatch script is no longer needed. Titanium’s module API now supports caching modules and assigning an object directly to module.exports, so the problems addressed by it are moot.

  8. Tim

    Cool deal. So require_once is moot as well? Just simply use require(module.js) and it will be loaded only once?

  9. Kevin Whinnery

    @Tim yes, that is no longer needed as well.

  10. Rich

    Kevin, previously my app was doing DB access via your CRUD example here

    With 1.8 and new titanium version I am trying to convert to modules. I can’t get the DB access to work. Original code looked like this.

    var db = (function() {
    var api = {};
    //…all oteher DB CRUD code bla, bla, bla
    return api;

    I have tried adding module.exports = db; to the .js file as well as changing around the CRUD code to start end like:

    function db() {
    //…all oteher DB CRUD code bla, bla, bla
    module.exports = db;

    But nothing seems to work app always crashes saying “Uncaught reference error: db is not defined”

    I have used all combinations of require and Ti.include that I can think of.

    Any ideas, Thanks!

    • Kevin Whinnery

      @Rich assigning the db variable to module.exports should be a valid way of wrapping that module in a CommonJS module. I wonder if the issue isn’t elsewhere in your project – I think we’d need to look at a complete example of what you’re trying to do in a Q&A post.

  11. Rich

    Oops…forget that one above

    Kevin, please check this Q&A out. Thanks!

  12. Zsombor Papp

    Hi Kevin,

    how do the Titanium project templates fit into this? Specifically, I am wondering about this construct:

    function ApplicationWindow() {

    return self;

    new ApplicationWindow().open();

    This to me seems like a strange mix of the pseudo-classical and the factory code pattern.

Comments are closed.

Sign up for updates!

Become a mobile leader. Take the first step to scale mobile innovation throughout your enterprise.
Get in touch
computer and tablet showing Appcelerator software
Start free, grow from there.
0 Flares Twitter 0 Facebook 0 Google+ 0 LinkedIn 0 Email -- 0 Flares ×