aura:dependency

The <aura:dependency> tag enables you to declare dependencies that can't easily be discovered by the framework.

The framework automatically tracks dependencies between definitions, such as components, defined in markup. This enables the framework to automatically send the definitions to the browser. However, if a component’s JavaScript code dynamically instantiates another component or fires an event that isn’t directly referenced in the component’s markup, use <aura:dependency> in the component’s markup to explicitly tell the framework about the dependency. Adding the <aura:dependency> tag ensures that a definition, such as a component, and its dependencies are sent to the client, when needed.

For example, adding this tag to a component marks the sampleNamespace:sampleComponent component as a dependency.

1<aura:dependency resource="markup://sampleNamespace:sampleComponent" />

Add this tag to component markup to mark the event as a dependency.

1<aura:dependency resource="markup://force:navigateToComponent" type="EVENT"/>

Use the <aura:dependency> tag if you fire an event in JavaScript code and you’re not registering the event in component markup using <aura:registerEvent>. Using an <aura:registerEvent> tag is the preferred approach.

The <aura:dependency> tag includes these system attributes.

System Attribute	Description
`resource`	The resource that the component depends on. For example, `resource="markup://sampleNamespace:sampleComponent"` refers to the sampleComponent in the sampleNamespace namespace. Use an asterisk (``) in the resource name for wildcard matching. For example, `resource="markup://sampleNamespace:"` matches everything in the namespace; `resource="markup://sampleNamespace:input"` matches everything in the namespace that starts with `input`. We don’t recommend using an asterisk (``) for wildcard matching as it tells the framework to send all matching definitions to the client. Wildcard matching usually sends more definitions than you need and leads to slower page load time. To speed up page load time, add an `<aura:dependency>` tag for each definition that’s not directly referenced in the component’s markup. Note Don’t use an asterisk (``) in the namespace portion of the resource name. For example, `resource="markup://sample:sampleComponent"` is not supported.
`type`	The type of resource that the component depends on. The default value is `COMPONENT`. Use `type=""` to match all types of resources. We don’t recommend using an asterisk (``) for wildcard matching as it tells the framework to send all matching definitions to the client. Be as selective as possible in the types of definitions that you send to the client. Note The most commonly used values are: `COMPONENT` `APPLICATION` `EVENT` Use a comma-separated list for multiple types; for example: `COMPONENT,APPLICATION`.

System Attribute

Description

resource

The resource that the component depends on. For example, resource="markup://sampleNamespace:sampleComponent" refers to the sampleComponent in the sampleNamespace namespace.

Use an asterisk (*) in the resource name for wildcard matching. For example, resource="markup://sampleNamespace:*" matches everything in the namespace; resource="markup://sampleNamespace:input*" matches everything in the namespace that starts with input.

We don’t recommend using an asterisk (*) for wildcard matching as it tells the framework to send all matching definitions to the client. Wildcard matching usually sends more definitions than you need and leads to slower page load time. To speed up page load time, add an <aura:dependency> tag for each definition that’s not directly referenced in the component’s markup.

Note

Don’t use an asterisk (*) in the namespace portion of the resource name. For example, resource="markup://sample*:sampleComponent" is not supported.

type

The type of resource that the component depends on. The default value is COMPONENT.

Use type="*" to match all types of resources.

We don’t recommend using an asterisk (*) for wildcard matching as it tells the framework to send all matching definitions to the client. Be as selective as possible in the types of definitions that you send to the client.

Note

The most commonly used values are:

COMPONENT
APPLICATION
EVENT

Use a comma-separated list for multiple types; for example: COMPONENT,APPLICATION.

Lightning Components Developer Guide

aura:dependency

See Also: