Update getStorybook to return story parameters

[timhaines]

Issue:
v4 of Storybook introduced story parameters, but getStorybook doesn't return them. This PR updates getStorybook so it does return parameters.

This allows in-browser consumers to access story parameters with a more supportable window['__STORYBOOK_CLIENT_API__'].getStorybook() instead of window['__STORYBOOK_CLIENT_API__']['_storyStore']['_data']

What I did

Updated the getStorybook function to return parameters

How to test

Unit tests

[Keraito]

From a code perspective there's not much wrong with this, tagging @tmeasday to judge the behaviour of this as he was responsible for the tagged PR.

[codecov]

Codecov Report

Merging #5549 into next will not change coverage.
The diff coverage is 100%.

@@          Coverage Diff          @@
##            next   #5549   +/-   ##
=====================================
  Coverage   33.1%   33.1%           
=====================================
  Files        638     638           
  Lines       9264    9264           
  Branches    1340    1318   -22     
=====================================
  Hits        3067    3067           
  Misses      5571    5571           
  Partials     626     626

Impacted Files	Coverage Δ
lib/client-api/src/story_store.js	75% <100%> (ø)	⬆️
lib/client-api/src/client_api.js	79.59% <100%> (ø)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update d9cd83c...04e2b96. Read the comment docs.

[ndelangen]

Hey @timhaines In v5 there's a new api for getting the stories data complete with parameters:

https://github.com/storybooks/storybook/blob/next/lib/client-api/src/story_store.js#L111-L123

Long term I'd like to remove the getStorybook api.

Would be happy to merge this PR though in the meantime.

[tmeasday]

I think returning extra data in getStorybook() is good, but do we need to change the return value of getStories()? That part doesn't seem as necessary?

PS We use code something like

.getStorybook()
  .map(({ kind, stories }) =>
    stories.map(({ name }) => {
      const { parameters } = storyStore.getStoryAndParameters(kind, name);

Although I'm looking at our code and it says "Annoying to have to do this, we should support this in .getStorybook" so it looks like this change is long overdue ;)

[timhaines]

@tmeasday to address your valid concern, I've left getStories behavior intact, and have introduced getStoriesWithParameters.

Note that getStories is only tested indirectly, as getStoriesWithParameters is now.

[timhaines]

@ndelangen thanks for the heads up on those two functions. I don't think they can be used as is in place of getStories, as they don't preserve the ordering in the same way getStories returns stories.

It's interesting to hear you're planning on deprecating and removing the getStorybook API long-term. Is there anything documented about how you'd like to replace the functionality?

[timhaines]

Closing this in favor of adopting raw() over improving getStorybook().

[ndelangen]

Thanks tim, if were missing any functionality in either .raw or .extract please let me know.

The .extract is for storybook itself, to transfer the stories to the manager.
.raw is for integration purposes such as storyshots.