satisfies operator shadows object this with interface this

🔍 Search Terms

I have been experimenting with the satisfies operator which has been pretty great to avoid having to interface anything. Instead, you can pass around the original object literal with all of its properties clearly shown in code completion.

But. Recently, I noticed there’s a slight problem. I am building this library where I’ve advocated for objects instead of classes or interfaces, everything working perfectly when they are just static objects. Yet when I want to add class-type semantics, namely pass an options and instantiated state that’s available to its functions, I face some difficulties.

This is how my interface looks:

export interface Extension<O = undefined, S = undefined> {
    name: string;
    opts?: O;
    store?: S;
    create?: (opts: O) => this & {
        opts: O;
        store: S;
    };
    onMount?: (editor: Editor, opts: O, store: S) => void;
    onDestroy?: (editor: Editor, opts: O, store: S) => void;
}

// and use it as:

export const paragraph = {
  name: 'paragraph' as const,
  create(opts) {
    this.opts = opts
    this.store = createStore(opts)
    return { ...this, opts, store: this.store }
  }
} satisfies Extension<Options, Store>

Which does work and compile. Except when I access the object from the create function, I notice that the return type of create is actually no more the this of the original object but the this of the Extension interface.

So while the static paragraph object literal is neatly described with its original shape, if I create it with the create function the signature is altered and it then becomes Extension with no type inference about it properties.

At the moment, I am bypassing this by manually augmenting the exposed global property with the return type I'd want from create:

declare module '@library/core' {
  interface Extensions {
    paragraph: typeof paragraph & { opts: Options, store: Store }
    // doesn't work
    //paragraph: ReturnType<typeof paragraph.create>
  }
}

✅ Viability Checklist

• 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 isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
• This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

⭐ Suggestion

My request and general inquiry is, whether it is possible to use the original this—which is available if I remove the satisfies operator—for the create function? Even if I use a custom function eg make(opts: Options) { return this } it always inherits the Extension this even though it's not even defined in the interface which seems wrong. Why does the Extension this overshadow the original object literal this?

In short my suggestion is: satisfies operator should not overload/shadow the original object this inside functions outside the satisfied interface. Although shadowing this inside the interface functions suck as well but probably can't be prevented.

📃 Motivating Example

No more classes! TypeScript satisfies operator makes class-style inheritance and composition magically easy as the object this is no longer shadowed by the satisfied interface in the object functions.

💻 Use Cases

1. What do you want to use this for?

• For making my object literal fully compatible with classes but much clearer and composable

2. What shortcomings exist with current approaches?

• Loss of type inference when using satisfies

3. What workarounds are you using in the meantime?

• I augment the object literal manually: paragraph: typeof paragraph & { opts: Optins, store: Store }

まず、動機となる satisfies の例を再現し、create 内部で推論される this と、satisfies を削除した場合に推論される型を比較します。満たされた Extension インターフェースがどのように関数コンテキストを提供するかを追跡します。元のオブジェクトリテラルの this を保持できるかどうかを明らかにし、その結果生じる型の挙動または設計上の制約を文書化できれば完了です。