You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Yes that's a good one. Maybe we need to work on a base set of types to be used. I'm not a big fan of a separate types library. They can become overused, especially when they're broader than what's used in a function.
E.g.
// defined in @kadena/typesexporttypeSomeGenericType={name: string;color: 'blue'|'red'|'green';};// defined in @kadena/some-libimporttype{SomeGenericType}from'@kadena/types';functiongetName({ name }: SomeGenericType){returnname;}
In this example the SomeGenericType is way to broad for the usage. I'd rather have it exported and defined specifically, than made generic:
// defined in @kadena/some-libexporttypeMySpecificType={name: string;};functiongetName({ name }: MySpecificType){returnname;}
Also, api-extractor can manage the type defenition .d.ts. generation based on public, alpha, beta, non-private JS/TSdoc
The text was updated successfully, but these errors were encountered:
Originally posted by @alber70g in #25 (comment)
Yes that's a good one. Maybe we need to work on a base set of types to be used. I'm not a big fan of a separate types library. They can become overused, especially when they're broader than what's used in a function.
E.g.
In this example the
SomeGenericType
is way to broad for the usage. I'd rather have it exported and defined specifically, than made generic:Also, api-extractor can manage the type defenition
.d.ts.
generation based on public, alpha, beta, non-private JS/TSdocThe text was updated successfully, but these errors were encountered: