Skip to main content

Overview

Every CometChat component must be rendered inside a provider tree that supplies theme, locale, plugin registry, and real-time events. The UI Kit offers two ways to set this up:
CometChatProvider is a single component that handles SDK initialization, user login, plugin registration, theming, localization, and real-time events — all declaratively via props.
That’s it. No CometChatUIKit.init(), no UIKitSettingsBuilder, no manual login. The provider handles the full lifecycle:
  1. Builds UIKitSettings from your props
  2. Calls CometChatUIKit.init(settings) internally
  3. Logs in the user (via uid + authKey, or authToken)
  4. Sets up the plugin registry (default plugins included automatically)
  5. Provides theme, locale, and event contexts to all child components

Props

*Required unless settings is provided.

Authentication

Provide one of:
  • authToken — for production (generated server-side via REST API)
  • uid + authKey — for development/testing only

Advanced: Pre-built Settings

For full control over SDK configuration (presence subscription mode, custom hosts, storage mode), pass a UIKitSettings object:

With Calling Enabled

With Custom Theme and Locale

With Additional Plugins

Default plugins (text, image, file, audio, video) are always included. Pass additional plugins via the plugins prop:

Accessing the Logged-In User

Inside your components (children of CometChatProvider), access the logged-in user via the useLoggedInUser() hook or CometChatUIKit.getLoggedInUser():

Approach 2: Individual Providers (Advanced)

For apps that need custom login flows, multiple CometChat instances, or fine-grained control over the provider tree, you can initialize manually and compose providers yourself.

Step 1: Initialize and Login

Call CometChatUIKit.init() and CometChatUIKit.login() before rendering:
src/main.tsx

Step 2: Compose Providers

After init and login, wrap your app with the individual providers:
src/App.tsx

When to Use This Approach

  • Custom login flows — your app has its own auth system and you need to control when login happens
  • Multiple chat instances — you need separate plugin registries or themes for different parts of the app
  • Gradual migration — you’re migrating from v6 and want to keep the imperative init pattern temporarily
  • Server-side rendering — you need to defer initialization to a specific lifecycle point
Even with individual providers, CometChatUIKit.init() must be called before rendering any CometChat components. The individual providers do not handle initialization — they only provide React context.

Internal Architecture

CometChatProvider composes these internal providers in order:
The EventsProvider only mounts after login succeeds. Before that, children render without real-time event subscriptions (which is correct since there’s no authenticated session to listen on).

Next.js App Router

CometChatProvider uses browser APIs internally, so it must be placed inside a Client Component:
app/providers.tsx

Migration from v6

In v6, initialization was always imperative:
v6 (before)
v7 (after)
Key differences:
  • No manual init() or login() calls needed
  • No UIKitSettingsBuilder required for basic usage
  • Default plugins are included automatically
  • Theme and locale are props, not separate configuration steps
  • Real-time events are managed internally (no RxJS, no manual listener setup)