Improve typing on generated storybook components

[will-ks]

This PR fixes a couple of issues with the storybook stories generated for each component.

1. Currently if you're using TypeScript with strict mode, the story contains a type error due to args not being properly typed:

This PR adds type assertion to the generated story, so the args parameter is now properly typed.

2. The story, viewed in Storybook, shows a warning about the component not being set up for controls:

This PR sets the component field in the story metadata. This means that the generated story will now show auto-generated controls for the component's props, and removes the warning:

[nx-cloud]

☁️ Nx Cloud Report

CI is running/has finished running commands for commit a138f50. As they complete they will appear below. Click to see the status, the terminal output, and the build insights.

📂 See all runs for this branch

---

✅ Successfully ran 4 targets

• cli run build
• cli run build
• cli run build
• cli run build

---

Sent with 💌 from NxCloud.

[netlify]

✅ Deploy Preview for redwoodjs-docs ready!

Name	Link
🔨 Latest commit	a138f50
🔍 Latest deploy log	https://app.netlify.com/sites/redwoodjs-docs/deploys/63076c5f4eca7600085ce647
😎 Deploy Preview	https://deploy-preview-6226--redwoodjs-docs.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site settings.

[dac09]

Thank you so much for this @will-ks - was on our list but couldn't get to yet!

[will-ks]

I just realised there's also stories generated for pages, layouts etc, which should also be given the same treatment. I'll close this PR and reopen when I've fixed the other ones.

[will-ks]

Components, Pages, Layouts and Cells now have the changes.
Only exception is with Cells, I couldn't set the component prop, as it expects a single component but the stories are each rendering a different component. I'm not sure what the best way around that would be.
Also note that I had to change the null that the cell stories were returning to an empty fragment (<></>) as Storybook expects a JSX.Element.

[jtoar]

Thanks @will-ks! I'm not great with TS, but one question: should we use ComponentStory instead of Story from @storybook/react? Two reasons for the suggestion:

