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

Feature request: allow unique types #211

Open
angrybacon opened this issue Oct 27, 2023 · 1 comment
Open

Feature request: allow unique types #211

angrybacon opened this issue Oct 27, 2023 · 1 comment

Comments

@angrybacon
Copy link

In order to enforce specific type usage for my React components I'd like to output unique typings with the library.

For context, I use typed-scss-modules to output types for some of the re-usable values declared in SCSS. And the idea would be to enforce my component props use those specifically. Doing so would also enable completions for most IDE when completing said props.

Since outputting enums would be a bit more work and since they are a more controversial option, how about having the possibility to output unique symbols rather than plain strings through options?

const classNameToNamedTypeDefinition = (
  className: ClassName,
  uniqueSymbol: boolean
) => {
  const uniqueTyping = uniqueSymbol ? " & { readonly '': unique symbol }" : '';
  return `export declare const ${className}: string${uniqueTyping};`;
};
@skovy
Copy link
Owner

skovy commented Nov 26, 2023

interesting, i haven't seen this approach used for unique typings before

conceptually, i like the idea and understand what you're going for. from a maintenance standpoint, i'm on the fence if i'd want this code to live in the library and need to maintain it.

what if this class name to type def function was exposed as a config option that could override the default? this way when the next person wants to customize the type output we don't need to add another configuration and more code, or if TypeScript it's proper support for unique types with this hack then this library wouldn't need to change.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants