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:Approach 1: CometChatProvider (Recommended)
CometChatProvider is a single component that handles SDK initialization, user login, plugin registration, theming, localization, and real-time events — all declaratively via props.
CometChatUIKit.init(), no UIKitSettingsBuilder, no manual login. The provider handles the full lifecycle:
- Builds
UIKitSettingsfrom your props - Calls
CometChatUIKit.init(settings)internally - Logs in the user (via
uid+authKey, orauthToken) - Sets up the plugin registry (default plugins included automatically)
- 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 aUIKitSettings 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 theplugins prop:
Accessing the Logged-In User
Inside your components (children ofCometChatProvider), 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
CallCometChatUIKit.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:
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)
- No manual
init()orlogin()calls needed - No
UIKitSettingsBuilderrequired 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)