[@types/react] Preserve generic type parameters for component when passed to "lazy" or "memo" #69474
Unanswered
KurtGokhan
asked this question in
Issues with a @types package
Replies: 2 comments 1 reply
-
Thanks for the discussion about "react", some useful links for everyone: Pinging the DT module owners: @johnnyreilly, @bbenezech, @pzavolinsky, @ericanderson, @DovydasNavickas, @theruther4d, @guilhermehubner, @ferdaber, @jrakotoharisoa, @pascaloliv, @Hotell, @franklixuefei, @Jessidhia, @saranshkataria, @lukyth, @eps1lon, @zieka, @dancerphil, @dimitropoulos, @disjukr, @vhfmag, @hellatan, @priyanshurav, @Semigradsky, @mattpocock. |
Beta Was this translation helpful? Give feedback.
0 replies
-
@eps1lon tagging you since you seem to be actively working on types. Any thoughts about this? Is there a plan to improve these types for React 19? |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
forwardRef
is going to be unnecessary in React 19 and it made the community happy. One of the reasonsforwardRef
is disliked is because it doesn't preserve generic type parameters of a component. Suppose a component like this:When this component is wrapped in a HOC like
forwardRef
,memo
orlazy
, the component loses the generic ability.See this behavior in TS playground.
Proposed solution
The culprit is the
ExoticComponent
type. It converts any component to a simple component like(props: P) => ReactNode
without preserving the generic type parameters.There is a simple solution to this issue. See a POC of the proposed solution giving off the expected behavior in TS playground. My POC doesn't consider class components though. If I get a green-light, I can make a reasonably backward-compatible solution.
Related discussions
See also #69029
Beta Was this translation helpful? Give feedback.
All reactions