• the storybook docs recommend it in tandem with typeof (scroll down to "React-specific utility types" https://storybook.js.org/blog/writing-stories-in-typescript/)
• I still get a red squiggle with just Story. Example:

// Post component

const Post = ({
  title,
  description,
}: {
  title: string
  description: string
}) => {
  return (
    <div>
      <h2>{title}</h2>
      <p>{description}</p>
    </div>
  )
}

export default Post

With Story:

With ComponentStory:

[jtoar]

TODO: add ComponentMeta

[will-ks]

@jtoar Good find, does look like ComponentStory is more appropriate. Will change. Also nice to read from that source you provided that in Storybook v7 stories get more concise. Hopefully upgrading to v7 is on the roadmap for Redwood.

[dac09]

Thanks again @will-ks -

Just added a commit to regenerate stories in our fixtures (which we use for smoke-tests). The changes are looking good to me, except for in Cells, as you've mentioned previously - essentially we can't spread the args because the type is unknown. I wonder if we can somehow use our utility types for cells to address this.

The other thing we discussed was also whether its worth including the type ComponentMeta - this is in the storybook docs (https://storybook.js.org/docs/react/writing-stories/args) - when you switch to the TS tab. I'm not exactly sure what it's purpose is, apart from maybe if the story itself is imported? Maybe in Redwood it doesn't matter since we automatically import it for you anyway?

[jtoar]

Hopefully upgrading to v7 is on the roadmap for Redwood.

@will-ks it certainly is, but it's not actually out yet right? Just alpha releases so far. So in the near future!

[jtoar]

@dac09 I tried using the loading utility type (CellLoadingProps) in the Cell file and it did fix the red squiggles for the Loading story in the stories file. But there's no empty utility type, so what do you think the move would be there?

Here's an alternative: let's just not pass args to Loading and Empty because they don't take any props in the template:

redwood/packages/cli/src/commands/generate/cell/templates/cell.tsx.template

Lines 12 to 14 in 1718499

	export const Loading = () => <div>Loading...</div>
	export const Empty = () => <div>Empty</div>

So this...

export const loading: ComponentStory<typeof Loading> = (args) => {
  return Loading ? <Loading {...args} /> : <></>
}

export const empty: ComponentStory<typeof Empty> = (args) => {
  return Empty ? <Empty {...args} /> : <></>
}

would become...

export const loading = () => {
  return Loading ? <Loading /> : <></>
}

export const empty = () => {
  return Empty ? <Empty /> : <></>
}

Thoughts?

[jtoar]

We actually run into the "Spread types may only be created from object types.ts(2698)" error with pages too. Anything that doesn't have any props specified.

E.g., here's the AboutPage in the test project fixture:

import { Link, routes } from '@redwoodjs/router'
import { MetaTags } from '@redwoodjs/web'

const AboutPage = () => { // 👈 no props
  return (
    <p className="font-light">
      This site was created to demonstrate my mastery of Redwood: Look on my
      works, ye mighty, and despair!
    </p>
  )
}

export default AboutPage

You'll see a red squiggle in the story file:

import type { ComponentMeta, ComponentStory } from '@storybook/react'

import AboutPage from './AboutPage'

export const generated: ComponentStory<typeof AboutPage> = (args) => {
  return <AboutPage {...args} /> // 👈 red squiggle here
}

export default {
  title: 'Pages/AboutPage',
  component: AboutPage,
} as ComponentMeta<typeof AboutPage>

[Tobbe]

I'm not great with Storybook - we just recently started using it at work
So when I first saw this

export const loading: ComponentStory<typeof Loading> = (args) => {
  return Loading ? <Loading {...args} /> : <></>
}

I was super confused about the spreading of ...args on <Loading /> exactly because I knew it didn't take any props. I thought maybe Storybook needed/used the extra args for something but eventually figured out it didn't.

So removing the args is a great improvement imho.

[Tobbe]

Just a stylistic preference, but I'd probably do this:

Suggested change

	return Loading ? <Loading {...args} /> : <></>
	return <Loading {...args} /> || <></>

[jtoar]

Looking at this again, do we actually need to handle this case? (Where Loading isn't exported by the Cell right?) If Loading isn't defined, isn't TS going to complain when we import it further up?

import { Loading, Empty, Failure, Success } from './PostCell'

It looks like here we'll get something like Module '"./PostCell"' has no exported member 'Loading'.ts(2305).

[Tobbe]

That would be even better! Just make sure it works the same with strict mode on/off
And JS doesn't care, right? So for the JS template we'd still have to do something like this, yeah?

[jtoar]

Now that I'm more into it, it's a little more nuanced than I thought:

• The component template doesn't have props, so we'd end up in the same TS-unhappy args situation. But components are obviously going to have props. (Sure some don't but most do.) So if we remove args, it's now an exercise for the user to add args back in
• Pages conditionally have props if they take route parameters

So it seems like args is something you want to add after you've added props. (Which for components, happens imminently after generation—not some far-off thing in the future really.) So now we're back to the question of should generators generate unused code that educates users about things they'll need later. Or not? We could always include this as a comment.

@virtuoushub I know we added args in to get the "Show code" feature working. Is there another nuance here we're missing maybe? (It hooks up the controls add-on too right?)

[Tobbe]

• The component template doesn't have props, so we'd end up in the same TS-unhappy args situation. But components are obviously going to have props. (Sure some don't but most do.) So if we remove args, it's now an exercise for the user to add args back in

So maybe the thing to change here is to give generated components some dummy prop? That way we could keep the args spreading for components.

And for pages we could generate the stories with args spreading if the page is generated for a path with parameters (yarn rw g page post /post/{id})

[jtoar]

@Tobbe do you think if we implemented this RFC #5833 (adding interface to TS generators), maybe this'd just be a solved problem?

[Tobbe]

Not sure it'd be a solved problem, but doing that is definitely part of the solution here. I didn't plan to bring that one up again until we were on React18 though, because with React18 they improved the React.FC type. Personally though, I'm all for making the change right now 🙂

[Tobbe]

Am I correct in thinking that propValueParam is used to provide a default value, but you can then let {...args} spread over it to render with a different value for that prop?

[jtoar]

Yeah that's right!

sb_args.mov

[virtuoushub]

@virtuoushub I know we added args in to get the "Show code" feature working. Is there another nuance here we're missing maybe? (It hooks up the controls add-on too right?)

fwiw - Yes, I think it has to do with the controls add-on. Outside of that I do not really know the ramifications for removing it out side of what you already listed.

---

I have not dealt with TypeScript/Redwood in a little bit - Do we generate the component's props as well? I think we could have the generated stories adhere to the correct typings in strict mode if we do unless I am missing something.

[Tobbe]

Currently we generate all components without props. We know most components will probably have props, but it's just really difficult to generate sensible default props, because it varies so much what props you'll want/need

[virtuoushub]

Currently we generate all components without props. We know most components will probably have props, but it's just really difficult to generate sensible default props, because it varies so much what props you'll want/need

Makes sense, imho we might want to consider at least "boiler-plating" empty props since we are generating the components and we know most people will want props. This way we can punt on what sensible defaults are, but at least provide the scaffolding to allow a framework user to easily add in what is needed later.

[Tobbe]

100% agree with that. And it's the route we're going to take when we upgrade to React 18, because then we can also start using the improved React.FC type