CLI: Avoid id changes after storiesof-to-csf migration

[Hypnosphi]

Issue: sometimes running storiesof-to-csf codemod leads to story id changes

What I did

1. Replaced camelCase with PascalCase in export names which rules out clashes with reserved keywords
2. Replaced Story suffix with _ prefix which gets stripped during conversion to id

[vercel]

This pull request is being automatically deployed with ZEIT Now (learn more).
To see the status of your deployment, click below or on the icon next to each commit.

🔍 Inspect: https://zeit.co/storybook/monorepo/5c8fki44v
🌍 Preview: https://monorepo-git-avoid-id-changes.storybook.now.sh

[Hypnosphi]

I wanted to use pipeline operator here, but I'm not sure whether it's OK with other contributors:

let key = name |> camelCase |> upperFirst

[shilman]

🤔 stage 1 ....

[ndelangen]

Let's not use language features that typescript doesn't support?

[shilman]

This makes sense & is definitely an improvement over the existing behavior.

My one concern is about PascalCase, since I don't know whether we should encourage that convention for story exports. What do you think about changing it to _${camelCase(name)} in those cases?

Curious to hear what you and others think.

[atanasster]

Just my 0.02c camelCase seems more natural in javascript projects /coming from a 20+ years Pascal guy :)/

[tmeasday]

I discussed this a little with @shilman and I think I agree that the "prefix reserved words with _" solution is probably a better way to achieve the same goal. Here's my thought process:

1. If we update the codemod to PascalCase but not our examples, people using the codemod are going to be put off: "this doesn't look like the docs, did it break or something?". I don't love that.
2. If we update our examples, the first thing a new user to storybook is going to see is something like:

export Welcome = () => <Welcome />;

I guess technically there's nothing wrong with a pascal-cased export but I reckon if I was a new user it would put me off.

[Hypnosphi]

camelCase seems more natural in javascript projects

But using PascalCase for components in JSX-based frameworks and libraries like React is quite a common practice. And the stories look pretty much like components (even if technically they aren't), and we even allow React hooks in them. So maybe PascalCasing them by default is a good thing? Among other things, it would:

1. Remove the need to suppress react-hooks/rules-of-hooks ESLint rule when using React hooks. Right now it complains because it doesn't treat a camelCased function as a component
2. Make it easier to reuse stories inside other stories. You could do just <MyStory /> without reassignments like const MyStory = myStory

If we update the codemod to PascalCase but not our examples, people using the codemod are going to be put off: "this doesn't look like the docs, did it break or something?". I don't love that.

It makes sense to me to update the examples as well. I can do it on approval

If we update our examples, the first thing a new user to storybook is going to see is something like:

export Welcome = () => <Welcome />;

Not really. What they actually would see in case of official-storybook is

export const ToStorybook = () => <Welcome showApp={linkTo('Button')} />;

[tmeasday]

That's a good point @Hypnosphi -- I think I am convinced, although it seems an important change.

[shilman]

That might be the case for React, but not for any of our other frameworks where we're returning JS objects... My gut still says _camelCase is the way to go. That said, I'm not married to that, so if you feel strongly about PascalCase then I reluctantly approve. 😄

[Hypnosphi]

OK. Given that the benefits for React (and maybe other JSX-based) are practical while the downsides for other frameworks are purely stylistical, let me migrate examples and CLI templates then