Skip to content

fix: Allow undefined ref for SearchBarCommands in SearchBarProps #2724

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

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

Pnlvfx
Copy link

@Pnlvfx Pnlvfx commented Feb 20, 2025

Description

This change updates the type definition for SearchBarProps to accept a ref that can be undefined. Previously, the ref was forced to be non-nullable, which required developers to use workarounds (like non-null assertions) even though React handles null/undefined refs gracefully. With React 19, the framework ensures that refs are managed correctly regardless of their empty initial state.

By allowing n undefined ref, we align the type definitions with React's natural behavior and improve the developer experience by eliminating unnecessary TypeScript errors. This change has no runtime impact, as the component lifecycle guarantees that the ref will be properly set before it is used.

Example that trigger the Typescript Error below:

const searchBarRef = useRef<SearchBarCommands>(undefined);

useLayoutEffect(() => {
  navigation.setOptions({
    headerSearchBarOptions: {
      tintColor: colors.text,
      ref: searchBarRef,
    } satisfies SearchBarProps,
  });
}, [navigation, colors.text]);

Type 'RefObject<SearchBarCommands | undefined>' is not assignable to type 'RefObject'.
Type 'SearchBarCommands | undefined' is not assignable to type 'SearchBarCommands'.
Type 'undefined' is not assignable to type 'SearchBarCommands'.ts(2322)

@Pnlvfx
Copy link
Author

Pnlvfx commented Feb 20, 2025

Description

This change updates the type definition for SearchBarProps to accept a ref that can be undefined. Previously, the ref was forced to be non-nullable, which required developers to use workarounds (like non-null assertions) even though React handles null/undefined refs gracefully. With React 19, the framework ensures that refs are managed correctly regardless of their empty initial state.

By allowing n undefined ref, we align the type definitions with React's natural behavior and improve the developer experience by eliminating unnecessary TypeScript errors. This change has no runtime impact, as the component lifecycle guarantees that the ref will be properly set before it is used.

Example that trigger the Typescript Error below:

const searchBarRef = useRef<SearchBarCommands>(undefined); // or null

useLayoutEffect(() => {
  navigation.setOptions({
    headerSearchBarOptions: {
      tintColor: colors.text,
      ref: searchBarRef,
    } satisfies SearchBarProps,
  });
}, [navigation, colors.text]);

Type 'RefObject<SearchBarCommands | undefined>' is not assignable to type 'RefObject'. Type 'SearchBarCommands | undefined' is not assignable to type 'SearchBarCommands'. Type 'undefined' is not assignable to type 'SearchBarCommands'.ts(2322)

@Pnlvfx
Copy link
Author

Pnlvfx commented Feb 20, 2025

Test passed successfully.

@kkafar
Copy link
Member

kkafar commented Feb 24, 2025

hey! thanks for the PR. I took a quick glance I'm not convinced of backward compat of your solution with react 18 yet.
I'll try to find some time this week to test this.

@Pnlvfx
Copy link
Author

Pnlvfx commented Apr 18, 2025

hey! thanks for the PR. I took a quick glance I'm not convinced of backward compat of your solution with react 18 yet. I'll try to find some time this week to test this.

Ehy no problem. Do you want me to do it using null instead of undefined? I usually use undefined with imperative ref as I prefer it, but yes, maybe react 18 doesn't support undefined, but should definetely support null. If you want I can do it, actually all react 19 users will have this issue, and as far as I know the only way to fix it is provide a nullable (initial) value to the ref.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants