Skip to main content
Each component’s BLoC manages data fetching, state transitions, and business logic. You can configure it via RequestBuilders, provide a custom BLoC instance, or extend the default one.

Configuring Data Fetching with RequestBuilders

Use request builders to control what data the component fetches. Pass the builder instance — not the result of .build().
The following parameters in MessagesRequestBuilder will always be altered inside the message list: UID, GUID, types, categories.

Request Builder by Component

Providing a Custom BLoC

Each component accepts an optional BLoC parameter. Provide your own instance to override default behavior:

BLoC Parameters by Component

Extending the Default BLoC

Extend the default BLoC class and override hooks to add custom behavior:

ListBase Hooks

All list-based BLoCs use the ListBase mixin with these override hooks:

Component-Specific BLoC Events

Each component’s BLoC has its own events and methods. See the individual component docs for details:

Lifecycle Callbacks


Repository & Datasource Overrides

Both CometChatConversations and CometChatMessageList follow the same clean architecture stack. There are two override points:

1. Datasource Override

Implement the abstract datasource interfaces to swap the data layer entirely — e.g. a REST API instead of the CometChat SDK, or a persistent cache instead of in-memory.

Conversations

Message List


2. Repository Override

The repository interfaces sit above the datasources. Override here to change business logic — caching strategy, error handling, retry logic — without touching the datasource layer.

Conversations

Message List


3. Wiring via the Service Locator

The service locators are the injection point. Both are singletons with a setup() method. Call reset() first, then setup() with your custom implementations before the widget mounts.

Datasource-level override (Conversations)

Repository-level override (Message List)


Key Points