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

Figure out a way to deal with common types #27

Open
alber70g opened this issue Jun 24, 2022 · 1 comment
Open

Figure out a way to deal with common types #27

alber70g opened this issue Jun 24, 2022 · 1 comment
Labels
discussion Needs (architectual) discussion to make a decision no-issue-activity

Comments

@alber70g
Copy link
Member

alber70g commented Jun 24, 2022

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.

// defined in @kadena/types
export type SomeGenericType = {
  name: string;
  color: 'blue' | 'red' | 'green';
};


// defined in @kadena/some-lib
import type { SomeGenericType } from '@kadena/types';

function getName({ name }: SomeGenericType) {
  return name;
}

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-lib
export type MySpecificType = {
  name: string;
};

function getName({ name }: MySpecificType) {
  return name;
}

Also, api-extractor can manage the type defenition .d.ts. generation based on public, alpha, beta, non-private JS/TSdoc

@alber70g alber70g added the discussion Needs (architectual) discussion to make a decision label Jul 1, 2022
@github-actions
Copy link
Contributor

This issue is stale because it is open for 60 days with no activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion Needs (architectual) discussion to make a decision no-issue-activity
Projects
None yet
Development

No branches or pull requests

1 participant