Thoughts on Storybook "Live" stories. #446
Description
Opening this issue to start a discussion related to "Live" stories and states that I've been thinking about for a while. I'd like to discuss whether we need them, and if so, whether they should be prominent or inconspicuous.
Curious to hear others thoughts on the subject. 🙂
Do we need them at all?
I've been wondering why we need live stories/states to be a first class thing at all? I do think that executing live can be useful for developers who are running the storybook locally, but they can also just comment out the preview state on any story they are working with to achieve the same thing.
On the other hand, live stories/states are not useful for non-devs or folks using https://ui.mydatahelps.org/ or any of the PR generated sites because they can't provide the necessary delegated participant access token. I think it feels a tad clunky/unpolished that the public facing UI storybook has a bunch of "Live" states that will always generate exceptions and fail to load because no one can ever use them successfully outside the dev environment.
Should they be prominent or inconspicuous?
If we determine that they are a necessary part of the storybook for development convenience, then I wonder if we can do something to keep those "Live" stories out of the build for https://ui.mydatahelps.org/ and the PR generated sites. In other words, they would only show up in local dev runs of the storybook, which is the only place I think they can be used anyways. Maybe they can be filtered out somehow when a delegated participant token is not present. Or maybe we don't include them as first class story entries, but as something less conspicuous, so they would be present, but less likely to be seen or used by folks who would not be able to use them anyways.