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

fix(typing): use generic TMessage on GiftedChat props #2488

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

Conversation

habovh
Copy link

@habovh habovh commented Mar 22, 2024

When using a custom type for message object, GiftedChat component needs to properly use type parameters when defining props.

Following deb4c45, the type parameter from the generic TMessage when declaring the class component props got lost in translation and thus broke previously valid use cases with custom message object types.

Despite some efforts in 39720e3, the type parameter still wasn't used and it did not fix this use-case.

This PR adds back the generic type parameter to GiftedChat's props.

Minimum repro

import { View, Text } from 'react-native'
import {
  GiftedChat,
  IMessage,
} from 'react-native-gifted-chat'

type ChatMessage = IMessage & {
  user: IMessage['user'] & {
    isAdmin: boolean,
  },
}

type Props = {
  messages: ChatMessage[],
}

export const CustomChat = (props: Props) => (
  <GiftedChat
    messages={props.messages}
    renderMessage={(messageProps) => (
      <View>
        {messageProps.currentMessage?.user.isAdmin && ( // Property 'isAdmin' does not exist on type 'User'.ts(2339)
          <Text>Admin</Text>
        )}
        <Text>{messageProps.currentMessage?.text}</Text>
      </View>
    )}
  />
)

Patch

For those who want to quickly fix the typing issue locally, you may use the following patch.

Patch for node_modules
diff --git a/node_modules/react-native-gifted-chat/lib/GiftedChat.d.ts b/node_modules/react-native-gifted-chat/lib/GiftedChat.d.ts
index 0444a70..77f695e 100644
--- a/node_modules/react-native-gifted-chat/lib/GiftedChat.d.ts
+++ b/node_modules/react-native-gifted-chat/lib/GiftedChat.d.ts
@@ -117,7 +117,7 @@ export interface GiftedChatState<TMessage extends IMessage = IMessage> {
     text?: string;
     messages?: TMessage[];
 }
-declare function GiftedChat<TMessage extends IMessage = IMessage>(props: GiftedChatProps): JSX.Element;
+declare function GiftedChat<TMessage extends IMessage = IMessage>(props: GiftedChatProps<TMessage>): JSX.Element;
 declare namespace GiftedChat {
     var propTypes: {
         messages: PropTypes.Requireable<(object | null | undefined)[]>;

@anthonyespirat
Copy link

anthonyespirat commented Apr 8, 2024

Related issue

src/GiftedChat.tsx:57

export interface GiftedChatProps<TMessage extends IMessage = IMessage> {
  /* Message container ref */
  messageContainerRef?: React.RefObject<FlatList<IMessage>>
  ...

i think should be:

export interface GiftedChatProps<TMessage extends IMessage = IMessage> {
  /* Message container ref */
  messageContainerRef?: React.RefObject<FlatList<TMessage>>
  ...

@habovh
Copy link
Author

habovh commented Apr 8, 2024

@anthonyespirat it looks indeed as it would make sense. Do you have a use-case with a minimum repro maybe?

@anthonyespirat
Copy link

@habovh repro

import { useRef } from "react";
import { FlatList } from "react-native";
import { GiftedChat, IMessage } from "react-native-gifted-chat";

type ChatMessage = IMessage & {
  user: IMessage["user"] & {
    isAdmin: boolean;
  };
};

type Props = {
  messages: ChatMessage[];
};

export const CustomChat = (props: Props) => {
  const containerRef = useRef<FlatList<ChatMessage>>(null);
  return (
    <GiftedChat<ChatMessage>
      messages={props.messages}
      messageContainerRef={containerRef} // Type 'RefObject<FlatList<ChatMessage>>' is not assignable to type 'RefObject<FlatList<IMessage>>'.
    />
  );
};

@habovh
Copy link
Author

habovh commented Apr 8, 2024

@anthonyespirat I've updated this PR to include your suggestion, thanks!

Edit: if you have an open issue that this PR would fix please mention it on this PR as well so it can get automatically closed ☺️

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