How to infer required properties in Angular and Lit with decorators?

[kasperpeulen]

We have been trying hard to get stricter types working in Storybook 7.0 for Typescript.

We want to able to give a type check warning when a required property is missing like here in React:

We also got this working in Vue (2 and 3) and Svelte, as we could provide the types that the custom language server extension gives us. However, I could not find a way for Angular and Lit, with uses class together with decorators. The decorators provide runtime metadata, but do not offer metadata at compile time as far as I am able to tell.

As a result, it appears impossible to determine if a property in the class is a:

• required property
• or an optional property (but non-nullable due to a default value)
• or a non-nullable internal state variable

Now in theory maybe the custom language server extension of Lit and Angular can also provide us with more rich information, but I couldn't find that. Please pitch in if you know more!

[break-stuff]

For web components (we also use Lit), we configure our stories like so:

import type { Meta, StoryObj } from "@storybook/web-components";

const meta: Meta<MyElement> = {
  title: "Components/My Element",
  component: "my-element",
  args,
  argTypes,
  parameters: {
    actions: {
      handles: events,
    },
  },
};
export default meta;

type Story = StoryObj<MyElement & typeof args>;

export const Default: Story = {...};

You can also use the web components storybook helpers to handle a lot of the heavy lifting for you.

[Marklb]

For Angular, runtime or maybe compile errors could probably be done, but I don't think enough can be gathered from just Typescript.

The following are why I think it would be difficult for Angular, but maybe someone would know a way to get around them:

Until runtime, when the decorators can be called, or compile time, when metadata properties can be set, there isn't anything unique about a component class. I could be wrong, but I don't think types can recognize that something has a decorator that will be called on it.

If you have the following component:

@Component({
  selector: 'example',
  inputs: [ 'inp1' ],
})
class ExampleComponent {
  static ngAcceptInputType_inp3: string | boolean | null | undefined
  
  private _inp3: boolean;
  
  inp1: string
  @Input() inp2: string
  @Input()
  get inp3(): boolean { return this._disabled }
  set inp3(value: boolean) { this._disabled = (value === '') || value }
  @Input('inp4Alias') inp4: string
  @Input({ required: true }) inp5: string
  @Input({ transform: booleanAttribute }) inp6: boolean
}

I think Typescript only sees:

class ExampleComponent {
  static ngAcceptInputType_inp3: string | boolean | null | undefined
  private _inp3: boolean
  inp1: string
  inp2: string
  inp3: boolean
  inp4: string
  inp5: string
  inp6: boolean
}

So, the types Storybook defines were mostly accurate to what a template accepts. Just because you have the type as boolean a template could pass in something else that the input transforms into the correct type with a setter, or now a transform can be used. I think the @Input({ required: true }) only affects AOT compiling, but maybe Storybook should be doing something about notifying those inputs are missing. The types don't allow inp4Alias in args, since it is not the name of a property on the class, but aliasing input names isn't common.

One of the problems with how it currently does the types is args accepts any property of the class, but some properties are not an input or output. I don't think anything can be done about that, through just Typescript, though.

The following are possible solutions I have thought about, but not tried to actually do:

Maybe you could have type files autogenerated in a way that it could work with, but I don't know if that could be done in a way that wasn't too awkward to work with. At the least, it would require a generation process to be run, before the types would work.

For autogenerated, I was thinking in a tsconfig the import types of *.component.ts files for *.stories.ts files could maybe point to an autogenerated *.d.ts that exports the class type, with the input/output properties only and extending a type that could be used in a conditional type to identify it as a component/directive/pipe in types. That is just a thought and it may not be possible to do that in a good way.

I don't know enough about the Angular language server to know if that could be leveraged in anyway for this. It seems to be focused on templates, from what I have seen.