Core: Fix filters not being applied in WebKit

[JReinhold]

Works on #25852

This ensures that when checking if there is an index to reset, it's not using stale data from before the index was even fully fetched.

What I did

The setFilter function will reset the index after the filter has been added, in an attempt to apply the filter to the index - but it will not reset the index if there isn't any index yet. The problem here was that it was potentially using stale index data to determine if the index was there or not to be reset. It would

1. get index
2. add filters
3. reset index if found in 1

This PR switches around step 1 and 2.

When getting the index and setting filters on initial load, there's a race condition happening between:

1. fetch index.json -> set index in state
2. register filter -> reset index with new filter

In Chromium, the fetch was consistently 120ms while registering filters was about 20 ms. This meant that registering filters would always be first, which was good because then the setIndex call after fetch would use the registered filters.

However in WebKit the race was most often reversed - fetch taking 20ms and registering filters taking 120 ms. I assume this is because WebKit give higher priority to fetches. This would result in the index being set before the filters had been added to the store state, and thus the filters would be ignored.

This race still occurs. But now, when filters are applied after the index has been initially set, setFilter will trigger a new setIndex with the filter.

Nothing changes in Chromium, setIndex will still run after filters, and only run once.

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

1. Navigate to the tags stories at /?path=/story/lib-preview-api-tags--inheritance
2. In both Chrome and Safari, reload many times (with cache disabled) and see that the "Docs Only" and "Test Only" stories should never appear in the sidebar - only "Dev Only".

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>

[nx-cloud]

☁️ Nx Cloud Report

CI is running/has finished running commands for commit cfe6e11. 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 affected -t check -c production --parallel=7

---

Sent with 💌 from NxCloud.

[JReinhold]

I tried an alternative solution, where setIndex would check if there was any filters in the state. If there wasn't it would repeat 1-5 ticks until a filter was found in the state. This was based on the assumption that our new internal static-filter should always be there.

This worked too but felt like too tight a coupling between the filter and the store.