Reusing component explorer for my components

[GordonSmith]

I am considering migrating a viz framework to use web components, assuming the paradigm works, is there any reason why I wouldn't be able to copy the component explorer to my web site and use it as part of my documentation?

[EisenbergEffect]

Great question @GordonSmith You can absolute do that.

However, our team has recently been discussing the future of the component explorer. It has a lot in common with Storybook. One thing we are considering is turning some of the features of the component explorer into Storybook plugins so that we could eliminate the duplication. We would then replace explorer with a souped up version of Storybook. The tooling plugins would then be made available as part of our tools offering so that the community could use them with their own Storybook setups.

I'd love to hear your thoughts on this.

[GordonSmith]

Thanks for the heads up - as I haven't used Storybook myself I can't really comment.

What I am in the market for is an off the shelf "component explorer" for consumers of my components (ideally one which can auto discover published attributes etc.).

FWIW I am also looking at the component explorer from the React FluentUI pages...

[EisenbergEffect]

I definitely think it's worth taking a look at Storybook to see if that will fit your needs. They have support for web components as well as React. If that doesn't meet your needs, I'd love to hear what shortcomings you see. Perhaps we can address that with the plugins we're considering.

[KingOfTac]

Has there been any further discussion on moving explorer towards plugins for storybook? Maybe instead of moving to storybook, another solution could be to add the component explorer as something that could be created from the upcoming FAST-cli. I've found that storybook is kind of a pain to customize the appearance or layout if the default doesn't fully fit your needs. The initial load times for storybook also get pretty slow for large component libraries.

[chrisdholt]

I've actually been looking recently at what it would take to convert the React portions of storybook to WC's, primarily to drop legacy dependencies and implementations from the repo. I could probably investigate a bit more what the implications and timeline would require to do this work. I'm not sure how much we could pick up right away, but it could be an interesting opportunity for contribution for folks in that case.

[KingOfTac]

I have a rather crude explorer built 100% using fast including router. It has some bugs and needs a major overhaul, but I would rather contribute to something the community could use and fork for their own projects if that's the road you want to go down.

[KingOfTac]

One major issue is Monaco editor's compatibility with shadow dom. I have yet to figure out a good way to wrap it with a fast component.

[EisenbergEffect]

If you don't have any styles you need to apply, you can set the shadowMode to null for the custom element in the decorator config and it will render to light dom. A common solution in this case is to just render to light dom. However, if you do need styles, then you can keep shadow dom on but write your styles to be based on slotted selectors. Then just have the web component manually put the Monaco editor in the light dom. So, you distribute a single component that encapsulates and applies its styles through slotted selectors and that also handles setting up and rendering Monaco as a light dom child.