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

Allow value pointing to a class or whose type has a new signature to be used as a type #45013

Closed
5 tasks done
JoshuaKGoldberg opened this issue Jul 13, 2021 · 5 comments
Closed
5 tasks done
Labels
Working as Intended The behavior described is the intended behavior; this is not a bug

Comments

@JoshuaKGoldberg
Copy link
Contributor

Suggestion

πŸ” Search Terms

refers to value used as type static class generic

βœ… Viability Checklist

My suggestion meets these guidelines:

  • This wouldn't be a breaking change in existing TypeScript/JavaScript code
  • This wouldn't change the runtime behavior of existing JavaScript code
  • This could be implemented without emitting different JS based on the types of the expressions
  • This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
  • This feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion

When a class is created by a static method, there doesn't seem to be a way to directly use it as a class type.

πŸ“ƒ Motivating Example

class BaseClass {
    constructor() {}

    static cloneClass() {
        return class extends this { };
    }
}

function takeBase(base: BaseClass) {} // Ok
takeBase(new BaseClass()); // Ok

const CreatedClass = BaseClass.cloneClass();

function takeCreated(created: CreatedClass) {}
//                            ~~~~~~~~~~~~
// 'CreatedClass' refers to a value, but is being used as a type here.
// Did you mean 'typeof CreatedClass'?

takeCreated(new CreatedClass()); // Ok

While CreatedClass is indeed a value, it's a value that happens to be equal to a class.

πŸ’» Use Cases

In general, class factories like this are rather unwieldy to set up in the type system.

For a specific use case, see gr2m/javascript-plugin-architecture-with-typescript-definitions#57, as posted in SO at https://stackoverflow.com/questions/68201386/how-to-make-required-constructor-options-optional-when-they-were-set-using-mycla. Those Oktokit classes have a static defaults member that returns a new class. That new class has a constructor parameter whose type information must be informed by the previous static class' generic.

See this playground link for a version that uses an interface to describe the class, and this playground link for a verson that purely uses a static class. The former would be resolved nicely by this issue's requested feature; the latter would be doable in a more complex way if #26242 and/or #5863 are implemented.

cc @gr2m

@MartinJohns
Copy link
Contributor

But you can refer to it using the typeof operator. This works just fine:

function takeCreated(created: InstanceType<typeof CreatedClass>) {}

@JoshuaKGoldberg
Copy link
Contributor Author

@MartinJohns true, but that's got pretty bad ergonomics. See the linked issue -- library authors shouldn't have to force the constituents into using type shenanigans like that.

@MartinJohns
Copy link
Contributor

MartinJohns commented Jul 13, 2021

I really don't see how this is "type shenanigans". It's just how the type system is designed and works. And I'd say const variables automatically being imported to the types would be even worse ergonomics.

But const variables not introducing new types is the intended behavior.

Your feature request goes in the same direction as #44681.

@RyanCavanaugh RyanCavanaugh added the Working as Intended The behavior described is the intended behavior; this is not a bug label Jul 13, 2021
@RyanCavanaugh
Copy link
Member

Name resolution isn't allowed to have fallback behavior. Doing this creates a semantic trap where adding a new top-level type possibly changes the meaning of existing code. And obviously we can't change the behavior to prefer an inner-scoped const over an outer-scoped interface; this would be breaking beyond measure.

@typescript-bot
Copy link
Collaborator

This issue has been marked 'Working as Intended' and has seen no recent activity. It has been automatically closed for house-keeping purposes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Working as Intended The behavior described is the intended behavior; this is not a bug
Projects
None yet
Development

No branches or pull requests

4 participants