Skip to main content
Once the widget is mounted, the controller is your handle on it: subscribe to what the conversation is doing, drive the panel from your own UI, and react to actions the assistant fires.

Getting the controller

<RinggWidget config /> builds the controller for you. onReady hands it back:
It fires once, after the widget’s first render, and the widget destroys the controller when it unmounts. Everything on this page works off that value.
If you built the controller yourself and passed it as controller instead of config, you already have it, and its lifecycle is yours: call destroy() when you are done.

Lifecycle events

The widget emits five lifecycle events. The names and payloads are identical on every platform; only the delivery mechanism differs (browser CustomEvent on the web, an in-memory bus on React Native and Flutter).
ringg:calendar_booking and ringg:component_acknowledgement only fire when the assistant sends interactive components. An assistant configured for plain voice or text never emits them.
React Native has no DOM, so events arrive on the controller’s in-memory bus. on returns an unsubscribe function.
Subscribe in an effect and return the unsubscribe function. Handlers registered during render accumulate on every re-render and fire multiple times per event.

Controller methods

Call these to drive the widget from your own buttons, deep links or navigation events.
The controller also exposes methods for component responses, Block Kit actions and dynamic-data extensions. The bundled widget calls those on itself while rendering interactive components, so a normal integration does not need them.

Reading state

Each store has a hook that re-renders your component when its snapshot changes. Use these to build your own UI, or to mirror the widget’s state elsewhere in your app.
Each message carries name, message, isSelf, timestamp, an optional sourceUrl for retrieved sources, and componentType with componentData when the message renders a component instead of text.

Interactive components

Assistants can send interactive components into the chat thread instead of plain text. All six types render natively, with no work on your side beyond mounting the widget. Configure which components an assistant can send from the dashboard. See Chat Components for authoring them.

Agent-triggered app actions

Assistants can fire host actions during a conversation, for example to open a screen or focus a field. On the web these become browser events. React Native has no ambient event bus, so you supply the handler through ports and receive the same payload.
Set eventLogs: { enabled: true } in config to also show each fired action as an inline pill in the chat thread, which makes these easy to watch while building.

Ports reference

ports overrides what the widget wires on its own. Every entry is optional: supply one and yours is used, leave it out and the default applies.
ports is read once, when the widget builds the controller. Changing it later has no effect; changing config rebuilds the conversation from scratch.

Owning the lifecycle yourself

When the widget cannot own the transport, build the controller and pass that instead. defaultUrlResolver keeps the Ringg endpoints without you naming them:

QA checklist

Open and close the panel once, then confirm one ringg:widget_status event per action.
Start and end one conversation, then confirm ringg:conversation_status carries a callId.
Navigate away and back, then confirm listeners are not duplicated.
Submit and skip feedback in separate runs if the feedback screen is enabled.
Unmount the screen during a call and confirm the microphone indicator clears.