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