stream-chat-react-native icon indicating copy to clipboard operation
stream-chat-react-native copied to clipboard

feat: allow conditionnaly disabling client creation

Open AmauryLiet opened this issue 4 weeks ago โ€ข 2 comments

๐ŸŽฏ Goal

Allow conditional call to useCreateChatClient.

I want a partial deployment of the feature across my user-base. Doing it properly currently requires calling the hook in a conditionnaly called component, which is cumbersome

๐Ÿ›  Implementation details

๐ŸŽจ UI Changes

None

๐Ÿงช Testing

โ˜‘๏ธ Checklist

  • [x] I have signed the Stream CLA (required)
  • [x] PR targets the develop branch
  • [ ] Documentation is updated
  • [ ] New code is tested in main example apps, including all possible scenarios
    • [ ] SampleApp iOS and Android
    • [ ] Expo iOS and Android

AmauryLiet avatar Dec 09 '25 17:12 AmauryLiet

Further discussion

I would be even better to be allowed to instantiate <Chat /> with a prop enabled: boolean. Currently this global provider cannot be mount before chatClient definition, causing the whole app tree to re-mount.

I see that this was somehow planned ou cancelled from some existing conditions (here, here, here ...)

=> I would be happy to open the PR if making client nullable is ok with you

AmauryLiet avatar Dec 10 '25 08:12 AmauryLiet

Help required

How to update the doc? I believe it is not in the same repository, is it?

AmauryLiet avatar Dec 10 '25 08:12 AmauryLiet

@isekovanic what is your mind on this one?

AmauryLiet avatar Dec 15 '25 10:12 AmauryLiet

Hi @AmauryLiet ,

Thanks for your contribution ! This is not something that makes sense for us to have within the SDK currently. And so this particular change I'll have to unfortunately reject from the repository. useCreateChatClient is anyway a utility hook that handles both client creation as well as connecting the user. If you need some more custom behaviour, I would very strongly encourage to simply fork the hook and modify it as you need. It is very unlikely to change anyway.

Regarding enabling a nullish instance of StreamChat on the Chat component, that is also something that does not make sense for the SDK itself. The only reason why it's technically nullable is the fact that the top level context provider has a value that can potentially be undefined and so it has to be checked everywhere. While this might change in the future, the fact that nothing will work without a client within the UI SDK will not.

If you anyway want to A/B test having chat in your application, I would strongly advise wrapping only the navigation stack that is responsible for rendering your chat screens to be wrapped into the Chat component (so as to prevent the rest of the app not rendering if you don't have a client). You anyway won't be needing those screens if the selective release claims a user should not have chat yet.

isekovanic avatar Dec 17 '25 14:12 isekovanic

Hello @isekovanic and thank you for your response

The use case is broader than just A/B testing: we for instance don't want to enable the chat for unauthenticated users (and never will). And as soon as the user logs in, we want to create the chat client and provide it globally.

The current API with non-disableableuseCreateChatClient forces us to call this hook conditionnaly. The only way I identify to achieve that is to have a whole Provider called conditionnaly:

const ChatProvider = ({ children }) => {
  if(getIsChatEnabled()) {
    return (
      <ComponentCallingUseCreateChatClient>
        {children}
      </ComponentCallingUseCreateChatClient>
    );
  }
  return children
}

However that is not acceptable as this provider would be rendered at the top of the react tree, and would cause a global re-mount of all children components

What would be your recommended way of handling this situation?

AmauryLiet avatar Dec 17 '25 16:12 AmauryLiet

Hi @AmauryLiet ,

Yep, I understand what you're trying to achieve - I'm just saying that you can feel free to simply copy the hook over (within your code) and do all the modifications you'd need. You might even decide not to connectUser for unauthenticated users (since you anyway won't have a user ID anyway) or proceed however you see fit !

If you're worried about not being forwards compatible with the hook, I can pretty safely say that we won't be changing the hook anytime soon - so you should be safe there.

So in essence, everything you have here just feel free to include in your own hook; that'll be perfectly fine

isekovanic avatar Dec 18 '25 09:12 isekovanic