Skip to main content
Understand the CometChat UI Kit component model so you can choose the right building blocks for your chat experience.

When to use this

  • You need to decide between Base Components and Components.
  • You want to understand how actions and events affect component behavior.
  • You want to know how configurations apply within composite UI flows.
  • You are planning a UI Kit implementation and need the conceptual model first.

Prerequisites

  • No additional setup is required for this conceptual overview.

Quick start

  1. Read the definitions of Base Components and Components.
  2. Decide which component type fits your screen requirements.
  3. Review Actions to understand built-in vs custom behavior.
  4. Review Events to understand how components communicate.
  5. Review Configurations to understand per-component customization in composite UIs.

Core concepts

  • Base Components: Visual building blocks that render UI without business logic.
  • Components: UI elements that include business logic such as data loading and user actions.
  • Actions: Behavior hooks that drive how a component responds to events.
  • Events: Emitted signals that allow other parts of the app to react.
  • Configurations: Per-component settings within composite screens.

Implementation

Choose between Base Components and Components

What you’re changing: The type of UI Kit building block you use for a screen.
  • Where to change it: Your screen design and component selection (no file change on this page).
  • Applies to: Any UI Kit screen or flow you build.
  • Default behavior: Base Components render UI only; Components include business logic and data handling.
  • Override: Select the component type that matches your functional needs.
  • Code: Not applicable for this overview.
  • Verify: You can describe why a screen uses Base Components or Components.

Decide on action handling

What you’re changing: How a component responds to user interaction.
  • Where to change it: Component action configuration in your implementation (not specified on this page).
  • Applies to: Components and composite screens that expose actions.
  • Default behavior: Predefined actions execute automatically in the component.
  • Override: Implement user-defined actions when you need custom behavior.
  • Code: Not applicable for this overview.
  • Verify: You can identify which actions are predefined vs user-defined for your screen.

Use events for decoupled behavior

What you’re changing: How UI Kit components communicate with the rest of your app.
  • Where to change it: Event handling in your implementation (not specified on this page).
  • Applies to: Components and composite components that emit events.
  • Default behavior: Events are emitted when user interaction or state changes occur.
  • Override: If your app needs to respond to a component event, subscribe to that event and handle it in your listener.
  • Code: Not applicable for this overview.
  • Verify: You can map an event to the UI change it should trigger.

Plan component configurations in composite screens

What you’re changing: Per-component configuration inside composite screens.
  • Where to change it: Component configuration in your composite screen setup (not specified on this page).
  • Applies to: Composite screens that embed multiple UI Kit components.
  • Default behavior: Each embedded component has its own configurable properties.
  • Override: Adjust configurations to tailor each component’s behavior and appearance.
  • Code: Not applicable for this overview.
  • Verify: You can list the components in a composite screen and the config each one needs.

Customization matrix

What you want to changeWhereProperty/APIExample
Component type selectionScreen design and architectureNot specified on this pageNot applicable for this overview
Predefined vs user-defined actionsComponent action handlingNot specified on this pageNot applicable for this overview
Event handling strategyEvent listeners in your implementationNot specified on this pageNot applicable for this overview
Per-component configuration in compositesComposite screen setupNot specified on this pageNot applicable for this overview

Common pitfalls & fixes

  • Confusing Base Components with Components: Base Components render UI only; Components include business logic.
  • Expecting Base Components to emit actions: Only Components and composite components expose actions.
  • Ignoring events: Events are how components notify the rest of your app about state changes.
  • Overlooking per-component configs in composites: Each embedded component has its own configuration.
  • Treating configurations as global: Configurations are scoped to the component they belong to.

FAQ

Q: Are Base Components enough for a full chat experience?
A: No. Base Components are visual building blocks; Components add business logic and data handling.
Q: Do all components expose actions?
A: Components and composite components do. Base Components do not.
Q: How do components communicate with the rest of my app?
A: They emit events that other parts of the app can listen to and respond to.

Next steps