Class: SC.Module


Extends SC.Object.

SC.Module is responsible for dynamically loading in JavaScript and other resources. These packages of code and resources, called bundles, can be loaded (i.e. parsed into actual JavaScript) by your application once it has finished launching, allowing you to reduce the time taken for it to load and launch.

To separate code into bundles, create a directory called modules within your application (or framework). For example, a directory structure for an app with two modules and a framework with one module would be,

my_project/
  apps/
    my_app/
      modules/
        settings_pane/
          ... all code in the settings_pane bundle
        sign_up_pane/
          ... all code in the sign_up_pane bundle
  frameworks/
    my_framework/
      modules/
        framework_config/
          ... all code in the framework_config bundle

Once you've got your modules defined, you need to decide how they should be made available to your application. There are three different loading styles that we can use for modules, 'inlined_modules', 'prefetched_modules', or 'deferred_modules', each with its own strengths and weaknesses.

This is specified in the Buildfile for your application or project. For example,

config :my_app,
  :inlined_modules => [:sign_up_pane],
  :prefetched_modules => [:settings_pane],
  :deferred_modules => [:'my_framework/framework_config']

Inlined modules include the module as an unparsed String within the main application code. This means inlined modules are guaranteed to be available within a loaded application, making them the best option for supporting offline mode. They, however, add to the initial load time of the main application code and take up space (less than when parsed) in memory.

Prefetched modules store the module as an unparsed String in a separate file from the main application code that is lazily loaded. This means that prefetched modules are not guaranteed to be available within a freshly loaded application. Instead, SproutCore will lazily fetch these modules individually when it detects that the application is idle, which means that the initial load time of the main application is improved, but importing a prefetched module may take slightly longer if it hasn't yet been fetched and going offline before a prefetched module is loaded will cause the module load to fail. Therefore, this loading style is most suitable for online-only applications that want to optimize their loading speed, but don't want noticeable delays when modules are first accessed.

Deferred modules store the module as a regular JavaScript file separate from the main application code. This means that deferred modules are not available within a loaded application until manually imported. Because the deferred module may never be needed and thus never be loaded, these modules are best for improving the load time and memory usage of an application. However, thesemodules are absolutely not suitable for offline mode and because they will not be prefetched, they take slightly longer to initially import than do prefetched modules.

To recap, the different loading styles and their benefits and costs are,

inlined_modules:

prefetched_modules:

deferred_modules:

Defined in: module.js

Field Summary

Instance Methods

Field Detail

methodsForSuspend
A list of the methods to temporarily disable (and buffer calls for) when we are suspended.

Instance Method Detail

isModuleReady(moduleName)

Returns YES if the module is ready; NO if it is not loaded or its dependencies have not yet loaded.

Parameters:
moduleName String
the name of the module to check
Returns:
Boolean
loadModule(moduleName, target, method)

Asynchronously loads a module if it is not already loaded. If you pass a function, or a target and action, it will be called once the module has finished loading.

If the module you request has dependencies (as specified in the Buildfile) that are not yet loaded, it will load them first before executing the requested module.

Parameters:
moduleName
{String}
target
{Function}
method
{Function}
Returns:
Boolean
YES if already loaded, NO otherwise
resume()

Call this in order to resume normal behavior of the methods here, and to finally perform any calls that may have occurred during suspension. Calls will run in the order they were received.

suspend()
Call this in order to prevent expensive tasks from occurring at inopportune times.
Documentation generated by JsDoc Toolkit 2.4.0 on Wed Apr 08 2015 10:02:21 GMT-0600 (CST)