Docs: Add CSF factory API documentation

[yannbf]

Closes #30342
Closes #30329

What I did

This PR introduces documentation for the CSF Factory format.

Checklist for Contributors

Testing

Manual testing

1. Check out this branch
2. Run sync-docs in storybookjs/web locally
3. Run the docs site locally
   • Make sure you've pulled the latest main, so the page-level tabs show up
4. Visit http://localhost:3000/docs/api/csf/csf-factories
   • And visit http://localhost:3000/docs/api/csf to view the other tab

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-storybook/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.

Greptile Summary

This PR introduces comprehensive documentation for the new CSF Factory API, providing examples and guidelines for creating and testing Storybook stories with improved type safety and reusability.

• Added new defineMain and definePreview configuration examples in docs/_snippets/csf-factories-main-example.md and docs/_snippets/csf-factories-preview-example.md
• Added story creation examples using preview.meta() and meta.story() in docs/_snippets/csf-factories-story-example.md
• Added testing integration examples with Vitest in docs/_snippets/portable-stories-csf-factory-run.md
• Updated portable stories documentation with warnings about CSF Factory API preference for React users
• Added documentation for story composition and property reuse through the composed property

[greptile-apps]

_{10 file(s) reviewed, 12 comment(s)
Edit PR Review Bot Settings | Greptile}

[nx-cloud]

View your CI Pipeline Execution ↗ for commit e6e3952.

Command	Status	Duration	Result
nx run-many -t build --parallel=3	✅ Succeeded	1m 59s	View ↗

---

☁️ Nx Cloud last updated this comment at 2025-02-13 13:17:32 UTC

[yannbf]

Interesting 🤔 the codemod only adds "#*": ["./*", "./*.ts", "./*.tsx"] and assumes that users will write #.storybook/preview which will relate to <root>.storybook/preview and if they have the preview file somewhere else, they will have to adjust the import in each file to something like #some-dir/.storybook/preview.

This means users with multiple Storybooks could have multiple imports like #apps/.storybook/preview and #libs/.storybook/preview without having to change anything in their package.json.

Perhaps the codemod should set this more specific field like what Kyle wrote here instead? WDYT @kasperpeulen?

[kylegach]

I see! Thanks for explaining. That's tricky. I see why you did it the current way, but think the way I documented is perhaps a bit more informative? I like that if someone does a Find for #.storybook/preview, they'll come across this.

[yannbf]

It's tricky, I'll leave @kasperpeulen to decide

[kylegach]

@kasperpeulen — Did you have thoughts? I'm still inclined to think it should be the way I've documented here, because:

I like that if someone does a Find for #.storybook/preview, they'll come across this.

[kasperpeulen]

I'm not sure, I will let @shilman decide about this. :P

[kylegach]

Fwiw, I'm 60/40 on my proposal here vs. what was implemented. So unless someone else strongly agrees with me, we can just keep it simple.

[shilman]

I can see both sides. I prefer @kylegach 's proposal slightly in the name of being explicit. If we want to support multiple preview files like you describe @yannbf then we should make that explicit instead and document it here.

[yannbf]

@kylegach this all looks great, thanks for working on the revisions! I can't approve since I opened the PR, so please approve it for me!

[jonniebigodes]

This is shaping up nicely. Thank you for adding the documentation. I appreciate it 🙏 I left some items for you to look into when you can. Let me know, and we'll go from there.