mirror of
https://github.com/angular/angular
synced 2026-05-24 09:28:37 +00:00
docs: simplify docs-code header by removing paths and keeping only file name and info
(cherry picked from commit 374c36d810)
This commit is contained in:
Shuaib Hasan Akib
Jessica Janiuk
parent
72b19d869d
commit
3686987622
8 changed files with 119 additions and 119 deletions
|
|
@ -46,9 +46,9 @@ export class DragDropExample {}
|
|||
You can make any element draggable by adding the `cdkDrag` directive. By default, all draggable elements support free dragging.
|
||||
|
||||
<docs-code-multifile preview path="adev/src/content/examples/drag-drop/src/overview/app/app.component.ts">
|
||||
<docs-code header="app/app.component.html" path="adev/src/content/examples/drag-drop/src/overview/app/app.component.html"/>
|
||||
<docs-code header="app/app.component.ts" path="adev/src/content/examples/drag-drop/src/overview/app/app.component.ts"/>
|
||||
<docs-code header="app/app.component.css" path="adev/src/content/examples/drag-drop/src/overview/app/app.component.css"/>
|
||||
<docs-code header="app.component.html" path="adev/src/content/examples/drag-drop/src/overview/app/app.component.html"/>
|
||||
<docs-code header="app.component.ts" path="adev/src/content/examples/drag-drop/src/overview/app/app.component.ts"/>
|
||||
<docs-code header="app.component.css" path="adev/src/content/examples/drag-drop/src/overview/app/app.component.css"/>
|
||||
</docs-code-multifile>
|
||||
|
||||
## Create a list of reorderable draggable elements
|
||||
|
|
@ -58,9 +58,9 @@ Add the `cdkDropList` directive to a parent element to group draggable elements
|
|||
The drag and drop directives don't update your data model. To update the data model, listen to the `cdkDropListDropped` event (once the user finishes dragging) and update the data model manually.
|
||||
|
||||
<docs-code-multifile preview path="adev/src/content/examples/drag-drop/src/sorting/app/app.component.ts">
|
||||
<docs-code header="app/app.component.html" path="adev/src/content/examples/drag-drop/src/sorting/app/app.component.html"/>
|
||||
<docs-code header="app/app.component.ts" path="adev/src/content/examples/drag-drop/src/sorting/app/app.component.ts"/>
|
||||
<docs-code header="app/app.component.css" path="adev/src/content/examples/drag-drop/src/sorting/app/app.component.css"/>
|
||||
<docs-code header="app.component.html" path="adev/src/content/examples/drag-drop/src/sorting/app/app.component.html"/>
|
||||
<docs-code header="app.component.ts" path="adev/src/content/examples/drag-drop/src/sorting/app/app.component.ts"/>
|
||||
<docs-code header="app.component.css" path="adev/src/content/examples/drag-drop/src/sorting/app/app.component.css"/>
|
||||
</docs-code-multifile>
|
||||
|
||||
You can use the `CDK_DROP_LIST` injection token that can be used to reference instances of `cdkDropList`. For more information see the [dependency injection guide](https://angular.dev/guide/di) and the [drop list injection token API](api/cdk/drag-drop/CDK_DROP_LIST).
|
||||
|
|
@ -85,9 +85,9 @@ The `cdkDropListConnectedTo` directive works both with a direct reference to ano
|
|||
</docs-code>
|
||||
|
||||
<docs-code-multifile preview path="adev/src/content/examples/drag-drop/src/connected-sorting/app/app.component.ts">
|
||||
<docs-code header="app/app.component.html" path="adev/src/content/examples/drag-drop/src/connected-sorting/app/app.component.html"/>
|
||||
<docs-code header="app/app.component.ts" path="adev/src/content/examples/drag-drop/src/connected-sorting/app/app.component.ts"/>
|
||||
<docs-code header="app/app.component.css" path="adev/src/content/examples/drag-drop/src/connected-sorting/app/app.component.css"/>
|
||||
<docs-code header="app.component.html" path="adev/src/content/examples/drag-drop/src/connected-sorting/app/app.component.html"/>
|
||||
<docs-code header="app.component.ts" path="adev/src/content/examples/drag-drop/src/connected-sorting/app/app.component.ts"/>
|
||||
<docs-code header="app.component.css" path="adev/src/content/examples/drag-drop/src/connected-sorting/app/app.component.css"/>
|
||||
</docs-code-multifile>
|
||||
|
||||
Use the `cdkDropListGroup` directive if you have an unknown number of connected drop lists to set up the connection automatically. Any new `cdkDropList` that is added under a group automatically connects to all other lists.
|
||||
|
|
@ -102,9 +102,9 @@ Use the `cdkDropListGroup` directive if you have an unknown number of connected
|
|||
</docs-code>
|
||||
|
||||
<docs-code-multifile preview path="adev/src/content/examples/drag-drop/src/connected-sorting-group/app/app.component.ts">
|
||||
<docs-code header="app/app.component.html" path="adev/src/content/examples/drag-drop/src/connected-sorting-group/app/app.component.html"/>
|
||||
<docs-code header="app/app.component.ts" path="adev/src/content/examples/drag-drop/src/connected-sorting-group/app/app.component.ts"/>
|
||||
<docs-code header="app/app.component.css" path="adev/src/content/examples/drag-drop/src/connected-sorting-group/app/app.component.css"/>
|
||||
<docs-code header="app.component.html" path="adev/src/content/examples/drag-drop/src/connected-sorting-group/app/app.component.html"/>
|
||||
<docs-code header="app.component.ts" path="adev/src/content/examples/drag-drop/src/connected-sorting-group/app/app.component.ts"/>
|
||||
<docs-code header="app.component.css" path="adev/src/content/examples/drag-drop/src/connected-sorting-group/app/app.component.css"/>
|
||||
</docs-code-multifile>
|
||||
|
||||
You can use the `CDK_DROP_LIST_GROUP` injection token that can be used to reference instances of `cdkDropListGroup`. For more information see the [dependency injection guide](https://angular.dev/guide/di) and the [drop list group injection token API](api/cdk/drag-drop/CDK_DROP_LIST_GROUP).
|
||||
|
|
@ -114,9 +114,9 @@ You can use the `CDK_DROP_LIST_GROUP` injection token that can be used to refere
|
|||
By default, a user can move `cdkDrag` elements from one container into another connected container. For more fine-grained control over which elements can be dropped into a container, use `cdkDropListEnterPredicate`. Angular calls the predicate whenever a draggable element enters a new container. Depending on whether the predicate returns true or false, the item may or may not be allowed into the new container.
|
||||
|
||||
<docs-code-multifile preview path="adev/src/content/examples/drag-drop/src/enter-predicate/app/app.component.ts">
|
||||
<docs-code header="app/app.component.html" path="adev/src/content/examples/drag-drop/src/enter-predicate/app/app.component.html"/>
|
||||
<docs-code header="app/app.component.ts" path="adev/src/content/examples/drag-drop/src/enter-predicate/app/app.component.ts"/>
|
||||
<docs-code header="app/app.component.css" path="adev/src/content/examples/drag-drop/src/enter-predicate/app/app.component.css"/>
|
||||
<docs-code header="app.component.html" path="adev/src/content/examples/drag-drop/src/enter-predicate/app/app.component.html"/>
|
||||
<docs-code header="app.component.ts" path="adev/src/content/examples/drag-drop/src/enter-predicate/app/app.component.ts"/>
|
||||
<docs-code header="app.component.css" path="adev/src/content/examples/drag-drop/src/enter-predicate/app/app.component.css"/>
|
||||
</docs-code-multifile>
|
||||
|
||||
## Attach data
|
||||
|
|
@ -140,9 +140,9 @@ You can associate some arbitrary data with both `cdkDrag` and `cdkDropList` by s
|
|||
By default, the user can drag the entire `cdkDrag` element to move it around. To restrict the user to only be able to do so using a handle element, add the `cdkDragHandle` directive to an element inside of `cdkDrag`. You can have as many `cdkDragHandle` elements as you want.
|
||||
|
||||
<docs-code-multifile preview path="adev/src/content/examples/drag-drop/src/custom-handle/app/app.component.ts">
|
||||
<docs-code header="app/app.component.html" path="adev/src/content/examples/drag-drop/src/custom-handle/app/app.component.html"/>
|
||||
<docs-code header="app/app.component.ts" path="adev/src/content/examples/drag-drop/src/custom-handle/app/app.component.ts"/>
|
||||
<docs-code header="app/app.component.css" path="adev/src/content/examples/drag-drop/src/custom-handle/app/app.component.css"/>
|
||||
<docs-code header="app.component.html" path="adev/src/content/examples/drag-drop/src/custom-handle/app/app.component.html"/>
|
||||
<docs-code header="app.component.ts" path="adev/src/content/examples/drag-drop/src/custom-handle/app/app.component.ts"/>
|
||||
<docs-code header="app.component.css" path="adev/src/content/examples/drag-drop/src/custom-handle/app/app.component.css"/>
|
||||
</docs-code-multifile>
|
||||
|
||||
You can use the `CDK_DRAG_HANDLE` injection token that can be used to reference instances of `cdkDragHandle`. For more information see the [dependency injection guide](https://angular.dev/guide/di) and the [drag handle injection token API](api/cdk/drag-drop/CDK_DRAG_HANDLE).
|
||||
|
|
@ -156,9 +156,9 @@ To customize the preview, provide a custom template via `*cdkDragPreview`. The c
|
|||
The cloned element removes its id attribute in order to avoid having multiple elements with the same id on the page. This will cause any CSS that targets that id not to be applied.
|
||||
|
||||
<docs-code-multifile preview path="adev/src/content/examples/drag-drop/src/custom-preview/app/app.component.ts">
|
||||
<docs-code header="app/app.component.html" path="adev/src/content/examples/drag-drop/src/custom-preview/app/app.component.html"/>
|
||||
<docs-code header="app/app.component.ts" path="adev/src/content/examples/drag-drop/src/custom-preview/app/app.component.ts"/>
|
||||
<docs-code header="app/app.component.css" path="adev/src/content/examples/drag-drop/src/custom-preview/app/app.component.css"/>
|
||||
<docs-code header="app.component.html" path="adev/src/content/examples/drag-drop/src/custom-preview/app/app.component.html"/>
|
||||
<docs-code header="app.component.ts" path="adev/src/content/examples/drag-drop/src/custom-preview/app/app.component.ts"/>
|
||||
<docs-code header="app.component.css" path="adev/src/content/examples/drag-drop/src/custom-preview/app/app.component.css"/>
|
||||
</docs-code-multifile>
|
||||
|
||||
You can use the `CDK_DRAG_PREVIEW` injection token that can be used to reference instances of `cdkDragPreview`. For more information see the [dependency injection guide](https://angular.dev/guide/di) and the [drag preview injection token API](api/cdk/drag-drop/CDK_DRAG_PREVIEW).
|
||||
|
|
@ -182,9 +182,9 @@ Alternatively, you can modify the `CDK_DRAG_CONFIG` injection token to update `p
|
|||
While a `cdkDrag` element is being dragged, the directive creates a placeholder element that shows where the element will be placed when dropped. By default, the placeholder is a clone of the element that is being dragged. You can replace the placeholder with a custom one using the `*cdkDragPlaceholder` directive:
|
||||
|
||||
<docs-code-multifile preview path="adev/src/content/examples/drag-drop/src/custom-placeholder/app/app.component.ts">
|
||||
<docs-code header="app/app.component.html" path="adev/src/content/examples/drag-drop/src/custom-placeholder/app/app.component.html"/>
|
||||
<docs-code header="app/app.component.ts" path="adev/src/content/examples/drag-drop/src/custom-placeholder/app/app.component.ts"/>
|
||||
<docs-code header="app/app.component.css" path="adev/src/content/examples/drag-drop/src/custom-placeholder/app/app.component.css"/>
|
||||
<docs-code header="app.component.html" path="adev/src/content/examples/drag-drop/src/custom-placeholder/app/app.component.html"/>
|
||||
<docs-code header="app.component.ts" path="adev/src/content/examples/drag-drop/src/custom-placeholder/app/app.component.ts"/>
|
||||
<docs-code header="app.component.css" path="adev/src/content/examples/drag-drop/src/custom-placeholder/app/app.component.css"/>
|
||||
</docs-code-multifile>
|
||||
|
||||
You can use the `CDK_DRAG_PLACEHOLDER` injection token that can be used to reference instances of `cdkDragPlaceholder`. For more information see the [dependency injection guide](https://angular.dev/guide/di) and the [drag placeholder injection token API](api/cdk/drag-drop/CDK_DRAG_PLACEHOLDER).
|
||||
|
|
@ -196,9 +196,9 @@ Set the `cdkDragRootElement` attribute if there's an element that you want to ma
|
|||
The attribute accepts a selector and looks up the DOM until it finds an element that matches the selector. If an element is found, it becomes draggable. This is useful for cases such as making a dialog draggable.
|
||||
|
||||
<docs-code-multifile preview path="adev/src/content/examples/drag-drop/src/root-element/app/app.component.ts">
|
||||
<docs-code header="app/app.component.html" path="adev/src/content/examples/drag-drop/src/root-element/app/app.component.html"/>
|
||||
<docs-code header="app/app.component.ts" path="adev/src/content/examples/drag-drop/src/root-element/app/app.component.ts"/>
|
||||
<docs-code header="app/app.component.css" path="adev/src/content/examples/drag-drop/src/root-element/app/app.component.css"/>
|
||||
<docs-code header="app.component.html" path="adev/src/content/examples/drag-drop/src/root-element/app/app.component.html"/>
|
||||
<docs-code header="app.component.ts" path="adev/src/content/examples/drag-drop/src/root-element/app/app.component.ts"/>
|
||||
<docs-code header="app.component.css" path="adev/src/content/examples/drag-drop/src/root-element/app/app.component.css"/>
|
||||
</docs-code-multifile>
|
||||
|
||||
Alternatively, you can modify the `CDK_DRAG_CONFIG` injection token to update `rootElementSelector` within the config. For more information see the [dependency injection guide](https://angular.dev/guide/di), [drag config injection token API](api/cdk/drag-drop/CDK_DRAG_CONFIG), and the [drag drop config API](api/cdk/drag-drop/DragDropConfig).
|
||||
|
|
@ -208,9 +208,9 @@ Alternatively, you can modify the `CDK_DRAG_CONFIG` injection token to update `r
|
|||
By default, `cdkDrag` elements not in a `cdkDropList` move from their normal DOM position only when a user manually moves the element. Use the `cdkDragFreeDragPosition` input to explicitly set the element’s position. A common use case for this is restoring a draggable element's position after a user has navigated away and then returned.
|
||||
|
||||
<docs-code-multifile preview path="adev/src/content/examples/drag-drop/src/free-drag-position/app/app.component.ts">
|
||||
<docs-code header="app/app.component.html" path="adev/src/content/examples/drag-drop/src/free-drag-position/app/app.component.html"/>
|
||||
<docs-code header="app/app.component.ts" path="adev/src/content/examples/drag-drop/src/free-drag-position/app/app.component.ts"/>
|
||||
<docs-code header="app/app.component.css" path="adev/src/content/examples/drag-drop/src/free-drag-position/app/app.component.css"/>
|
||||
<docs-code header="app.component.html" path="adev/src/content/examples/drag-drop/src/free-drag-position/app/app.component.html"/>
|
||||
<docs-code header="app.component.ts" path="adev/src/content/examples/drag-drop/src/free-drag-position/app/app.component.ts"/>
|
||||
<docs-code header="app.component.css" path="adev/src/content/examples/drag-drop/src/free-drag-position/app/app.component.css"/>
|
||||
</docs-code-multifile>
|
||||
|
||||
### Restrict movement within an element
|
||||
|
|
@ -218,9 +218,9 @@ By default, `cdkDrag` elements not in a `cdkDropList` move from their normal DOM
|
|||
To stop the user from being able to drag a `cdkDrag` element outside of another element, pass a CSS selector to the `cdkDragBoundary` attribute. This attribute accepts a selector and looks up the DOM until it finds an element that matches it. If a match is found, the element becomes the boundary that the draggable element can't be dragged outside of `cdkDragBoundary` can also be used when `cdkDrag` is placed inside a `cdkDropList`.
|
||||
|
||||
<docs-code-multifile preview path="adev/src/content/examples/drag-drop/src/boundary/app/app.component.ts">
|
||||
<docs-code header="app/app.component.html" path="adev/src/content/examples/drag-drop/src/boundary/app/app.component.html"/>
|
||||
<docs-code header="app/app.component.ts" path="adev/src/content/examples/drag-drop/src/boundary/app/app.component.ts"/>
|
||||
<docs-code header="app/app.component.css" path="adev/src/content/examples/drag-drop/src/boundary/app/app.component.css"/>
|
||||
<docs-code header="app.component.html" path="adev/src/content/examples/drag-drop/src/boundary/app/app.component.html"/>
|
||||
<docs-code header="app.component.ts" path="adev/src/content/examples/drag-drop/src/boundary/app/app.component.ts"/>
|
||||
<docs-code header="app.component.css" path="adev/src/content/examples/drag-drop/src/boundary/app/app.component.css"/>
|
||||
</docs-code-multifile>
|
||||
|
||||
Alternatively, you can modify the `CDK_DRAG_CONFIG` injection token to update boundaryElement within the config. For more information see the [dependency injection guide](https://angular.dev/guide/di), [drag config injection token API](api/cdk/drag-drop/CDK_DRAG_CONFIG), and the [drag drop config API](api/cdk/drag-drop/DragDropConfig).
|
||||
|
|
@ -230,9 +230,9 @@ Alternatively, you can modify the `CDK_DRAG_CONFIG` injection token to update bo
|
|||
By default, `cdkDrag` allows free movement in all directions. To restrict dragging to a specific axis, set `cdkDragLockAxis` to either "x" or "y"on `cdkDrag`. To restrict dragging for multiple draggable elements within `cdkDropList`, set `cdkDropListLockAxis` on `cdkDropList` instead.
|
||||
|
||||
<docs-code-multifile preview path="adev/src/content/examples/drag-drop/src/axis-lock/app/app.component.ts">
|
||||
<docs-code header="app/app.component.html" path="adev/src/content/examples/drag-drop/src/axis-lock/app/app.component.html"/>
|
||||
<docs-code header="app/app.component.ts" path="adev/src/content/examples/drag-drop/src/axis-lock/app/app.component.ts"/>
|
||||
<docs-code header="app/app.component.css" path="adev/src/content/examples/drag-drop/src/axis-lock/app/app.component.css"/>
|
||||
<docs-code header="app.component.html" path="adev/src/content/examples/drag-drop/src/axis-lock/app/app.component.html"/>
|
||||
<docs-code header="app.component.ts" path="adev/src/content/examples/drag-drop/src/axis-lock/app/app.component.ts"/>
|
||||
<docs-code header="app.component.css" path="adev/src/content/examples/drag-drop/src/axis-lock/app/app.component.css"/>
|
||||
</docs-code-multifile>
|
||||
|
||||
Alternatively, you can modify the `CDK_DRAG_CONFIG` injection token to update `lockAxis` within the config. For more information see the [dependency injection guide](https://angular.dev/guide/di), [drag config injection token API](api/cdk/drag-drop/CDK_DRAG_CONFIG), and the [drag drop config API](api/cdk/drag-drop/DragDropConfig).
|
||||
|
|
@ -244,9 +244,9 @@ By default when the user puts their pointer down on a `cdkDrag`, the dragging se
|
|||
You can delay the dragging sequence using the `cdkDragStartDelay` input. The input waits for the user to hold down their pointer for the specified number of milliseconds before dragging the element.
|
||||
|
||||
<docs-code-multifile preview path="adev/src/content/examples/drag-drop/src/delay-drag/app/app.component.ts">
|
||||
<docs-code header="app/app.component.html" path="adev/src/content/examples/drag-drop/src/delay-drag/app/app.component.html"/>
|
||||
<docs-code header="app/app.component.ts" path="adev/src/content/examples/drag-drop/src/delay-drag/app/app.component.ts"/>
|
||||
<docs-code header="app/app.component.css" path="adev/src/content/examples/drag-drop/src/delay-drag/app/app.component.css"/>
|
||||
<docs-code header="app.component.html" path="adev/src/content/examples/drag-drop/src/delay-drag/app/app.component.html"/>
|
||||
<docs-code header="app.component.ts" path="adev/src/content/examples/drag-drop/src/delay-drag/app/app.component.ts"/>
|
||||
<docs-code header="app.component.css" path="adev/src/content/examples/drag-drop/src/delay-drag/app/app.component.css"/>
|
||||
</docs-code-multifile>
|
||||
|
||||
Alternatively, you can modify the `CDK_DRAG_CONFIG` injection token to update dragStartDelay within the config. For more information see the [dependency injection guide](https://angular.dev/guide/di), [drag config injection token API](api/cdk/drag-drop/CDK_DRAG_CONFIG), and the [drag drop config API](api/cdk/drag-drop/DragDropConfig).
|
||||
|
|
@ -256,9 +256,9 @@ Alternatively, you can modify the `CDK_DRAG_CONFIG` injection token to update dr
|
|||
If you want to disable dragging for a particular drag item, set the `cdkDragDisabled` input on a `cdkDrag` item to true or false. You can disable an entire list using the `cdkDropListDisabled` input on a `cdkDropList`. It is also possible to disable a specific handle via `cdkDragHandleDisabled` on `cdkDragHandle`.
|
||||
|
||||
<docs-code-multifile preview path="adev/src/content/examples/drag-drop/src/disable-drag/app/app.component.ts">
|
||||
<docs-code header="app/app.component.html" path="adev/src/content/examples/drag-drop/src/disable-drag/app/app.component.html"/>
|
||||
<docs-code header="app/app.component.ts" path="adev/src/content/examples/drag-drop/src/disable-drag/app/app.component.ts"/>
|
||||
<docs-code header="app/app.component.css" path="adev/src/content/examples/drag-drop/src/disable-drag/app/app.component.css"/>
|
||||
<docs-code header="app.component.html" path="adev/src/content/examples/drag-drop/src/disable-drag/app/app.component.html"/>
|
||||
<docs-code header="app.component.ts" path="adev/src/content/examples/drag-drop/src/disable-drag/app/app.component.ts"/>
|
||||
<docs-code header="app.component.css" path="adev/src/content/examples/drag-drop/src/disable-drag/app/app.component.css"/>
|
||||
</docs-code-multifile>
|
||||
|
||||
Alternatively, you can modify the `CDK_DRAG_CONFIG` injection token to update `draggingDisabled` within the config. For more information see the [dependency injection guide](https://angular.dev/guide/di), [drag config injection token API](api/cdk/drag-drop/CDK_DRAG_CONFIG), and the [drag drop config API](api/cdk/drag-drop/DragDropConfig).
|
||||
|
|
@ -270,9 +270,9 @@ Alternatively, you can modify the `CDK_DRAG_CONFIG` injection token to update `d
|
|||
By default, the `cdkDropList` directive assumes lists are vertical. This can be changed by setting the `cdkDropListOrientation` property to horizontal.
|
||||
|
||||
<docs-code-multifile preview path="adev/src/content/examples/drag-drop/src/horizontal-sorting/app/app.component.ts">
|
||||
<docs-code header="app/app.component.html" path="adev/src/content/examples/drag-drop/src/horizontal-sorting/app/app.component.html"/>
|
||||
<docs-code header="app/app.component.ts" path="adev/src/content/examples/drag-drop/src/horizontal-sorting/app/app.component.ts"/>
|
||||
<docs-code header="app/app.component.css" path="adev/src/content/examples/drag-drop/src/horizontal-sorting/app/app.component.css"/>
|
||||
<docs-code header="app.component.html" path="adev/src/content/examples/drag-drop/src/horizontal-sorting/app/app.component.html"/>
|
||||
<docs-code header="app.component.ts" path="adev/src/content/examples/drag-drop/src/horizontal-sorting/app/app.component.ts"/>
|
||||
<docs-code header="app.component.css" path="adev/src/content/examples/drag-drop/src/horizontal-sorting/app/app.component.css"/>
|
||||
</docs-code-multifile>
|
||||
|
||||
Alternatively, you can modify the `CDK_DRAG_CONFIG` injection token to update `listOrientation` within the config. For more information see the [dependency injection guide](https://angular.dev/guide/di), [drag config injection token API](api/cdk/drag-drop/CDK_DRAG_CONFIG), and the [drag drop config API](api/cdk/drag-drop/DragDropConfig).
|
||||
|
|
@ -284,9 +284,9 @@ By default, the `cdkDropList` sorts the draggable elements by moving them around
|
|||
If you have a sortable list that needs to wrap onto new lines, you can set `cdkDropListOrientation` attribute to `mixed`. This causes the list to use a different strategy of sorting the elements which involves moving them in the DOM. However the list can no longer animate the sorting action .
|
||||
|
||||
<docs-code-multifile preview path="adev/src/content/examples/drag-drop/src/mixed-sorting/app/app.component.ts">
|
||||
<docs-code header="app/app.component.html" path="adev/src/content/examples/drag-drop/src/mixed-sorting/app/app.component.html"/>
|
||||
<docs-code header="app/app.component.ts" path="adev/src/content/examples/drag-drop/src/mixed-sorting/app/app.component.ts"/>
|
||||
<docs-code header="app/app.component.css" path="adev/src/content/examples/drag-drop/src/mixed-sorting/app/app.component.css"/>
|
||||
<docs-code header="app.component.html" path="adev/src/content/examples/drag-drop/src/mixed-sorting/app/app.component.html"/>
|
||||
<docs-code header="app.component.ts" path="adev/src/content/examples/drag-drop/src/mixed-sorting/app/app.component.ts"/>
|
||||
<docs-code header="app.component.css" path="adev/src/content/examples/drag-drop/src/mixed-sorting/app/app.component.css"/>
|
||||
</docs-code-multifile>
|
||||
|
||||
### Selective sorting
|
||||
|
|
@ -294,9 +294,9 @@ If you have a sortable list that needs to wrap onto new lines, you can set `cdkD
|
|||
By default, `cdkDrag` elements are sorted into any position inside of a `cdkDropList`. To change this behavior, set the `cdkDropListSortPredicate` attribute which takes in a function. The predicate function is called whenever a draggable element is about to be moved into a new index within the drop list. If the predicate returns true, the item will be moved into the new index, otherwise it will keep its current position.
|
||||
|
||||
<docs-code-multifile preview path="adev/src/content/examples/drag-drop/src/sort-predicate/app/app.component.ts">
|
||||
<docs-code header="app/app.component.html" path="adev/src/content/examples/drag-drop/src/sort-predicate/app/app.component.html"/>
|
||||
<docs-code header="app/app.component.ts" path="adev/src/content/examples/drag-drop/src/sort-predicate/app/app.component.ts"/>
|
||||
<docs-code header="app/app.component.css" path="adev/src/content/examples/drag-drop/src/sort-predicate/app/app.component.css"/>
|
||||
<docs-code header="app.component.html" path="adev/src/content/examples/drag-drop/src/sort-predicate/app/app.component.html"/>
|
||||
<docs-code header="app.component.ts" path="adev/src/content/examples/drag-drop/src/sort-predicate/app/app.component.ts"/>
|
||||
<docs-code header="app.component.css" path="adev/src/content/examples/drag-drop/src/sort-predicate/app/app.component.css"/>
|
||||
</docs-code-multifile>
|
||||
|
||||
### Disable sorting
|
||||
|
|
@ -304,9 +304,9 @@ By default, `cdkDrag` elements are sorted into any position inside of a `cdkDrop
|
|||
There are cases where draggable elements can be dragged out of one `cdkDropList` into another, however the user shouldn't be able to sort them within the source list. For these cases, add the `cdkDropListSortingDisabled` attribute to prevent the draggable elements in a `cdkDropList` from sorting. This preserves the dragged element's initial position in the source list if it does not get dragged to a new valid position.
|
||||
|
||||
<docs-code-multifile preview path="adev/src/content/examples/drag-drop/src/disable-sorting/app/app.component.ts">
|
||||
<docs-code header="app/app.component.html" path="adev/src/content/examples/drag-drop/src/disable-sorting/app/app.component.html"/>
|
||||
<docs-code header="app/app.component.ts" path="adev/src/content/examples/drag-drop/src/disable-sorting/app/app.component.ts"/>
|
||||
<docs-code header="app/app.component.css" path="adev/src/content/examples/drag-drop/src/disable-sorting/app/app.component.css"/>
|
||||
<docs-code header="app.component.html" path="adev/src/content/examples/drag-drop/src/disable-sorting/app/app.component.html"/>
|
||||
<docs-code header="app.component.ts" path="adev/src/content/examples/drag-drop/src/disable-sorting/app/app.component.ts"/>
|
||||
<docs-code header="app.component.css" path="adev/src/content/examples/drag-drop/src/disable-sorting/app/app.component.css"/>
|
||||
</docs-code-multifile>
|
||||
|
||||
Alternatively, you can modify the `CDK_DRAG_CONFIG` injection token to update sortingDisabled within the config. For more information see the [dependency injection guide](https://angular.dev/guide/di), [drag config injection token API](api/cdk/drag-drop/CDK_DRAG_CONFIG), and the [drag drop config API](api/cdk/drag-drop/DragDropConfig).
|
||||
|
|
@ -320,9 +320,9 @@ To enable copying, you can set the `cdkDropListHasAnchor` input. This tells the
|
|||
Combining `cdkDropListHasAnchor` with `cdkDropListSortingDisabled` makes it possible to construct a list from which a user can copy items without being able to reorder the source list (e.g. a product list and a shopping cart).
|
||||
|
||||
<docs-code-multifile preview path="adev/src/content/examples/drag-drop/src/copy-list/app/app.component.ts">
|
||||
<docs-code header="app/app.component.html" path="adev/src/content/examples/drag-drop/src/copy-list/app/app.component.html"/>
|
||||
<docs-code header="app/app.component.ts" path="adev/src/content/examples/drag-drop/src/copy-list/app/app.component.ts"/>
|
||||
<docs-code header="app/app.component.css" path="adev/src/content/examples/drag-drop/src/copy-list/app/app.component.css"/>
|
||||
<docs-code header="app.component.html" path="adev/src/content/examples/drag-drop/src/copy-list/app/app.component.html"/>
|
||||
<docs-code header="app.component.ts" path="adev/src/content/examples/drag-drop/src/copy-list/app/app.component.ts"/>
|
||||
<docs-code header="app.component.css" path="adev/src/content/examples/drag-drop/src/copy-list/app/app.component.css"/>
|
||||
</docs-code-multifile>
|
||||
|
||||
## Customize animations
|
||||
|
|
|
|||
|
|
@ -24,7 +24,7 @@ Additional metadata may include the library, component, or area of the applicati
|
|||
To specify a custom ID in the `i18n` attribute or [`$localize`][ApiLocalizeInitLocalize] tagged message string, use the `@@` prefix.
|
||||
The following example defines the `introductionHeader` custom ID in a heading element.
|
||||
|
||||
<docs-code header="app/app.component.html" path="adev/src/content/examples/i18n/doc-files/app.component.html" visibleRegion="i18n-attribute-solo-id"/>
|
||||
<docs-code header="app.component.html" path="adev/src/content/examples/i18n/doc-files/app.component.html" visibleRegion="i18n-attribute-solo-id"/>
|
||||
|
||||
The following example defines the `introductionHeader` custom ID for a variable.
|
||||
|
||||
|
|
@ -50,7 +50,7 @@ Use a custom ID in combination with a description and a meaning to further help
|
|||
|
||||
The following example includes a description, followed by the custom ID.
|
||||
|
||||
<docs-code header="app/app.component.html" path="adev/src/content/examples/i18n/doc-files/app.component.html" visibleRegion="i18n-attribute-id"/>
|
||||
<docs-code header="app.component.html" path="adev/src/content/examples/i18n/doc-files/app.component.html" visibleRegion="i18n-attribute-id"/>
|
||||
|
||||
The following example defines the `introductionHeader` custom ID and description for a variable.
|
||||
|
||||
|
|
@ -64,7 +64,7 @@ variableText2 = $localize`:An introduction header for this sample@@introductionH
|
|||
|
||||
The following example adds a meaning.
|
||||
|
||||
<docs-code header="app/app.component.html" path="adev/src/content/examples/i18n/doc-files/app.component.html" visibleRegion="i18n-attribute-meaning-and-id"/>
|
||||
<docs-code header="app.component.html" path="adev/src/content/examples/i18n/doc-files/app.component.html" visibleRegion="i18n-attribute-meaning-and-id"/>
|
||||
|
||||
The following example defines the `introductionHeader` custom ID for a variable.
|
||||
|
||||
|
|
@ -83,7 +83,7 @@ If you use the same ID for two different text elements, the extraction tool extr
|
|||
|
||||
For example, in the following code snippet the same `myId` custom ID is defined for two different text elements.
|
||||
|
||||
<docs-code header="app/app.component.html" path="adev/src/content/examples/i18n/doc-files/app.component.html" visibleRegion="i18n-duplicate-custom-id"/>
|
||||
<docs-code header="app.component.html" path="adev/src/content/examples/i18n/doc-files/app.component.html" visibleRegion="i18n-duplicate-custom-id"/>
|
||||
|
||||
The following displays the translation in French.
|
||||
|
||||
|
|
|
|||
|
|
@ -8,15 +8,15 @@ Its name reflects the way the directive is applied: as an attribute on a host el
|
|||
The sample application's `HighlightDirective` sets the background color of an element based on either a data bound color or a default color \(lightgray\).
|
||||
It also sets a custom property of the element \(`customProperty`\) to `true` for no reason other than to show that it can.
|
||||
|
||||
<docs-code header="app/shared/highlight.directive.ts" path="adev/src/content/examples/testing/src/app/shared/highlight.directive.ts"/>
|
||||
<docs-code header="highlight.directive.ts" path="adev/src/content/examples/testing/src/app/shared/highlight.directive.ts"/>
|
||||
|
||||
It's used throughout the application, perhaps most simply in the `AboutComponent`:
|
||||
|
||||
<docs-code header="app/about/about.component.ts" path="adev/src/content/examples/testing/src/app/about/about.component.ts"/>
|
||||
<docs-code header="about.component.ts" path="adev/src/content/examples/testing/src/app/about/about.component.ts"/>
|
||||
|
||||
Testing the specific use of the `HighlightDirective` within the `AboutComponent` requires only the techniques explored in the ["Nested component tests"](guide/testing/components-scenarios#nested-component-tests) section of [Component testing scenarios](guide/testing/components-scenarios).
|
||||
|
||||
<docs-code header="app/about/about.component.spec.ts" path="adev/src/content/examples/testing/src/app/about/about.component.spec.ts" visibleRegion="tests"/>
|
||||
<docs-code header="about.component.spec.ts" path="adev/src/content/examples/testing/src/app/about/about.component.spec.ts" visibleRegion="tests"/>
|
||||
|
||||
However, testing a single use case is unlikely to explore the full range of a directive's capabilities.
|
||||
Finding and testing all components that use the directive is tedious, brittle, and almost as unlikely to afford full coverage.
|
||||
|
|
@ -26,7 +26,7 @@ Isolated unit tests don't touch the DOM and, therefore, do not inspire confidenc
|
|||
|
||||
A better solution is to create an artificial test component that demonstrates all ways to apply the directive.
|
||||
|
||||
<docs-code header="app/shared/highlight.directive.spec.ts (TestComponent)" path="adev/src/content/examples/testing/src/app/shared/highlight.directive.spec.ts" visibleRegion="test-component"/>
|
||||
<docs-code header="highlight.directive.spec.ts (TestComponent)" path="adev/src/content/examples/testing/src/app/shared/highlight.directive.spec.ts" visibleRegion="test-component"/>
|
||||
|
||||
<img alt="HighlightDirective spec in action" src="assets/images/guide/testing/highlight-directive-spec.png">
|
||||
|
||||
|
|
@ -35,7 +35,7 @@ The initial value is the word "cyan" which should be the background color of the
|
|||
|
||||
Here are some tests of this component:
|
||||
|
||||
<docs-code header="app/shared/highlight.directive.spec.ts (selected tests)" path="adev/src/content/examples/testing/src/app/shared/highlight.directive.spec.ts" visibleRegion="selected-tests"/>
|
||||
<docs-code header="highlight.directive.spec.ts (selected tests)" path="adev/src/content/examples/testing/src/app/shared/highlight.directive.spec.ts" visibleRegion="selected-tests"/>
|
||||
|
||||
A few techniques are noteworthy:
|
||||
|
||||
|
|
|
|||
|
|
@ -42,7 +42,7 @@ ng generate component banner --inline-template --inline-style --module app
|
|||
|
||||
It also generates an initial test file for the component, `banner-external.component.spec.ts`, that looks like this:
|
||||
|
||||
<docs-code header="app/banner/banner-external.component.spec.ts (initial)" path="adev/src/content/examples/testing/src/app/banner/banner-initial.component.spec.ts" visibleRegion="v1"/>
|
||||
<docs-code header="banner-external.component.spec.ts (initial)" path="adev/src/content/examples/testing/src/app/banner/banner-initial.component.spec.ts" visibleRegion="v1"/>
|
||||
|
||||
HELPFUL: Because `compileComponents` is asynchronous, it uses the [`waitForAsync`](api/core/testing/waitForAsync) utility function imported from `@angular/core/testing`.
|
||||
|
||||
|
|
@ -57,7 +57,7 @@ The rest of the file is boilerplate setup code anticipating more advanced tests
|
|||
You'll learn about these advanced test features in the following sections.
|
||||
For now, you can radically reduce this test file to a more manageable size:
|
||||
|
||||
<docs-code header="app/banner/banner-initial.component.spec.ts (minimal)" path="adev/src/content/examples/testing/src/app/banner/banner-initial.component.spec.ts" visibleRegion="v2"/>
|
||||
<docs-code header="banner-initial.component.spec.ts (minimal)" path="adev/src/content/examples/testing/src/app/banner/banner-initial.component.spec.ts" visibleRegion="v2"/>
|
||||
|
||||
In this example, the metadata object passed to `TestBed.configureTestingModule` simply declares `BannerComponent`, the component to test.
|
||||
|
||||
|
|
|
|||
|
|
@ -8,7 +8,7 @@ In the example application, the `BannerComponent` presents static title text in
|
|||
|
||||
After a few changes, the `BannerComponent` presents a dynamic title by binding to the component's `title` property like this.
|
||||
|
||||
<docs-code header="app/banner/banner.component.ts" path="adev/src/content/examples/testing/src/app/banner/banner.component.ts" visibleRegion="component"/>
|
||||
<docs-code header="banner.component.ts" path="adev/src/content/examples/testing/src/app/banner/banner.component.ts" visibleRegion="component"/>
|
||||
|
||||
As minimal as this is, you decide to add a test to confirm that component actually displays the right content where you think it should.
|
||||
|
||||
|
|
@ -18,7 +18,7 @@ You'll write a sequence of tests that inspect the value of the `<h1>` element th
|
|||
|
||||
You update the `beforeEach` to find that element with a standard HTML `querySelector` and assign it to the `h1` variable.
|
||||
|
||||
<docs-code header="app/banner/banner.component.spec.ts (setup)" path="adev/src/content/examples/testing/src/app/banner/banner.component.spec.ts" visibleRegion="setup"/>
|
||||
<docs-code header="banner.component.spec.ts (setup)" path="adev/src/content/examples/testing/src/app/banner/banner.component.spec.ts" visibleRegion="setup"/>
|
||||
|
||||
### `createComponent()` does not bind data
|
||||
|
||||
|
|
@ -65,11 +65,11 @@ Many testers prefer that the Angular test environment run change detection autom
|
|||
That's possible by configuring the `TestBed` with the `ComponentFixtureAutoDetect` provider.
|
||||
First import it from the testing utility library:
|
||||
|
||||
<docs-code header="app/banner/banner.component.detect-changes.spec.ts (import)" path="adev/src/content/examples/testing/src/app/banner/banner.component.detect-changes.spec.ts" visibleRegion="import-ComponentFixtureAutoDetect"/>
|
||||
<docs-code header="banner.component.detect-changes.spec.ts (import)" path="adev/src/content/examples/testing/src/app/banner/banner.component.detect-changes.spec.ts" visibleRegion="import-ComponentFixtureAutoDetect"/>
|
||||
|
||||
Then add it to the `providers` array of the testing module configuration:
|
||||
|
||||
<docs-code header="app/banner/banner.component.detect-changes.spec.ts (AutoDetect)" path="adev/src/content/examples/testing/src/app/banner/banner.component.detect-changes.spec.ts" visibleRegion="auto-detect"/>
|
||||
<docs-code header="banner.component.detect-changes.spec.ts (AutoDetect)" path="adev/src/content/examples/testing/src/app/banner/banner.component.detect-changes.spec.ts" visibleRegion="auto-detect"/>
|
||||
|
||||
HELPFUL: You can also use the `fixture.autoDetectChanges()` function instead if you only want to enable automatic change detection
|
||||
after making updates to the state of the fixture's component. In addition, automatic change detection is on by default
|
||||
|
|
@ -77,7 +77,7 @@ when using `provideZonelessChangeDetection` and turning it off is not recommende
|
|||
|
||||
Here are three tests that illustrate how automatic change detection works.
|
||||
|
||||
<docs-code header="app/banner/banner.component.detect-changes.spec.ts (AutoDetect Tests)" path="adev/src/content/examples/testing/src/app/banner/banner.component.detect-changes.spec.ts" visibleRegion="auto-detect-tests"/>
|
||||
<docs-code header="banner.component.detect-changes.spec.ts (AutoDetect Tests)" path="adev/src/content/examples/testing/src/app/banner/banner.component.detect-changes.spec.ts" visibleRegion="auto-detect-tests"/>
|
||||
|
||||
The first test shows the benefit of automatic change detection.
|
||||
|
||||
|
|
@ -99,7 +99,7 @@ It won't read that property until you raise the element's `input` event by calli
|
|||
|
||||
The following example demonstrates the proper sequence.
|
||||
|
||||
<docs-code header="app/hero/hero-detail.component.spec.ts (pipe test)" path="adev/src/content/examples/testing/src/app/hero/hero-detail.component.spec.ts" visibleRegion="title-case-pipe"/>
|
||||
<docs-code header="hero-detail.component.spec.ts (pipe test)" path="adev/src/content/examples/testing/src/app/hero/hero-detail.component.spec.ts" visibleRegion="title-case-pipe"/>
|
||||
|
||||
## Component with external files
|
||||
|
||||
|
|
@ -107,7 +107,7 @@ The preceding `BannerComponent` is defined with an _inline template_ and _inline
|
|||
|
||||
Many components specify _external templates_ and _external css_ with the `@Component.templateUrl` and `@Component.styleUrls` properties respectively, as the following variant of `BannerComponent` does.
|
||||
|
||||
<docs-code header="app/banner/banner-external.component.ts (metadata)" path="adev/src/content/examples/testing/src/app/banner/banner-external.component.ts" visibleRegion="metadata"/>
|
||||
<docs-code header="banner-external.component.ts (metadata)" path="adev/src/content/examples/testing/src/app/banner/banner-external.component.ts" visibleRegion="metadata"/>
|
||||
|
||||
This syntax tells the Angular compiler to read the external files during component compilation.
|
||||
|
||||
|
|
@ -135,7 +135,7 @@ Components often have service dependencies.
|
|||
The `WelcomeComponent` displays a welcome message to the logged-in user.
|
||||
It knows who the user is based on a property of the injected `UserService`:
|
||||
|
||||
<docs-code header="app/welcome/welcome.component.ts" path="adev/src/content/examples/testing/src/app/welcome/welcome.component.ts"/>
|
||||
<docs-code header="welcome.component.ts" path="adev/src/content/examples/testing/src/app/welcome/welcome.component.ts"/>
|
||||
|
||||
The `WelcomeComponent` has decision logic that interacts with the service, logic that makes this component worth testing.
|
||||
|
||||
|
|
@ -176,11 +176,11 @@ HELPFUL: For a use case in which `TestBed.inject()` does not work, see the [_Ove
|
|||
|
||||
Here's the complete `beforeEach()`, using `TestBed.inject()`:
|
||||
|
||||
<docs-code header="app/welcome/welcome.component.spec.ts" path="adev/src/content/examples/testing/src/app/welcome/welcome.component.spec.ts" visibleRegion="setup"/>
|
||||
<docs-code header="welcome.component.spec.ts" path="adev/src/content/examples/testing/src/app/welcome/welcome.component.spec.ts" visibleRegion="setup"/>
|
||||
|
||||
And here are some tests:
|
||||
|
||||
<docs-code header="app/welcome/welcome.component.spec.ts" path="adev/src/content/examples/testing/src/app/welcome/welcome.component.spec.ts" visibleRegion="tests"/>
|
||||
<docs-code header="welcome.component.spec.ts" path="adev/src/content/examples/testing/src/app/welcome/welcome.component.spec.ts" visibleRegion="tests"/>
|
||||
|
||||
The first is a sanity test; it confirms that the `UserService` is called and working.
|
||||
|
||||
|
|
@ -197,14 +197,14 @@ The third test checks that the component displays the proper message when there
|
|||
In this sample, the `AboutComponent` template hosts a `TwainComponent`.
|
||||
The `TwainComponent` displays Mark Twain quotes.
|
||||
|
||||
<docs-code header="app/twain/twain.component.ts (template)" path="adev/src/content/examples/testing/src/app/twain/twain.component.ts" visibleRegion="template" />
|
||||
<docs-code header="twain.component.ts (template)" path="adev/src/content/examples/testing/src/app/twain/twain.component.ts" visibleRegion="template" />
|
||||
|
||||
HELPFUL: The value of the component's `quote` property passes through an `AsyncPipe`.
|
||||
That means the property returns either a `Promise` or an `Observable`.
|
||||
|
||||
In this example, the `TwainComponent.getQuote()` method tells you that the `quote` property returns an `Observable`.
|
||||
|
||||
<docs-code header="app/twain/twain.component.ts (getQuote)" path="adev/src/content/examples/testing/src/app/twain/twain.component.ts" visibleRegion="get-quote"/>
|
||||
<docs-code header="twain.component.ts (getQuote)" path="adev/src/content/examples/testing/src/app/twain/twain.component.ts" visibleRegion="get-quote"/>
|
||||
|
||||
The `TwainComponent` gets quotes from an injected `TwainService`.
|
||||
The component starts the returned `Observable` with a placeholder value \(`'...'`\), before the service can return its first quote.
|
||||
|
|
@ -220,7 +220,7 @@ In general, tests themselves should not make calls to remote servers.
|
|||
They should emulate such calls.
|
||||
The setup in this `app/twain/twain.component.spec.ts` shows one way to do that:
|
||||
|
||||
<docs-code header="app/twain/twain.component.spec.ts (setup)" path="adev/src/content/examples/testing/src/app/twain/twain.component.spec.ts" visibleRegion="setup"/>
|
||||
<docs-code header="twain.component.spec.ts (setup)" path="adev/src/content/examples/testing/src/app/twain/twain.component.spec.ts" visibleRegion="setup"/>
|
||||
|
||||
Focus on the spy.
|
||||
|
||||
|
|
@ -421,13 +421,13 @@ Clicking that hero tells the `DashboardComponent` that the user has selected the
|
|||
|
||||
The `DashboardHeroComponent` is embedded in the `DashboardComponent` template like this:
|
||||
|
||||
<docs-code header="app/dashboard/dashboard.component.html (excerpt)" path="adev/src/content/examples/testing/src/app/dashboard/dashboard.component.html" visibleRegion="dashboard-hero"/>
|
||||
<docs-code header="dashboard.component.html (excerpt)" path="adev/src/content/examples/testing/src/app/dashboard/dashboard.component.html" visibleRegion="dashboard-hero"/>
|
||||
|
||||
The `DashboardHeroComponent` appears in an `@for` block, which sets each component's `hero` input property to the looping value and listens for the component's `selected` event.
|
||||
|
||||
Here's the component's full definition:
|
||||
|
||||
<docs-code header="app/dashboard/dashboard-hero.component.ts (component)" path="adev/src/content/examples/testing/src/app/dashboard/dashboard-hero.component.ts" visibleRegion="component"/>
|
||||
<docs-code header="dashboard-hero.component.ts (component)" path="adev/src/content/examples/testing/src/app/dashboard/dashboard-hero.component.ts" visibleRegion="component"/>
|
||||
|
||||
While testing a component this simple has little intrinsic value, it's worth knowing how.
|
||||
Use one of these approaches:
|
||||
|
|
@ -442,7 +442,7 @@ The immediate goal is to test the `DashboardHeroComponent`, not the `DashboardCo
|
|||
|
||||
Here's the meat of the spec file setup.
|
||||
|
||||
<docs-code header="app/dashboard/dashboard-hero.component.spec.ts (setup)" path="adev/src/content/examples/testing/src/app/dashboard/dashboard-hero.component.spec.ts" visibleRegion="setup"/>
|
||||
<docs-code header="dashboard-hero.component.spec.ts (setup)" path="adev/src/content/examples/testing/src/app/dashboard/dashboard-hero.component.spec.ts" visibleRegion="setup"/>
|
||||
|
||||
Notice how the setup code assigns a test hero \(`expectedHero`\) to the component's `hero` property, emulating the way the `DashboardComponent` would set it using the property binding in its repeater.
|
||||
|
||||
|
|
@ -511,14 +511,14 @@ If you like it, add it to your own collection of helpers.
|
|||
|
||||
Here's the previous test, rewritten using the click helper.
|
||||
|
||||
<docs-code header="app/dashboard/dashboard-hero.component.spec.ts (test with click helper)" path="adev/src/content/examples/testing/src/app/dashboard/dashboard-hero.component.spec.ts" visibleRegion="click-test-3"/>
|
||||
<docs-code header="dashboard-hero.component.spec.ts (test with click helper)" path="adev/src/content/examples/testing/src/app/dashboard/dashboard-hero.component.spec.ts" visibleRegion="click-test-3"/>
|
||||
|
||||
## Component inside a test host
|
||||
|
||||
The previous tests played the role of the host `DashboardComponent` themselves.
|
||||
But does the `DashboardHeroComponent` work correctly when properly data-bound to a host component?
|
||||
|
||||
<docs-code header="app/dashboard/dashboard-hero.component.spec.ts (test host)" path="adev/src/content/examples/testing/src/app/dashboard/dashboard-hero.component.spec.ts" visibleRegion="test-host"/>
|
||||
<docs-code header="dashboard-hero.component.spec.ts (test host)" path="adev/src/content/examples/testing/src/app/dashboard/dashboard-hero.component.spec.ts" visibleRegion="test-host"/>
|
||||
|
||||
The test host sets the component's `hero` input property with its test hero.
|
||||
It binds the component's `selected` event with its `onSelected` handler, which records the emitted hero in its `selectedHero` property.
|
||||
|
|
@ -527,7 +527,7 @@ Later, the tests will be able to check `selectedHero` to verify that the `Dashbo
|
|||
|
||||
The setup for the `test-host` tests is similar to the setup for the stand-alone tests:
|
||||
|
||||
<docs-code header="app/dashboard/dashboard-hero.component.spec.ts (test host setup)" path="adev/src/content/examples/testing/src/app/dashboard/dashboard-hero.component.spec.ts" visibleRegion="test-host-setup"/>
|
||||
<docs-code header="dashboard-hero.component.spec.ts (test host setup)" path="adev/src/content/examples/testing/src/app/dashboard/dashboard-hero.component.spec.ts" visibleRegion="test-host-setup"/>
|
||||
|
||||
This testing module configuration shows two important differences:
|
||||
|
||||
|
|
@ -541,7 +541,7 @@ The query for the hero element \(`heroEl`\) still finds it in the test DOM, albe
|
|||
|
||||
The tests themselves are almost identical to the stand-alone version:
|
||||
|
||||
<docs-code header="app/dashboard/dashboard-hero.component.spec.ts (test-host)" path="adev/src/content/examples/testing/src/app/dashboard/dashboard-hero.component.spec.ts" visibleRegion="test-host-tests"/>
|
||||
<docs-code header="dashboard-hero.component.spec.ts (test-host)" path="adev/src/content/examples/testing/src/app/dashboard/dashboard-hero.component.spec.ts" visibleRegion="test-host-tests"/>
|
||||
|
||||
Only the selected event test differs.
|
||||
It confirms that the selected `DashboardHeroComponent` hero really does find its way up through the event binding to the host component.
|
||||
|
|
@ -553,11 +553,11 @@ The `DashboardComponent` is a _routing component_ because the user can navigate
|
|||
|
||||
Angular provides test helpers to reduce boilerplate and more effectively test code which depends on `HttpClient`. The `provideRouter` function can be used directly in the test module as well.
|
||||
|
||||
<docs-code header="app/dashboard/dashboard.component.spec.ts" path="adev/src/content/examples/testing/src/app/dashboard/dashboard.component.spec.ts" visibleRegion="router-harness"/>
|
||||
<docs-code header="dashboard.component.spec.ts" path="adev/src/content/examples/testing/src/app/dashboard/dashboard.component.spec.ts" visibleRegion="router-harness"/>
|
||||
|
||||
The following test clicks the displayed hero and confirms that we navigate to the expected URL.
|
||||
|
||||
<docs-code header="app/dashboard/dashboard.component.spec.ts (navigate test)" path="adev/src/content/examples/testing/src/app/dashboard/dashboard.component.spec.ts" visibleRegion="navigate-test"/>
|
||||
<docs-code header="dashboard.component.spec.ts (navigate test)" path="adev/src/content/examples/testing/src/app/dashboard/dashboard.component.spec.ts" visibleRegion="navigate-test"/>
|
||||
|
||||
## Routed components
|
||||
|
||||
|
|
@ -573,7 +573,7 @@ It creates an `ActivatedRoute` object with the routing information and injects i
|
|||
|
||||
Here are the services injected into `HeroDetailComponent`:
|
||||
|
||||
<docs-code header="app/hero/hero-detail.component.ts (inject)" path="adev/src/content/examples/testing/src/app/hero/hero-detail.component.ts" visibleRegion="inject"/>
|
||||
<docs-code header="hero-detail.component.ts (inject)" path="adev/src/content/examples/testing/src/app/hero/hero-detail.component.ts" visibleRegion="inject"/>
|
||||
|
||||
The `HeroDetail` component needs the `id` parameter so it can fetch the corresponding hero using the `HeroDetailService`.
|
||||
The component has to get the `id` from the `ActivatedRoute.paramMap` property which is an `Observable`.
|
||||
|
|
@ -581,7 +581,7 @@ The component has to get the `id` from the `ActivatedRoute.paramMap` property wh
|
|||
It can't just reference the `id` property of the `ActivatedRoute.paramMap`.
|
||||
The component has to _subscribe_ to the `ActivatedRoute.paramMap` observable and be prepared for the `id` to change during its lifetime.
|
||||
|
||||
<docs-code header="app/hero/hero-detail.component.ts (constructor)" path="adev/src/content/examples/testing/src/app/hero/hero-detail.component.ts" visibleRegion="ctor"/>
|
||||
<docs-code header="hero-detail.component.ts (constructor)" path="adev/src/content/examples/testing/src/app/hero/hero-detail.component.ts" visibleRegion="ctor"/>
|
||||
|
||||
Tests can explore how the `HeroDetailComponent` responds to different `id` parameter values by navigating to different routes.
|
||||
|
||||
|
|
@ -593,7 +593,7 @@ The component tree can be very deep and sometimes the nested components play no
|
|||
|
||||
The `AppComponent`, for example, displays a navigation bar with anchors and their `RouterLink` directives.
|
||||
|
||||
<docs-code header="app/app.component.html" path="adev/src/content/examples/testing/src/app/app.component.html"/>
|
||||
<docs-code header="app.component.html" path="adev/src/content/examples/testing/src/app/app.component.html"/>
|
||||
|
||||
To validate the links but not the navigation, you don't need the `Router` to navigate and you don't need the `<router-outlet>` to mark where the `Router` inserts _routed components_.
|
||||
|
||||
|
|
@ -612,14 +612,14 @@ Use them, alone or in combination, to stay focused on testing the primary compon
|
|||
|
||||
In the first technique, you create and declare stub versions of the components and directive that play little or no role in the tests.
|
||||
|
||||
<docs-code header="app/app.component.spec.ts (stub declaration)" path="adev/src/content/examples/testing/src/app/app.component.spec.ts" visibleRegion="component-stubs"/>
|
||||
<docs-code header="app.component.spec.ts (stub declaration)" path="adev/src/content/examples/testing/src/app/app.component.spec.ts" visibleRegion="component-stubs"/>
|
||||
|
||||
The stub selectors match the selectors for the corresponding real components.
|
||||
But their templates and classes are empty.
|
||||
|
||||
Then declare them by overriding the `imports` of your component using `TestBed.overrideComponent`.
|
||||
|
||||
<docs-code header="app/app.component.spec.ts (TestBed stubs)" path="adev/src/content/examples/testing/src/app/app.component.spec.ts" visibleRegion="testbed-stubs"/>
|
||||
<docs-code header="app.component.spec.ts (TestBed stubs)" path="adev/src/content/examples/testing/src/app/app.component.spec.ts" visibleRegion="testbed-stubs"/>
|
||||
|
||||
HELPFUL: The `set` key in this example replaces all the exisiting imports on your component, make sure to imports all dependencies, not only the stubs. Alternatively you can use the `remove`/`add` keys to selectively remove and add imports.
|
||||
|
||||
|
|
@ -627,7 +627,7 @@ HELPFUL: The `set` key in this example replaces all the exisiting imports on you
|
|||
|
||||
In the second approach, add `NO_ERRORS_SCHEMA` to the metadata overrides of your component.
|
||||
|
||||
<docs-code header="app/app.component.spec.ts (NO_ERRORS_SCHEMA)" path="adev/src/content/examples/testing/src/app/app.component.spec.ts" visibleRegion="no-errors-schema"/>
|
||||
<docs-code header="app.component.spec.ts (NO_ERRORS_SCHEMA)" path="adev/src/content/examples/testing/src/app/app.component.spec.ts" visibleRegion="no-errors-schema"/>
|
||||
|
||||
The `NO_ERRORS_SCHEMA` tells the Angular compiler to ignore unrecognized elements and attributes.
|
||||
|
||||
|
|
@ -652,7 +652,7 @@ While the stubs in _this_ example were empty, you could give them stripped-down
|
|||
|
||||
In practice you will combine the two techniques in the same setup, as seen in this example.
|
||||
|
||||
<docs-code header="app/app.component.spec.ts (mixed setup)" path="adev/src/content/examples/testing/src/app/app.component.spec.ts" visibleRegion="mixed-setup"/>
|
||||
<docs-code header="app.component.spec.ts (mixed setup)" path="adev/src/content/examples/testing/src/app/app.component.spec.ts" visibleRegion="mixed-setup"/>
|
||||
|
||||
The Angular compiler creates the `BannerStubComponent` for the `<app-banner>` element and applies the `RouterLink` to the anchors with the `routerLink` attribute, but it ignores the `<app-welcome>` and `<router-outlet>` tags.
|
||||
|
||||
|
|
@ -660,7 +660,7 @@ The Angular compiler creates the `BannerStubComponent` for the `<app-banner>` el
|
|||
|
||||
A little more setup triggers the initial data binding and gets references to the navigation links:
|
||||
|
||||
<docs-code header="app/app.component.spec.ts (test setup)" path="adev/src/content/examples/testing/src/app/app.component.spec.ts" visibleRegion="test-setup"/>
|
||||
<docs-code header="app.component.spec.ts (test setup)" path="adev/src/content/examples/testing/src/app/app.component.spec.ts" visibleRegion="test-setup"/>
|
||||
|
||||
Three points of special interest:
|
||||
|
||||
|
|
@ -670,11 +670,11 @@ Three points of special interest:
|
|||
|
||||
The `AppComponent` links to validate are as follows:
|
||||
|
||||
<docs-code header="app/app.component.html (navigation links)" path="adev/src/content/examples/testing/src/app/app.component.html" visibleRegion="links"/>
|
||||
<docs-code header="app.component.html (navigation links)" path="adev/src/content/examples/testing/src/app/app.component.html" visibleRegion="links"/>
|
||||
|
||||
Here are some tests that confirm those links are wired to the `routerLink` directives as expected:
|
||||
|
||||
<docs-code header="app/app.component.spec.ts (selected tests)" path="adev/src/content/examples/testing/src/app/app.component.spec.ts" visibleRegion="tests"/>
|
||||
<docs-code header="app.component.spec.ts (selected tests)" path="adev/src/content/examples/testing/src/app/app.component.spec.ts" visibleRegion="tests"/>
|
||||
|
||||
## Use a `page` object
|
||||
|
||||
|
|
@ -683,7 +683,7 @@ The `HeroDetailComponent` is a simple view with a title, two hero fields, and tw
|
|||
But there's plenty of template complexity even in this simple form.
|
||||
|
||||
<docs-code
|
||||
path="adev/src/content/examples/testing/src/app/hero/hero-detail.component.html" header="app/hero/hero-detail.component.html"/>
|
||||
path="adev/src/content/examples/testing/src/app/hero/hero-detail.component.html" header="hero-detail.component.html"/>
|
||||
|
||||
Tests that exercise the component need …
|
||||
|
||||
|
|
@ -698,23 +698,23 @@ Tame the complexity with a `Page` class that handles access to component propert
|
|||
|
||||
Here is such a `Page` class for the `hero-detail.component.spec.ts`
|
||||
|
||||
<docs-code header="app/hero/hero-detail.component.spec.ts (Page)" path="adev/src/content/examples/testing/src/app/hero/hero-detail.component.spec.ts" visibleRegion="page"/>
|
||||
<docs-code header="hero-detail.component.spec.ts (Page)" path="adev/src/content/examples/testing/src/app/hero/hero-detail.component.spec.ts" visibleRegion="page"/>
|
||||
|
||||
Now the important hooks for component manipulation and inspection are neatly organized and accessible from an instance of `Page`.
|
||||
|
||||
A `createComponent` method creates a `page` object and fills in the blanks once the `hero` arrives.
|
||||
|
||||
<docs-code header="app/hero/hero-detail.component.spec.ts (createComponent)" path="adev/src/content/examples/testing/src/app/hero/hero-detail.component.spec.ts" visibleRegion="create-component"/>
|
||||
<docs-code header="hero-detail.component.spec.ts (createComponent)" path="adev/src/content/examples/testing/src/app/hero/hero-detail.component.spec.ts" visibleRegion="create-component"/>
|
||||
|
||||
Here are a few more `HeroDetailComponent` tests to reinforce the point.
|
||||
|
||||
<docs-code header="app/hero/hero-detail.component.spec.ts (selected tests)" path="adev/src/content/examples/testing/src/app/hero/hero-detail.component.spec.ts" visibleRegion="selected-tests"/>
|
||||
<docs-code header="hero-detail.component.spec.ts (selected tests)" path="adev/src/content/examples/testing/src/app/hero/hero-detail.component.spec.ts" visibleRegion="selected-tests"/>
|
||||
|
||||
## Override component providers
|
||||
|
||||
The `HeroDetailComponent` provides its own `HeroDetailService`.
|
||||
|
||||
<docs-code header="app/hero/hero-detail.component.ts (prototype)" path="adev/src/content/examples/testing/src/app/hero/hero-detail.component.ts" visibleRegion="prototype"/>
|
||||
<docs-code header="hero-detail.component.ts (prototype)" path="adev/src/content/examples/testing/src/app/hero/hero-detail.component.ts" visibleRegion="prototype"/>
|
||||
|
||||
It's not possible to stub the component's `HeroDetailService` in the `providers` of the `TestBed.configureTestingModule`.
|
||||
Those are providers for the _testing module_, not the component.
|
||||
|
|
@ -733,7 +733,7 @@ There might not be a remote server to call.
|
|||
|
||||
Fortunately, the `HeroDetailService` delegates responsibility for remote data access to an injected `HeroService`.
|
||||
|
||||
<docs-code header="app/hero/hero-detail.service.ts (prototype)" path="adev/src/content/examples/testing/src/app/hero/hero-detail.service.ts" visibleRegion="prototype"/>
|
||||
<docs-code header="hero-detail.service.ts (prototype)" path="adev/src/content/examples/testing/src/app/hero/hero-detail.service.ts" visibleRegion="prototype"/>
|
||||
|
||||
The [previous test configuration](#import-a-feature-module) replaces the real `HeroService` with a `TestHeroService` that intercepts server requests and fakes their responses.
|
||||
|
||||
|
|
@ -743,7 +743,7 @@ What if `HeroDetailService` makes its own server requests?
|
|||
|
||||
The `TestBed.overrideComponent` method can replace the component's `providers` with easy-to-manage _test doubles_ as seen in the following setup variation:
|
||||
|
||||
<docs-code header="app/hero/hero-detail.component.spec.ts (Override setup)" path="adev/src/content/examples/testing/src/app/hero/hero-detail.component.spec.ts" visibleRegion="setup-override"/>
|
||||
<docs-code header="hero-detail.component.spec.ts (Override setup)" path="adev/src/content/examples/testing/src/app/hero/hero-detail.component.spec.ts" visibleRegion="setup-override"/>
|
||||
|
||||
Notice that `TestBed.configureTestingModule` no longer provides a fake `HeroService` because it's [not needed](#spy-stub).
|
||||
|
||||
|
|
@ -751,7 +751,7 @@ Notice that `TestBed.configureTestingModule` no longer provides a fake `HeroServ
|
|||
|
||||
Focus on the `overrideComponent` method.
|
||||
|
||||
<docs-code header="app/hero/hero-detail.component.spec.ts (overrideComponent)" path="adev/src/content/examples/testing/src/app/hero/hero-detail.component.spec.ts" visibleRegion="override-component-method"/>
|
||||
<docs-code header="hero-detail.component.spec.ts (overrideComponent)" path="adev/src/content/examples/testing/src/app/hero/hero-detail.component.spec.ts" visibleRegion="override-component-method"/>
|
||||
|
||||
It takes two arguments: the component type to override \(`HeroDetailComponent`\) and an override metadata object.
|
||||
The [override metadata object](guide/testing/utility-apis#metadata-override-object) is a generic defined as follows:
|
||||
|
|
@ -791,13 +791,13 @@ It neither injects nor delegates to the lower level `HeroService` so there's no
|
|||
The related `HeroDetailComponent` tests will assert that methods of the `HeroDetailService` were called by spying on the service methods.
|
||||
Accordingly, the stub implements its methods as spies:
|
||||
|
||||
<docs-code header="app/hero/hero-detail.component.spec.ts (HeroDetailServiceSpy)" path="adev/src/content/examples/testing/src/app/hero/hero-detail.component.spec.ts" visibleRegion="hds-spy"/>
|
||||
<docs-code header="hero-detail.component.spec.ts (HeroDetailServiceSpy)" path="adev/src/content/examples/testing/src/app/hero/hero-detail.component.spec.ts" visibleRegion="hds-spy"/>
|
||||
|
||||
### The override tests
|
||||
|
||||
Now the tests can control the component's hero directly by manipulating the spy-stub's `testHero` and confirm that service methods were called.
|
||||
|
||||
<docs-code header="app/hero/hero-detail.component.spec.ts (override tests)" path="adev/src/content/examples/testing/src/app/hero/hero-detail.component.spec.ts" visibleRegion="override-tests"/>
|
||||
<docs-code header="hero-detail.component.spec.ts (override tests)" path="adev/src/content/examples/testing/src/app/hero/hero-detail.component.spec.ts" visibleRegion="override-tests"/>
|
||||
|
||||
### More overrides
|
||||
|
||||
|
|
|
|||
|
|
@ -11,12 +11,12 @@ Most pipes have no dependence on Angular other than the `@Pipe` metadata and an
|
|||
Consider a `TitleCasePipe` that capitalizes the first letter of each word.
|
||||
Here's an implementation with a regular expression.
|
||||
|
||||
<docs-code header="app/shared/title-case.pipe.ts" path="adev/src/content/examples/testing/src/app/shared/title-case.pipe.ts"/>
|
||||
<docs-code header="title-case.pipe.ts" path="adev/src/content/examples/testing/src/app/shared/title-case.pipe.ts"/>
|
||||
|
||||
Anything that uses a regular expression is worth testing thoroughly.
|
||||
Use simple Jasmine to explore the expected cases and the edge cases.
|
||||
|
||||
<docs-code header="app/shared/title-case.pipe.spec.ts" path="adev/src/content/examples/testing/src/app/shared/title-case.pipe.spec.ts" visibleRegion="excerpt"/>
|
||||
<docs-code header="title-case.pipe.spec.ts" path="adev/src/content/examples/testing/src/app/shared/title-case.pipe.spec.ts" visibleRegion="excerpt"/>
|
||||
|
||||
## Writing DOM tests to support a pipe test
|
||||
|
||||
|
|
@ -25,4 +25,4 @@ They can't tell if the `TitleCasePipe` is working properly as applied in the app
|
|||
|
||||
Consider adding component tests such as this one:
|
||||
|
||||
<docs-code header="app/hero/hero-detail.component.spec.ts (pipe test)" path="adev/src/content/examples/testing/src/app/hero/hero-detail.component.spec.ts" visibleRegion="title-case-pipe"/>
|
||||
<docs-code header="hero-detail.component.spec.ts (pipe test)" path="adev/src/content/examples/testing/src/app/hero/hero-detail.component.spec.ts" visibleRegion="title-case-pipe"/>
|
||||
|
|
|
|||
|
|
@ -5,7 +5,7 @@ To check that your services are working as you intend, you can write tests speci
|
|||
Services are often the smoothest files to unit test.
|
||||
Here are some synchronous and asynchronous unit tests of the `ValueService` written without assistance from Angular testing utilities.
|
||||
|
||||
<docs-code header="app/demo/demo.spec.ts" path="adev/src/content/examples/testing/src/app/demo/demo.spec.ts" visibleRegion="ValueService"/>
|
||||
<docs-code header="demo.spec.ts" path="adev/src/content/examples/testing/src/app/demo/demo.spec.ts" visibleRegion="ValueService"/>
|
||||
|
||||
## Services with dependencies
|
||||
|
||||
|
|
@ -55,7 +55,7 @@ The `TestBed.configureTestingModule()` method takes a metadata object that can h
|
|||
|
||||
To test a service, you set the `providers` metadata property with an array of the services that you'll test or mock.
|
||||
|
||||
<docs-code header="app/demo/demo.testbed.spec.ts (provide ValueService in beforeEach)" path="adev/src/content/examples/testing/src/app/demo/demo.testbed.spec.ts" visibleRegion="value-service-before-each"/>
|
||||
<docs-code header="demo.testbed.spec.ts (provide ValueService in beforeEach)" path="adev/src/content/examples/testing/src/app/demo/demo.testbed.spec.ts" visibleRegion="value-service-before-each"/>
|
||||
|
||||
Then inject it inside a test by calling `TestBed.inject()` with the service class as the argument.
|
||||
|
||||
|
|
@ -88,7 +88,7 @@ Here's how you might rewrite one of the `MasterService` tests in that style.
|
|||
|
||||
Begin by putting re-usable, preparatory code in a _setup_ function instead of `beforeEach()`.
|
||||
|
||||
<docs-code header="app/demo/demo.spec.ts (setup)" path="adev/src/content/examples/testing/src/app/demo/demo.spec.ts" visibleRegion="no-before-each-setup"/>
|
||||
<docs-code header="demo.spec.ts (setup)" path="adev/src/content/examples/testing/src/app/demo/demo.spec.ts" visibleRegion="no-before-each-setup"/>
|
||||
|
||||
The `setup()` function returns an object literal with the variables, such as `masterService`, that a test might reference.
|
||||
You don't define _semi-global_ variables \(for example, `let masterService: MasterService`\) in the body of the `describe()`.
|
||||
|
|
@ -111,7 +111,7 @@ Data services that make HTTP calls to remote servers typically inject and delega
|
|||
|
||||
You can test a data service with an injected `HttpClient` spy as you would test any service with a dependency.
|
||||
|
||||
<docs-code header="app/model/hero.service.spec.ts (tests with spies)" path="adev/src/content/examples/testing/src/app/model/hero.service.spec.ts" visibleRegion="test-with-spies"/>
|
||||
<docs-code header="hero.service.spec.ts (tests with spies)" path="adev/src/content/examples/testing/src/app/model/hero.service.spec.ts" visibleRegion="test-with-spies"/>
|
||||
|
||||
IMPORTANT: The `HeroService` methods return `Observables`.
|
||||
You must _subscribe_ to an observable to \(a\) cause it to execute and \(b\) assert that the method succeeds or fails.
|
||||
|
|
|
|||
|
|
@ -139,7 +139,7 @@ The `DebugElement.query(predicate)` and `DebugElement.queryAll(predicate)` metho
|
|||
The predicate is any method that takes a `DebugElement` and returns a _truthy_ value.
|
||||
The following example finds all `DebugElements` with a reference to a template local variable named "content":
|
||||
|
||||
<docs-code header="app/demo/demo.testbed.spec.ts" path="adev/src/content/examples/testing/src/app/demo/demo.testbed.spec.ts" visibleRegion="custom-predicate"/>
|
||||
<docs-code header="demo.testbed.spec.ts" path="adev/src/content/examples/testing/src/app/demo/demo.testbed.spec.ts" visibleRegion="custom-predicate"/>
|
||||
|
||||
The Angular `By` class has three static methods for common predicates:
|
||||
|
||||
|
|
@ -149,4 +149,4 @@ The Angular `By` class has three static methods for common predicates:
|
|||
| `By.css(selector)` | Return elements with matching CSS selectors |
|
||||
| `By.directive(directive)` | Return elements that Angular matched to an instance of the directive class |
|
||||
|
||||
<docs-code header="app/hero/hero-list.component.spec.ts" path="adev/src/content/examples/testing/src/app/hero/hero-list.component.spec.ts" visibleRegion="by"/>
|
||||
<docs-code header="hero-list.component.spec.ts" path="adev/src/content/examples/testing/src/app/hero/hero-list.component.spec.ts" visibleRegion="by"/>
|
||||
|
|
|
|||
Loading…
Reference in a new issue