Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use generics to type data property in GrayMatterFile interface #69

Closed
michaeljota opened this issue Apr 15, 2018 · 1 comment
Closed
Labels
feature request A request for new functionality.

Comments

@michaeljota
Copy link

I originally posted this in #67, but I realize that this is actually a bug when using Typescript.

I would like to type the data property in GrayMatterFile interface. With a generic type, of curse. Could be done with this:

  interface GrayMatterFile<T = any, I extends Input = Input> {
    data: T;
    content: string;
    excrept?: string;
    orig: Buffer | I;
    language: string;
    matter: string;
    stringify(lang: string): string;
  }

Using default generics again, allow this to keep backward compatibility, if the T is declared after the I.

  interface GrayMatterFile<I extends Input = Input, T = any> {
    data: T;
    content: string;
    excrept?: string;
    orig: Buffer | I;
    language: string;
    matter: string;
    stringify(lang: string): string;
  }

This is because object does not allow accessing any custom properties, so effectively there are only a couple of properties that you can access when using this with Typescript. By using generics, developers are allowed to shape that property as they probably now the actual model of data property. By using defaults, if the developer does not provide a type, then data will be any, allowing to access any custom property.

@robertmassaioli
Copy link
Collaborator

In 4.0.2 we have used the type { [key: string]: any; } because without validation that the parsed frontmatter matches the type T, it is probably not a good idea to just cast the read-in type to T. It's just going to result in unexpected errors.

You can add a validation + typecast logic on top of that type if you like.

At any rate, I'm going to close this as "won't fix". Cheers.

@robertmassaioli robertmassaioli added the feature request A request for new functionality. label Jan 16, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request A request for new functionality.
Projects
None yet
Development

No branches or pull requests

2 participants