Addon-Interactions: Fix status in panel tab

[yannbf]

Closes #

What I did

There was a regression with the interactions addon where the status tab stopped showing a failure state (look at the number at top right):

Where before it would show a red square:

So this PR brings the behavior back, however I think the red square doesn't look as nice anymore, so I made a change to show a status badge instead, but red.

Scenario 1 - Play fn step fails:

Scenario 2 - Play fn step succeeds but there are unhandled exceptions:

Scenario 3 - Play fn fails before executing anything (count is shown as 0) 👈 We should think about the UI here:

Checklist for Contributors

Testing

The changes in this PR are covered in the following automated tests:

• stories
• unit tests
• integration tests
• end-to-end tests

Manual testing

This section is mandatory for all contributions. If you believe no manual test is necessary, please state so explicitly. Thanks!

Documentation

• Add or update documentation reflecting your changes
• If you are deprecating/removing a feature, make sure to update
  MIGRATION.MD

Checklist for Maintainers

• When this PR is ready for testing, make sure to add ci:normal, ci:merged or ci:daily GH label to it to run a specific set of sandboxes. The particular set of sandboxes can be found in code/lib/cli/src/sandbox-templates.ts

• Make sure this PR contains one of the labels below:

  Available labels

  • bug: Internal changes that fixes incorrect behavior.
  • maintenance: User-facing maintenance tasks.
  • dependencies: Upgrading (sometimes downgrading) dependencies.
  • build: Internal-facing build tooling & test updates. Will not show up in release changelog.
  • cleanup: Minor cleanup style change. Will not show up in release changelog.
  • documentation: Documentation only changes. Will not show up in release changelog.
  • feature request: Introducing a new feature.
  • BREAKING CHANGE: Changes that break compatibility in some way with current major version.
  • other: Changes that don't fit in the above categories.

🦋 Canary release

This PR does not have a canary release associated. You can request a canary release of this pull request by mentioning the @storybookjs/core team here.

core team members can create a canary release here or locally with gh workflow run --repo storybookjs/storybook canary-release-pr.yml --field pr=<PR_NUMBER>

name	before	after	diff	z	%
createSize	0 B	0 B	0 B	-	-
generateSize	76.5 MB	76.5 MB	0 B	1.54	0%
initSize	198 MB	198 MB	55 B	-0.98	0%
diffSize	121 MB	121 MB	55 B	-0.98	0%
buildSize	7.59 MB	7.59 MB	26 B	1.65	0%
buildSbAddonsSize	1.63 MB	1.63 MB	26 B	Infinity	0%
buildSbCommonSize	195 kB	195 kB	0 B	-	0%
buildSbManagerSize	2.3 MB	2.3 MB	0 B	-	0%
buildSbPreviewSize	349 kB	349 kB	0 B	-	0%
buildStaticSize	0 B	0 B	0 B	-	-
buildPrebuildSize	4.47 MB	4.47 MB	26 B	Infinity	0%
buildPreviewSize	3.12 MB	3.12 MB	0 B	0.23	0%
testBuildSize	0 B	0 B	0 B	-	-
testBuildSbAddonsSize	0 B	0 B	0 B	-	-
testBuildSbCommonSize	0 B	0 B	0 B	-	-
testBuildSbManagerSize	0 B	0 B	0 B	-	-
testBuildSbPreviewSize	0 B	0 B	0 B	-	-
testBuildStaticSize	0 B	0 B	0 B	-	-
testBuildPrebuildSize	0 B	0 B	0 B	-	-
testBuildPreviewSize	0 B	0 B	0 B	-	-

name	before	after	diff	z	%
createTime	10.7s	7.1s	-3s -564ms	-0.86	-49.7%
generateTime	22.6s	23.3s	683ms	0.37	2.9%
initTime	26.1s	23.3s	-2s -892ms	-0.15	-12.4%
buildTime	15s	15.8s	804ms	1.28	🔺5.1%
testBuildTime	0ms	0ms	0ms	-	-
devPreviewResponsive	8.5s	9.8s	1.2s	1.35	🔺12.9%
devManagerResponsive	5.9s	6.3s	405ms	1.71	🔺6.4%
devManagerHeaderVisible	751ms	1s	269ms	3.92	🔺26.4%
devManagerIndexVisible	784ms	1s	303ms	4.56	🔺27.9%
devStoryVisibleUncached	1.3s	1.8s	431ms	1.89	🔺23.8%
devStoryVisible	809ms	1.1s	320ms	4.8	🔺28.3%
devAutodocsVisible	732ms	1.3s	658ms	11.66	🔺47.3%
devMDXVisible	684ms	785ms	101ms	0.82	12.9%
buildManagerHeaderVisible	709ms	852ms	143ms	0.6	16.8%
buildManagerIndexVisible	711ms	855ms	144ms	0.56	16.8%
buildStoryVisible	761ms	909ms	148ms	0.65	16.3%
buildAutodocsVisible	673ms	715ms	42ms	-0.02	5.9%
buildMDXVisible	662ms	695ms	33ms	0.67	4.7%

[greptile-apps]

PR Summary

• code/addons/interactions/src/Panel.tsx: Fixed regression issue to accurately reflect error status in the UI.
• code/addons/interactions/src/components/TabStatus.tsx: Removed TabStatus.tsx file and TabIcon component.
• code/addons/interactions/src/manager.tsx: Replaced TabIcon with Badge for error status display.

_{3 file(s) reviewed, no comment(s)
Edit PR Review Bot Settings}

[nx-cloud]

☁️ Nx Cloud Report

CI is running/has finished running commands for commit 40b1b2f. As they complete they will appear below. Click to see the status, the terminal output, and the build insights.

📂 See all runs for this CI Pipeline Execution

---

✅ Successfully ran 1 target

• nx run-many -t build --parallel=3

---

Sent with 💌 from NxCloud.

[MichaelArestad]

Nice catch! This looks good overall. When we designed this, we were under the impression that Interactions can only be Pass or Fail. This is why we went with the stop icon. Is there a case where there is more than one failure?

[yannbf]

Nice catch! This looks good overall. When we designed this, we were under the impression that Interactions can only be Pass or Fail. This is why we went with the stop icon. Is there a case where there is more than one failure?

They will always pass or fail. The number just means the amount of interaction steps, so I totally get why you're asking.
If a test has, let's say, 10 steps, and it fails on step 5, the count will show 5.

Perhaps this is confusing and it should really just show a square or something else, but with no numbers 🤔

[MichaelArestad]

Perhaps this is confusing and it should really just show a square or something else, but with no numbers.

I'm open to other ideas, but I'm not sure numbers are clear here. I suppose 1 could work as well for consistency.

[cdedreuille]

Thanks a lot @yannbf. Bringing the behaviour back makes total sense. Looking at the different solutions I'm not sure I understand why the inside of the panel need to change. It seems that the solution is in the the tab itself. Visually speaking, while adding a red badge could work I think there's something to explore to have failed tabs that fully reflect its own state.

In this example the warning is only on the badge but the rest of the tab is still blue active. The badge could. be misinterpreted as a notification or failure to receive notification. If we think about Storybook as a testing tool I think we could explore using our UI bolder to reflect the step of it. In that case, perhaps the full tab should reflect the state of its content. Something to explore.