Skip to content

wire debug

Brian Cavalier edited this page Dec 21, 2011 · 3 revisions


The wire/debug plugin outputs diagnostic information to the console as wire specs are wired as well as when contexts are destroyed. It can also trace method calls on your components at runtime, showing you call depth, arguments, return values, exceptions, etc.

During wiring, wire/debug tracks components as they pass through the lifecycle, and outputs information as each component reaches the ready state. In verbose mode (see Options below), it will output information for each step in the lifecycle for each component (extremely verbose!). If a component cannot reach the ready state for any reason (e.g., it requires an unresolvable reference), wire/debug will output error information to the console.

Tracing can be very helpful when debugging your application. After wiring, if tracing is enabled, wire/debug will track component method call chains (for all components and methods you allow via the filter and pointcut options, see below), and print out information such as the arguments, return value, and any exceptions thrown, as your application runs.

NOTE: You should not use the wire/debug plugin in production


    module: 'wire/debug',

    // verbose (Optional)
    // If set to true, even more (a LOT) info will be output.
    // Default is false if not specified.
    verbose: false,

    // timeout (Optional)
    // Milliseconds to wait for wiring to finish before reporting
    // failed components.  There may be failures caused by 3rd party
    // wire plugins and components that wire.js cannot detect.  This
    // provides a last ditch way to try to report those failures.
    // Default is 5000ms (5 seconds)
    timeout: 5000,

    // filter (Optional)
    // String or RegExp to match against a component's name.  Only
    // components whose path matches will be reported in the debug
    // diagnostic output.
    // All components will still be tracked for failures.
    // This can be useful in reducing the amount of diagnostic output and
    // focusing it on specific components.
    // Defaults to matching all components
    // Examples:
    //   filter: ".*View"
    //   filter: /.*View/
    //   filter: "[fF]oo[bB]ar"
    filter: ".*"

    // trace (Optional)
    // Enables application component tracing that will log information about component
    // method calls while your application runs.  This provides a powerful way to watch
    // and debug your application as it runs.
    // To enable full tracing, which is a LOT of information:
    trace: true
    // Or, specify options to enable more focused tracing:
    trace: {
         // filter (Optional)
         // Similar to above, can be string pattern or RegExp
         // If not specified, the general debug filter is used (see above)
         filter: ".*View",

         // pointcut (Optional)
         // Matches *method names*.  Can be used with or without specifying filter
         // When filter is not specified, this will match methods across all components.
         // For example, if all your components name their event emitters "on<Event>", e.g. "onClick"
         // you could trace all your event emitters:
         // Default: "^[^_]" (all methods not starting with '_')
         pointcut: "on.*",

         // step (Optional)
         // At what step in the wiring process should tracing start.  This can be helpful
         // if you need to trace a component during wiring.
         // Values: 'create', 'configure', 'initialize', 'ready', 'destroy'
         // NOTE: This defines when tracing *begins*.  For example, if this is set to
         // 'configure' (the default), anything that happens to components during and
         // after the configure step, until that component is destroyed, will be traced.
         // Default: 'configure'
         step: 'configure'
Something went wrong with that request. Please try again.