Couch Potato Components

A typical Couch Potato component might look something like this:

define(['app', 'lodash', 'myService', function(app, _) {

  app.registerController('myController', ['$scope', '$timeout', '$myService',

    function($scope, $timeout, $myService) {

      $scope.concattedAlphas = '';
      _.each(['a', 'b', 'c'], function(val) {
        $scope.concattedAlphas += val;
      });

      $timeout(
        function() {
          $scope.aValueFromMyService = $myService.aValue;
        },
        1000
      );
    }
  ]);
});

That really silly controller depends on the AMD modules "lodash" and "myService".

lodash is just the lodash utility library. It knows nothing about Couch Potato (or Angular) and doesn't need to. This is regular RequireJS here.

On the other hand, "myService" is itself (or at least might be) a Couch Potato AMD module. It is defined similarly to the one we're defining here (i.e. app.registerService(...)). Note the use of the word "might". It's also entirely possible that myService was configured as a non-lazy component. In fact, when you use Couch Potato and you define components as modules like the one above, you are in control of whether they end up being loaded lazily or built into your application as part of a RequireJS compilation/minification build step (e.g in a grunt task).

Both modules are required as part of requiring myController. In practical terms, this means that:

In this way, Couch Potato components can depend on each other. This follows the "AMD way" of expressing dependencies, so that users of myController (e.g. routes or states) are not forced to know what components the controller requires -- the controller module is tracking that, and RequireJS is ensuring that everything it needs is prepped and ready to go.

You may have noticed that we have not discussed the "app" dependency. It's the application module. It deserves some discussion.

These AMD modules run outside the context of Angular. There needs to be a way to tie back into your app in order to register the component with Angular. The application module is the bridge.

It turns out that in order to make it possible for Couch Potato to do its work, we've prepared the application module with some sugary functions that expose the Couch Potato services. Later, we'll see what those sugary functions look like. For now, just know that app.registerController is a function that's using Couch Potato to get the controller registered.

The rest of the code in this module is just standard Angular stuff. The only real difference is the define function that wraps it and the call to app.registerController instead of app.controller.

Ok, with components out of the way, let's loop back and look at the app module again to understand how it's enabling this app.registerController business. Read about setting up the app module.