Introduce a new function to the JSX namespace called convertProperties (subject to change) which takes a component and returns an object representing its JSX props.
declare namespace JSX {
// today's behavior
function convertProperties<P>(component: (JSX.ElementClass & { new(): { props: P } }) | ((props: P) => JSX.Element)): P;
// alternatively, if this were to supercede IntrinsicAttributes rather than just working alongside it
function convertProperties<P>(component: (props: P) => JSX.Element): P & JSX.IntrinsicAttributes;
function convertProperties<P, T extends { props: P }>(component: JSX.ElementClass & { new(): T }): P & JSX.IntrinsicAttributes & JSX.IntrinsicClassAttributes<T>;
}
When the typechecker sees a component expression (e.g. <MyComponent prop={val} />), it will determine the types of the required properties by performing a virtual call to JSX.convertProperties with the provided component type and using the return type. For example:
The Solid framework is very similar to React, but rather than tracking reactive dependencies with an explicit dependencies array like in React's useMemo and useEffect, Solid requires calling a function to retrieve the value of a piece of state, allowing for implicit dependency tracking based on which states were previously fetched the last time the memo/effect callback ran (see https://www.solidjs.com/guides/reactivity#introducing-primitives). It is a similar concept to Knockout's observables.
However, when it comes to component properties, Solid uses proxy dereferences instead of explicit function calls. This leads to a common footgun where destructuring the props object like one might do in React will prevent dependencies from being tracked (https://www.solidjs.com/guides/faq#why-do-i-lose-reactivity-when-i-destructure-props). An alternative design could have had the jsx factory function wrap every prop in a reactive getter before bundling them into the props object.
By separating the prop types between the component creation and the JSX where it's used, TypeScript would be able to support such a design in a new web framework.
š» Use Cases
See above.
Another similar use case could be:
type DetailedProps<P> = {
[K in keyof P]: {
value: P[K];
prevValue?: P[K];
}
}
declare namespace JSX {
function convertProperties<P>(component: ((props: DetailedProps<P>) => JSX.Element)): P;
}
This feature would also allow performing the reverse operation of JSX.IntrinsicAttributes. For example:
declare namespace JSX {
function convertProperties<P>(component: ((props: P) => JSX.Element)): Omit<P, 'parent'>;
}
type PropsWithParent<T> = T & {
parent?: JSX.Element;
};
function MyComponent({ parent }: PropsWithParent<{}>) {
// ...
}
function App() {
return <MyComponent />;
}
Alternative Designs
Alternatively, a solution which is slightly less powerful but likely just as useful in 90% of cases could be to declare generic types on the JSX namespace like is done with JSX.IntrinsicClassAttributes<T>:
declare namespace JSX {
// same behavior as today
type TransformProps<P> = P;
// some use cases
type TransformProps<P> = { [K in keyof P]: P[K] extends () => infer R ? R : never };
type TransformProps<P> = Omit<P, 'parent'>;
// or in reverse, deriving JSX prop types via inference like in the earlier examples
type TransformProps<P> = SignalProps<P>;
type TransformProps<P> = P & { parent?: JSX.Element };
}
Suggestion
š Search Terms
ā Viability Checklist
My suggestion meets these guidelines:
ā Suggestion
Concept based on #14729
Introduce a new function to the
JSX
namespace calledconvertProperties
(subject to change) which takes a component and returns an object representing its JSX props.When the typechecker sees a component expression (e.g.
<MyComponent prop={val} />
), it will determine the types of the required properties by performing a virtual call toJSX.convertProperties
with the provided component type and using the return type. For example:š Motivating Example
The Solid framework is very similar to React, but rather than tracking reactive dependencies with an explicit dependencies array like in React's
useMemo
anduseEffect
, Solid requires calling a function to retrieve the value of a piece of state, allowing for implicit dependency tracking based on which states were previously fetched the last time the memo/effect callback ran (see https://www.solidjs.com/guides/reactivity#introducing-primitives). It is a similar concept to Knockout's observables.However, when it comes to component properties, Solid uses proxy dereferences instead of explicit function calls. This leads to a common footgun where destructuring the
props
object like one might do in React will prevent dependencies from being tracked (https://www.solidjs.com/guides/faq#why-do-i-lose-reactivity-when-i-destructure-props). An alternative design could have had the jsx factory function wrap every prop in a reactive getter before bundling them into theprops
object.By separating the prop types between the component creation and the JSX where it's used, TypeScript would be able to support such a design in a new web framework.
š» Use Cases
See above.
Another similar use case could be:
This feature would also allow performing the reverse operation of
JSX.IntrinsicAttributes
. For example:Alternative Designs
Alternatively, a solution which is slightly less powerful but likely just as useful in 90% of cases could be to declare generic types on the
JSX
namespace like is done withJSX.IntrinsicClassAttributes<T>
: