[Feat] Improve repo discoverability

[tudorpopams]

The repo is not easily discoverable at this point thus making it hard for developers to use the components hosted here.

• [x] Create docsite application that publishes with --doc mode
• [ ] Add the application docs URL to public-docsite-v9 via Storybook composition
• [ ] Adopt core SB plugins:
  • [ ] @fluentui/react-storybook-addon
  • [ ] @fluentui/react-storybook-addon-export-to-sandbox
• [ ] Improve docs for contrib packages: (handled per owner)
  • [TBD Packages list]

[Hotell]

I see 2 possibilities:

1. Explore storybook composition

https://storybook.js.org/docs/6.5/sharing/storybook-composition

I quickly tried it out and it works, well, kinda:

More investigation is necessary:

• potential issues with different storybook versions ( contrib is on 7, core on 6 - this will change https://github.com/microsoft/fluentui/issues/30858)
• need to double check if docs mode is supported with composition ( otherwise we cannot use it in order to maintain same UX )
• aggregate contrib storybooks under 1 common SB in order to be able to use 1 deploy link for all contrib storybooks

2. Embrace libraries/stories packaging story we have within core

• publish stories packages from contrib and consume those packages within core public-docsite-v9
  • Cons:
  • exposing non production ( storybook ) assets to npm ( we could use other registry ofc )
  • additional build processing on core side when building docsite-v9

[dmytrokirpa]

Added another option to the list:

Option 1: Create a static page(s) in public-docsite-v9

This option involves creating static pages that list all packages with short descriptions and links to standalone Storybooks.

Pros:

• Simplicity: This approach is straightforward and easy to implement. It involves creating static page(s) that list all packages with short descriptions and links to standalone Storybooks.
• Low Maintenance: Once the static pages are created, they require minimal maintenance. Updates to individual Storybooks do not necessitate changes to the static pages.
• Separation of Concerns: Each package maintains its own Storybook, reducing the risk of conflicts and making it easier to manage individual Storybooks.

Cons:

• User Experience: Users need to navigate away from the main site to view the Storybooks, which can be inconvenient and disrupt the user experience.
• Inconsistent Look and Feel: Since each package maintains its own Storybook, there might be inconsistencies in the visual appearance and user interface across different Storybooks.
• Scalability: As the number of packages grows, maintaining and updating the static pages can become cumbersome.

Option 2: Storybook composition

This approach composes stories for all fluentui-contrib packages into one website (Storybook in docs only mode, re-using the same Storybook presets and plugins from the core).

Pros:

• Unified Experience: Composing stories for all fluentui-contrib packages into one website provides a unified and consistent user experience.
• Reusability: Re-using the same Storybook presets and plugins from the core ensures a similar visual appearance and functionality across all packages.
• Centralized Management: Managing all stories in one place simplifies Storybook updates and maintenance.

Cons:

• Complexity: This approach is more complex to implement and time consuming, as it requires updating existing stories and changing current storybook setup. Also for unified experience we need to copy-paste or publish or re-use Storybook presets and plugins from public-docsite-v9

Option 3: Publish stories packages from contrib and consume those packages within core public-docsite-v9

Pros:

• Modularity: Publishing stories as packages allows for modular and reusable components. Each package can be independently updated and maintained.
• Integration: Consuming these packages within the core public-docsite-v9 ensures a consistent look and feel while leveraging the existing infrastructure.
• Scalability: This approach scales well as new packages can be easily added without significant changes to the core site.

Cons:

• Initial Setup: Setting up the infrastructure to publish and consume story packages requires initial effort and configuration.
• Dependency Management: Similar to the second option, ensuring that all packages are compatible with the core site can be complex.

[Hotell]

option 1 won't scale / nor will fix existing issues with contrib "docs state of the art"

option 3 is unnecessary "javascript golfing" without any real benefit ATM

option 2 is what we want

• current state of contrib "docs" is beyond ideal, inconsistent, no "documentation context" and scattered around various urls, not automatically exposed to public and the list goes on
  • example of current "docs" for chat component
  • we don't wanna expose something like this as a part of official core library
• contrib docs should follow the same high quality standard of documentation
• we should aim to get something like https://react.fluentui-contrib.dev/ working future-wise
• once we have application for "docs" setup in contrib, it's matter of 1 time configuration in core public-docsite-v9 application via storybook composition which will propagate without no further need of maintenance

the progress/implementation will be gradual:

1st part:

• creating docs application that publishes with --doc mode
• adding the application docs url to core via composition

2nd part:

• make storybook parts public ( which is already planned for Q3 - unified DX initiative )
• adopt core SB plugins

3rd part

• improving contrib docs ( handled per owner )

ty