Tech/introduce-preview-api

[ndelangen]

Refactor the preview packages

Introduces a new package called preview-api which should be the only package the user would ever want to import in any code that runs on the preview side.

This replaces the need to ever import from @storbook/addons, @storybook/preview-web, @storybook/client-api,@storybook/store,@storybook/core-client.

All these packages are unified under this 1 package.

Likely these packages listed will be removed at some point in the future, simplifying maintenance & future development. It also means users will have an easier time importing the right api from the right place.

I've updated all our code to use the new package.

This should all be backwards compatible, if a user were to still import @storybook/client-api for example they'd see a deprecation warning in the console of their browser, but everything should work.

Some of the code of these packages has actually moved, that includes these 4 packages: client-api, core-client, preview-web and store. Other packages still have their code in the original place, and the preview-api package simply re-exports some or all exports from the original.

The intent is to move all code for the preview into this package when it's not shared anywhere else (runs in the preview only). I decided to make this PR with 4 packages moved, to show it's possible, demonstrate backwards compatibility, and get approval from the other maintainers / rest of the team.

An important step I'm still keen on making is is to split @storybook/addons into 2 packages, 1 for the preview (code should be moved to @storybook/preview-api and the other part for code that runs in the manager (mostly for registering addon panels/etc.) into the @storybook/api package... which I intent to rename to @storybook/manager-api.

Diagram of packages (note that manager-api is currently called api, and this is a proposed change not included in this PR)

This is what prebundling really means:

At the builder level we break the dependency graph into pieces. The are pieces that are stories, and there are pieces that is storybook's runtime code. By breaking the storybook runtime code away from the work that the builder has to do, we gain better performance, because there is less work for the builder to do. The user never has their builder compile storybook's code.

SO the package re-architecture (right now) looks like this:

I've moved code of the 4 packages listed TO preview-api, and for backwards compatibility those packages re-export from preview-api.
@storybook/addons is currently doing something slightly different, because of it's dual use in both the preview and manager (which is a problem) that I will still do. Possibly as part of this PR.

[valentinpalkovic]

Could you leave a comment, why this change is needed?

[ndelangen]

Yes!

See here: https://circleci.com/gh/storybookjs/storybook/444855

When we build our code for dist, we used to compress our variable names.
Turns out when generating variables names like this _2 is a valid identifier.
But when you try and create a function with that name using eval or new Function() it throws.

I decided that not compressing variable names would probably be the right choice here, considering this might make debugging way way easier too.

[tmeasday]

@ndelangen can all these nice pictures end up in a README or something please?

[tmeasday]

Love it @ndelangen !