Declare types for Classic Component

[wagenet]

Is it possible to declare alternate types for a component?

This is my attempt:

import TextArea from '@ember/component/text-area';
import Component from '@glint/environment-ember-loose/glimmer-component';
import { TextareaArgs } from '@glint/environment-ember-loose/-private/intrinsics/textarea';

interface CopyTextareaArgs extends TextareaArgs {
  [key: string]: unknown;
}

interface CopyTextareaSignature {
  Element: HTMLTextAreaElement; // TextArea
  Args: CopyTextareaArgs;
}

export default class CopyTextarea extends TextArea {
  readonly = true;

  click(): void {
    (this.element as HTMLTextAreaElement).select();
  }
}

declare module '@glint/environment-ember-loose/registry' {
  export default interface Registry {
    CopyTextarea: Component<CopyTextareaSignature>;
  }
}

Unfortunately, it doesn't seem to work.

app/components/app-badge-row.hbs:4:5 - error TS2344: Type 'null' does not satisfy the constraint 'Element'.

4     <CopyTextarea
      ~~~~~~~~~~~~~
5       class="dw-input badge-markdown-input"
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
6       @value={{this.badgeMarkdown}}
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
7     />

[dfreeman]

I don't know if the deprecate() call has landed in Ember itself yet, but RFC 671 deprecates subclassing (or really doing anything in JS/TS space with) built-in components, so that's likely not something we're going to aim to make first-class here.

That said, I think your issue in the snippet you posted is that you're putting an instance type in the registry, not a constructor type. If you use ComponentLike<CopyTextareaSignature> instead (which is a constructor type), I think it should work.

[boris-petrov]

@dfreeman - are you sure subclassing the built-in components is/will be deprecated? I quickly glanced over the RFC and didn't see that? Can you point us to the text please?

[dfreeman]

Subclassing is called out near the bottom of the "The Problems" section as something that leaks implementation details.

Because of this, the fact that they are implemented as `Ember.Component`
subclasses are highly observable. Some common use cases and consequences are:

1. These classes can be imported for subclassing. For example, an app can
   export a custom subclass of `TextField` at, say, `app/components/my-text-field.js`
   which can then be invoked as <MyTextField>.

<!-- ... -->

These are all opportunities for the internal implementation to leak, therefore
making changes to how the built-in components are implemented – specifically
stop subclassing from `Ember.Component` – will likely be a breaking change for
some, even if the new implementations otherwise supported all documented APIs
perfectly.

In @wagenet's snippet above, accessing this.element is a great example of that—that field is only available because Textarea is an Ember.Component, which is meant to be (or at least become, in the future) an implementation detail that could change.

[boris-petrov]

Yes, in this case I understand. But if one subclasses and uses only "public API" stuff... I'm not sure that is a problem. It is actually impossible to prevent that. In any case sorry for the off-topic here.

[dfreeman]

But if one subclasses and uses only "public API" stuff...

That's exactly the point though—there is no public API for components outside of templates 😄

Even the fact that the component is a class is an implementation detail, since I could equally make a random POJO {} into a component by giving it an appropriate component manager.

[wagenet]

I still couldn't figure this out, but I decided to just change stuff to not subclass.