Repository: TypeScript
Issue: Hide prototype completions for properties of a component in JSX context
Labels: Suggestion,Help Wanted,Experience Enhancement

### 🔍 Search Terms

prototype methods, hide suggestions, Function.prototype, callable type without prototype, compound components, JSX subcomponents

### ✅ Viability Checklist

- [X] This wouldn't be a breaking change in existing TypeScript/JavaScript code
- [X] This wouldn't change the runtime behavior of existing JavaScript code
- [X] This could be implemented without emitting different JS based on the types of the expressions
- [X] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
- [X] This isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
- [X] This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

### ⭐ Suggestion

Some UI components in libraries like React or Solid can expose "subcomponents" as properties. This pattern is commonly known as "compound components", which can be implemented in multiple ways. In this variant, there is a function ("root component") with properties that are functions ("subcomponents").

When typing JSX, TypeScript's autocomplete helpfully displays available subcomponents. However, `Function.prototype` properties and methods also show up.

This isn't a great experience, since those can **never** be used in this context - `Function.prototype` properties **are never valid components** in any UI framework/library.

For this reason, I'm suggesting that TypeScript never displays prototype methods when in this context (JSX opening element position).

---

More context:

In my way to finding a solution to this DX issue, my initial aim was trying to manually create some sort of "callable type" for the root component that somehow excludes prototype methods. I discussed [with @Andarist on Twitter](https://x.com/daniguardio_la/status/1818324311591239844) and my teammate @ciampo found [this related issue ("Allow to add a call signature to the Mapped Type OR to remove all `Function.prototype` methods")](https://github.com/microsoft/TypeScript/issues/27575) that asks for a similar approach.

However, @Andarist [suggested the solution above](https://x.com/AndaristRake/status/1818338104727781785). I think this approach is superior for a variety of reasons:

- Zero changes required by users. Works out of the box.
- Very narrow scope.
- Has absolutely no potential downsides AFAIK (as state, `Function.prototype` properties are never valid components in any UI framework/library)
- I'm not very familiar with the TypeScript codebase - that said it feels like this would be a much simpler and straightforward change to implement.

### 📃 Motivating Example

Here's a compound component in React (19 for simplicity, since it doesn't require `forwardRef`) in what I call "overloaded" style (root function component with function properties as subcomponents):

```tsx
function Component () {}
Component.Subcomponent = function Subcomponent () {}
```

When using it, the user will input something like this into their editor ([playground link](https://www.typescriptlang.org/play/?#code/GYVwdgxgLglg9mABAYTgWwA4IKZigCgEpEBvAXwChVMc8A6AZRACMJ0sxcpEBeRUSLAQp2tKE1ajOeIqTIBuClSlc6QA)):

```
<Component>
  <Component.
            ^ TypeScript will display suggestions at this point
```

The suggestions will appear:

![image](https://github.com/user-attachments/assets/3e838f62-54a8-401d-8027-a0827b87bc17)


As you can see, prototype methods show up. Ideally, they wouldn't.

### 💻 Use Cases

Authoring components in the "overloaded" compound component API style, with better DX for consumers of the components.