You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@@ -146,10 +141,12 @@ export const Empty: Story = {
146
141
```
147
142
148
143
<divclass="aside">
149
-
💡 <ahref="https://storybook.js.org/docs/angular/writing-stories/decorators"><b>Decorators</b></a> are a way to provide arbitrary wrappers to stories. In this case we’re using a decorator key on the default export to add some <code>padding</code> around the rendered component. They can also be used to wrap stories in “providers”–-i.e., library components that set some context.
144
+
145
+
💡[**Decorators**](https://storybook.js.org/docs/writing-stories/decorators) are a way to provide arbitrary wrappers to stories. In this case we’re using a decorator key on the default export to add some `margin` around the rendered component. They can also be used to wrap stories in “providers”–-i.e., library components that set some context.
146
+
150
147
</div>
151
148
152
-
By importing `TaskStories`, we were able to [compose](https://storybook.js.org/docs/angular/writing-stories/args#args-composition) the arguments (args for short) in our stories with minimal effort. That way, the data and actions (mocked callbacks) expected by both components are preserved.
149
+
By importing `TaskStories`, we were able to [compose](https://storybook.js.org/docs/writing-stories/args#args-composition) the arguments (args for short) in our stories with minimal effort. That way, the data and actions (mocked callbacks) expected by both components are preserved.
153
150
154
151
Now check Storybook for the new `TaskList` stories.
155
152
@@ -236,7 +233,7 @@ The added markup results in the following UI:
Copy file name to clipboardexpand all lines: content/intro-to-storybook/angular/en/conclusion.md
+1-1
Original file line number
Diff line number
Diff line change
@@ -16,7 +16,7 @@ Storybook is a powerful tool for React, React Native, Vue, Angular, Svelte and m
16
16
17
17
Want to dive deeper? Here are helpful resources.
18
18
19
-
-[**Official Storybook documentation**](https://storybook.js.org/docs/angular/get-started/introduction) has API documentation, community links, and the addon gallery.
19
+
-[**Official Storybook documentation**](https://storybook.js.org/docs/get-started/install?renderer=angular) has API documentation, community links, and the addon gallery.
20
20
21
21
-[**UI Testing Playbook**](https://storybook.js.org/blog/ui-testing-playbook/) highlights workflow best practices used by high-velocity teams at Twilio, Adobe, Peloton, and Shopify.
Copy file name to clipboardexpand all lines: content/intro-to-storybook/angular/en/deploy.md
+14-6
Original file line number
Diff line number
Diff line change
@@ -15,7 +15,7 @@ Running `npm run build-storybook` will output a static Storybook in the `storybo
15
15
16
16
## Publish Storybook
17
17
18
-
This tutorial uses <ahref="https://www.chromatic.com/?utm_source=storybook_website&utm_medium=link&utm_campaign=storybook">Chromatic</a>, a free publishing service made by the Storybook maintainers. It allows us to deploy and host our Storybook safely and securely in the cloud.
18
+
This tutorial uses [Chromatic](https://www.chromatic.com/?utm_source=storybook_website&utm_medium=link&utm_campaign=storybook), a free publishing service made by the Storybook maintainers. It allows us to deploy and host our Storybook safely and securely in the cloud.
19
19
20
20
### Set up a repository in GitHub
21
21
@@ -94,20 +94,28 @@ jobs:
94
94
runs-on: ubuntu-latest
95
95
# Job steps
96
96
steps:
97
-
- uses: actions/checkout@v3
97
+
- uses: actions/checkout@v4
98
98
with:
99
99
fetch-depth: 0
100
-
- run: yarn
101
-
#👇 Adds Chromatic as a step in the workflow
102
-
- uses: chromaui/action@v1
100
+
- uses: actions/setup-node@v4
101
+
with:
102
+
node-version: 20
103
+
- name: Install dependencies
104
+
run: npm ci
105
+
- name: "Run Chromatic"
106
+
uses: chromaui/action@latest
103
107
# Options required for Chromatic's GitHub Action
104
108
with:
105
109
#👇 Chromatic projectToken, see https://storybook.js.org/tutorials/intro-to-storybook/angular/en/deploy/ to obtain it
<divclass="aside"><p>💡 For brevity purposes <ahref=" https://docs.github.com/en/actions/security-guides/encrypted-secrets#creating-encrypted-secrets-for-a-repository ">GitHub secrets</a> weren't mentioned. Secrets are secure environment variables provided by GitHub so that you don't need to hard code the <code>project-token</code>.</p></div>
114
+
<divclass="aside">
115
+
116
+
💡 For brevity purposes [GitHub secrets](https://docs.github.com/en/actions/security-guides/encrypted-secrets#creating-encrypted-secrets-for-a-repository) weren't mentioned. Secrets are secure environment variables provided by GitHub so that you don't need to hard code the `project-token`.
Copy file name to clipboardexpand all lines: content/intro-to-storybook/angular/en/screen.md
+14-10
Original file line number
Diff line number
Diff line change
@@ -291,7 +291,9 @@ One way to sidestep this problem is to never render container components anywher
291
291
However, developers **will** inevitably need to render containers further down the component hierarchy. If we want to render most or all of the app in Storybook (we do!), we need a solution to this issue.
292
292
293
293
<divclass="aside">
294
-
💡 As an aside, passing data down the hierarchy is a legitimate approach, especially when using <ahref="http://graphql.org/">GraphQL</a>. It’s how we have built <ahref="https://www.chromatic.com/?utm_source=storybook_website&utm_medium=link&utm_campaign=storybook">Chromatic</a> alongside 800+ stories.
294
+
295
+
💡 As an aside, passing data down the hierarchy is a legitimate approach, especially when using [GraphQL](http://graphql.org/). It’s how we have built [Chromatic](https://www.chromatic.com/?utm_source=storybook_website&utm_medium=link&utm_campaign=storybook) alongside 800+ stories.
296
+
295
297
</div>
296
298
297
299
## Supplying context with decorators
@@ -352,15 +354,15 @@ Cycling through states in Storybook makes it easy to test we’ve done this corr
352
354
/>
353
355
</video>
354
356
355
-
## Interaction tests
357
+
## Component tests
356
358
357
359
So far, we've been able to build a fully functional application from the ground up, starting from a simple component up to a screen and continuously testing each change using our stories. But each new story also requires a manual check on all the other stories to ensure the UI doesn't break. That's a lot of extra work.
358
360
359
361
Can't we automate this workflow and test our component interactions automatically?
360
362
361
-
### Write an interaction test using the play function
363
+
### Write a component test using the play function
362
364
363
-
Storybook's [`play`](https://storybook.js.org/docs/angular/writing-stories/play-function) and [`@storybook/addon-interactions`](https://storybook.js.org/docs/angular/writing-tests/interaction-testing) help us with that. A play function includes small snippets of code that run after the story renders.
365
+
Storybook's [`play`](https://storybook.js.org/docs/writing-stories/play-function) and [`@storybook/addon-interactions`](https://storybook.js.org/docs/writing-tests/component-testing) help us with that. A play function includes small snippets of code that run after the story renders.
364
366
365
367
The play function helps us verify what happens to the UI when tasks are updated. It uses framework-agnostic DOM APIs, which means we can write stories with the play function to interact with the UI and simulate human behavior no matter the frontend framework.
366
368
@@ -441,9 +443,9 @@ Check your newly-created story. Click the `Interactions` panel to see the list o
441
443
442
444
With Storybook's play function, we were able to sidestep our problem, allowing us to interact with our UI and quickly check how it responds if we update our tasks—keeping the UI consistent at no extra manual effort.
443
445
444
-
But, if we take a closer look at our Storybook, we can see that it only runs the interaction tests when viewing the story. Therefore, we'd still have to go through each story to run all checks if we make a change. Couldn't we automate it?
446
+
But, if we take a closer look at our Storybook, we can see that it only runs the component tests when viewing the story. Therefore, we'd still have to go through each story to run all checks if we make a change. Couldn't we automate it?
445
447
446
-
The good news is that we can! Storybook's [test runner](https://storybook.js.org/docs/angular/writing-tests/test-runner) allows us to do just that. It's a standalone utility—powered by [Playwright](https://playwright.dev/)—that runs all our interactions tests and catches broken stories.
448
+
The good news is that we can! Storybook's [test runner](https://storybook.js.org/docs/writing-tests/test-runner) allows us to do just that. It's a standalone utility—powered by [Playwright](https://playwright.dev/)—that runs all our interactions tests and catches broken stories.
447
449
448
450
Let's see how it works! Run the following command to install it:
449
451
@@ -464,13 +466,15 @@ Next, update your `package.json` `scripts` and add a new test task:
464
466
Finally, with your Storybook running, open up a new terminal window and run the following command:
465
467
466
468
```shell
467
-
npm run test-storybook -- --watch
469
+
npm run test-storybook -- --url http://localhost:6006/ -- --watch
468
470
```
469
471
470
472
<divclass="aside">
471
-
💡 Interaction testing with the play function is a fantastic way to test your UI components. It can do much more than we've seen here; we recommend reading the <ahref="https://storybook.js.org/docs/angular/writing-tests/interaction-testing">official documentation</a> to learn more about it.
472
-
<br />
473
-
For an even deeper dive into testing, check out the <ahref="/ui-testing-handbook">Testing Handbook</a>. It covers testing strategies used by scaled-front-end teams to supercharge your development workflow.
473
+
474
+
💡 Component testing with the play function is a fantastic way to test your UI components. It can do much more than we've seen here; we recommend reading the [official documentation](https://storybook.js.org/docs/writing-tests/component-testing) to learn more about it.
475
+
476
+
For an even deeper dive into testing, check out the [Testing Handbook](/ui-testing-handbook). It covers testing strategies used by scaled-front-end teams to supercharge your development workflow.
477
+
474
478
</div>
475
479
476
480

@@ -125,7 +119,9 @@ export const Archived: Story = {
125
119
```
126
120
127
121
<divclass="aside">
128
-
💡 <ahref="https://storybook.js.org/docs/angular/essentials/actions"><b>Actions</b></a> help you verify interactions when building UI components in isolation. Oftentimes you won't have access to the functions and state you have in context of the app. Use <code>action()</code> to stub them in.
122
+
123
+
💡 [**Actions**](https://storybook.js.org/docs/essentials/actions) help you verify interactions when building UI components in isolation. Oftentimes you won't have access to the functions and state you have in context of the app. Use `fn()` to stub them in.
124
+
129
125
</div>
130
126
131
127
There are two basic levels of organization in Storybook: the component and its child stories. Think of each story as a permutation of a component. You can have as many stories per component as you need.
@@ -141,16 +137,15 @@ To tell Storybook about the component we are documenting, we create a `default`
141
137
-`title` -- how to group or categorize the component in the Storybook sidebar
142
138
-`tags` -- to automatically generate documentation for our components
143
139
-`excludeStories`-- additional information required by the story but should not be rendered in Storybook
144
-
-`render` -- a custom [render function](https://storybook.js.org/docs/angular/api/csf#custom-render-functions) that allows us how the component is rendered in Storybook
145
-
-`argsToTemplate` -- a helper function that converts the args to property and event bindings for the component, providing robust workflow support for Storybook's controls and the component's inputs and outputs
140
+
-`args` -- define the action [args](https://storybook.js.org/docs/essentials/actions#action-args) that the component expects to mock out the custom events
146
141
147
-
To define our stories, we'll use Component Story Format 3 (also known as [CSF3](https://storybook.js.org/docs/angular/api/csf) ) to build out each of our test cases. This format is designed to build out each of our test cases in a concise way. By exporting an object containing each component state, we can define our tests more intuitively and author and reuse stories more efficiently.
142
+
To define our stories, we'll use Component Story Format 3 (also known as [CSF3](https://storybook.js.org/docs/api/csf) ) to build out each of our test cases. This format is designed to build out each of our test cases in a concise way. By exporting an object containing each component state, we can define our tests more intuitively and author and reuse stories more efficiently.
148
143
149
-
Arguments or [`args`](https://storybook.js.org/docs/angular/writing-stories/args) for short, allow us to live-edit our components with the controls addon without restarting Storybook. Once an [`args`](https://storybook.js.org/docs/angular/writing-stories/args) value changes, so does the component.
144
+
Arguments or [`args`](https://storybook.js.org/docs/writing-stories/args) for short, allow us to live-edit our components with the controls addon without restarting Storybook. Once an [`args`](https://storybook.js.org/docs/writing-stories/args) value changes, so does the component.
150
145
151
-
`action()` allows us to create a callback that appears in the **actions** panel of the Storybook UI when clicked. So when we build a pin button, we’ll be able to determine if a button click is successful in the UI.
146
+
`fn()` allows us to create a callback that appears in the **Actions** panel of the Storybook UI when clicked. So when we build a pin button, we’ll be able to determine if a button click is successful in the UI.
152
147
153
-
As we need to pass the same set of actions to all permutations of our component, it is convenient to bundle them up into a single `actionsData` variable and pass them into our story definition each time. Another nice thing about bundling the `actionsData` that a component needs is that you can `export` them and use them in stories for components that reuse this component, as we'll see later.
148
+
As we need to pass the same set of actions to all permutations of our component, it is convenient to bundle them up into a single `ActionsData` variable and pass them into our story definition each time. Another nice thing about bundling the `ActionsData` that a component needs is that you can `export` them and use them in stories for components that reuse this component, as we'll see later.
154
149
155
150
When creating a story, we use a base `task` arg to build out the shape of the task the component expects. Typically modeled from what the actual data looks like. Again, `export`-ing this shape will enable us to reuse it in later stories, as we'll see.
0 commit comments