Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bug: forwardRef ignore Type Check #27558

Closed
HotariTobu opened this issue Oct 20, 2023 · 5 comments
Closed

Bug: forwardRef ignore Type Check #27558

HotariTobu opened this issue Oct 20, 2023 · 5 comments
Labels
Resolution: Stale Automatically closed due to inactivity Status: Unconfirmed A potential issue that we haven't yet confirmed as a bug

Comments

@HotariTobu
Copy link

React version: 18.2.0
TypeScript version: 5.2.2

Steps To Reproduce

  1. Define a component with forwardRef
  2. Do not give type annotation to parameter ref
  3. Use useImperativeHandle
  4. Use the component and pass a ref object
  5. Access the ref object's properties that are not exposed in useImperativeHandle

The reproducible code forked from here:

'use client'

import { forwardRef, useImperativeHandle, useRef } from "react";

const Child = forwardRef((props, ref) => {
  const realInputRef = useRef<HTMLInputElement>(null)

  useImperativeHandle(ref, () => ({
    // focus() {
    //   realInputRef.current?.focus()
    // },
  }))

  return <input {...props} ref={realInputRef} />
})

const Parent = () => {
  const inputRef = useRef<HTMLInputElement>(null)

  function handleClick() {
    inputRef.current?.focus()
  }

  return (
    <div>
      <Child ref={inputRef} />
      <button onClick={handleClick}>Focus the input</button>
    </div>
  )
}
Child.displayName = 'Child'

export default Parent

Link to code example:

https://codesandbox.io/p/sandbox/sweet-cloud-hn34vp

The current behavior

forwardRef with ForwardedRef<unknown> does not cause any type error.
Then an error occurs like below on run-time.

TypeError: _inputRef_current.focus is not a function

The expected behavior

forwardRef components should cause an error when wrong type ref objects are passed through the parameter ref.
It is so that we notice a mistake before run-time.

@HotariTobu HotariTobu added the Status: Unconfirmed A potential issue that we haven't yet confirmed as a bug label Oct 20, 2023
@HotariTobu HotariTobu changed the title Bug: useImperativeHandle ignore Type Check Bug: forwardRef ignore Type Check Oct 20, 2023
@sophiebits
Copy link
Collaborator

cc @eps1lon – I guess the inferred type parameter here ends up as unknown? which I think seems fine but then it seems you shouldn't be able to pass a ref of React.RefObject<HTMLInputElement> to React.ForwardRefExoticComponent<React.RefAttributes<unknown>>

Copy link

github-actions bot commented Apr 5, 2024

This issue has been automatically marked as stale. If this issue is still affecting you, please leave any comment (for example, "bump"), and we'll keep it open. We are sorry that we haven't been able to prioritize it yet. If you have any new additional information, please include it with your comment!

@github-actions github-actions bot added the Resolution: Stale Automatically closed due to inactivity label Apr 5, 2024
@eps1lon
Copy link
Collaborator

eps1lon commented Apr 5, 2024

The main problem here is that you can pass Ref<HTMLInputElement> to a component that accepts Ref<unknown>. You expect to read HTMLInputElement yet the component may write an unknown instance into the ref. This is essentially the same issue as microsoft/TypeScript#30748 i.e. it's a design limitation of TypeScript.

We may be able to fix this at the type level by defaulting the instance type to never instead. Needs to tested in the types though by filing a PR changing https://github.com/DefinitelyTyped/DefinitelyTyped/blob/a449dbfd6f1286eb52cfa4d1c2346771947342c2/types/react/index.d.ts#L1561 to T defaulting to never (function forwardRef<T = never, P = {}>() and then checking if CI passes.

@github-actions github-actions bot removed the Resolution: Stale Automatically closed due to inactivity label Apr 10, 2024
Copy link

github-actions bot commented Jul 9, 2024

This issue has been automatically marked as stale. If this issue is still affecting you, please leave any comment (for example, "bump"), and we'll keep it open. We are sorry that we haven't been able to prioritize it yet. If you have any new additional information, please include it with your comment!

@github-actions github-actions bot added the Resolution: Stale Automatically closed due to inactivity label Jul 9, 2024
Copy link

Closing this issue after a prolonged period of inactivity. If this issue is still present in the latest release, please create a new issue with up-to-date information. Thank you!

@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Jul 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Resolution: Stale Automatically closed due to inactivity Status: Unconfirmed A potential issue that we haven't yet confirmed as a bug
Projects
None yet
Development

No branches or pull requests

3 participants