Local caching

Local caching enables Sendbird Chat SDK for JavaScript to locally cache and retrieve group channel and message data. Its benefits include reducing refresh time and allowing a client app to create a channel list or a chat view that can work online as well as offline, which can be used for offline messaging.

You can enable local caching when initializing the Chat SDK by setting the optional parameter localCacheEnabled to true. See Initialize the Chat SDK and Connect to the Sendbird server to learn more.

To view the image in full screen, click on the

Local caching relies on the groupChannelCollection and messageCollection classes, which are used to build a channel list view and a chat view, respectively. Collections are designed to react to the events that can cause changes in a view. An event controller in the SDK oversees such events and passes them to a relevant collection. For example, if a new group channel is created while the current user is looking at a chat view, the current view won't be affected by this event.

Note: Sendbird Chat SDK v4 supports both TypeScript and JavaScript.

The following is a list of functionalities our Chat SDK supports.

GroupChannelCollection allows you to swiftly create a channel list view that stays up to date on all channel-related events. It contains the following functions and variables.

const groupChannelFilter: GroupChannelFilter = new GroupChannelFilter();
groupChannelFilter.includeEmpty = true;

const params: GroupChannelCollectionParams = {
    filter: groupChannelFilter,
    order: GroupChannelListOrder.LATEST_LAST_MESSAGE,
};
const collection: GroupChannelCollection = sb.groupChannel.createGroupChannelCollection(params);

const handler: GroupChannelCollectionEventHandler = {
    onChannelsAdded: (context: GroupChannelEventContext, channels: GroupChannel[]) => {
        // Add new channels to your data source.
    },
    onChannelsUpdated: (context: GroupChannelEventContext, channels: GroupChannel[]) => {
        // Update the existing channels in your data source.
    },
    onChannelsDeleted: (context: GroupChannelEventContext, channelUrls: string[]) => {
        // Delete the channels with the matching channelUrls from your data source.
    },
};
collection.setGroupChannelCollectionHandler(handler);

const channels: GroupChannel[] = await collection.loadMore();

When the createGroupChannelCollection() method is called, the group channel data stored in the local cache and the Sendbird server are fetched and sorted based on the value of order and filter.

The setGroupChannelCollectionHandler() method allows you to set the event listeners that can subscribe to channel-related events.

As for pagination, hasMore checks if there are more group channels to load whenever a user hits the bottom of the channel list. If so, loadMore() retrieves those channels from the local cache and the Sendbird server.

To learn more about the collection and how to create a channel list view with it, see Create a collection.

MessageCollection allows you to swiftly create a chat view that includes all data. It is composed of the following elements.

const filter: MessageFilter = new MessageFilter();
const limit = 100;
const collection: MessageCollection = channel.createMessageCollection({
    filter,
    limit,
});

const handler: MessageCollectionEventHandler = {
    onMessagesAdded: (context: MessageEventContext, channel: GroupChannel, messages: BaseMessage[]) => {
        // Add the messages to your data source.
    },
    onMessagesUpdated: (context: MessageEventContext, channel: GroupChannel, messages: BaseMessage[]) => {
        // Update the messages in your data source.
    },
    onMessagesDeleted: (context: MessageEventContext, channel: GroupChannel, messageIds: number[]) => {
        // Remove the messages from the data source.
    },
    onChannelUpdated: (context: GroupChannelEventContext, channel: GroupChannel) => {
        // Change the chat view with the updated channel information.
    },
    onChannelDeleted: (context: GroupChannelEventContext, channelUrl: string) => {
        // This is called when a channel was deleted. So the current chat view should be cleared.
    },
    onHugeGapDetected: () => {
        // The Chat SDK detects more than 300 messages missing.
    }
};
collection.setMessageCollectionHandler(handler);

const startingPoint: number = Date.now();
collection
    .initialize(MessageCollectionInitPolicy.CACHE_AND_REPLACE_BY_API, startingPoint)
    .onCacheResult((err: Error, messages: BaseMessage[]) => {
        // Messages will be retrieved from the local cache.
        // They might be too outdated or far from the startingPoint.
    })
    .onApiResult((err: Error, messages: BaseMessage[]) => {
        // Messages will be retrieved from the Sendbird server through API.
        // According to MessageCollectionInitPolicy.CACHE_AND_REPLACE_BY_API,
        // the existing data source needs to be cleared
        // before adding retrieved messages to the local cache.
    });

if (collection.hasPrevious) {
    // Load the previous messages when the scroll
    // reaches the first message in the chat view.
    const messages: BaseMessage[] = await collection.loadPrevious()
}

if (collection.hasNext) {
    // Load the next messages when the scroll
    // reaches the last message in the chat view.
    const messages: BaseMessage[] = collection.loadNext();
}

In MessageCollection, the initialization is dictated by MessageCollectionInitPolicy. This determines which data to use for the collection. Currently, we only support CACHE_AND_REPLACE_BY_API. According to this policy, the collection will load the messages stored in the local cache through onCachedResult(). Then onApiResult() will be called to replace them with the messages fetched from the Sendbird server through an API request.

As for pagination, hasNext checks if there are more messages to load whenever a user hits the bottom of the chat view. If there are, the loadNext() method retrieves those messages from the local cache. The hasPrevious accessor works the same way when the scroll reaches the least recent message in the view.

To learn more about the collection and how to create a chat view with it, see Create a collection.

To view the image in full screen, click on the

A gap is created when messages or channels that exist on the Sendbird server are missing from the local cache. This discrepancy occurs when a client app isn't able to properly load new events due to issues with the connection status.

To prevent such a gap, the Chat SDK constantly communicates with the Sendbird server and fetches data through background sync. The synchronization process pulls the data from the most to least recent. This ensures that the local cache has all the data in order. However, because this synchronization takes place in the background, changes won't call collection event handlers or affect the view.

Despite the background sync, a gap may still be created. When the client app is in the foreground, the SDK checks with the Sendbird server to see if there has been a gap. If more than 300 messages are missing in the local cache compared to the Sendbird server, the Chat SDK classifies this as a huge gap and onHugeGapDetected is called. In case of a huge gap, it is more effective to discard the existing message collection and create a new one. On the other hand, a relatively small gap can be filled in through changelog sync.

Background sync ensures that the local cache keeps its data up-to-date compared to the Sendbird server, whereas changelog sync fetches any events that can affect the channel list view and the chat view.

Changelog sync pulls data when the client app is back online. When the client app is connected to the server, it fetches events in chronological order by the value of updated_at, from first to last. Events fetched by changelog sync are then added to the collection, updating the view.

The events are delivered to the collection through event handlers such as onMessagesUpdated, onMessagesDeleted, onChannelsUpdated, onChannelsDeleted, and onChannelsAdded.

A message is normally sent through the WebSocket connection which means the connection must be secured and confirmed before sending any message. With local caching, you can temporarily keep an unsent message in the local cache if the WebSocket connection is lost. The Chat SDK with local caching marks the failed message as pending, stores it locally, and automatically resends the pending message when the WebSocket is reconnected. This is called auto resend.

The following cases are eligible for auto resend.

• A user message couldn't be sent because the WebSocket connection was lost even before it was established.

• A file message couldn't upload the attached file to the Sendbird server.

• An attached file was uploaded to the Sendbird server but the file message itself couldn't be sent because the WebSocket connection was closed.

To view the image in full screen, click on the

A user message is sent through the WebSocket. If a message couldn't be sent because the WebSocket connection was lost, the Chat SDK receives an error through a callback and queues the pending message in the local cache for auto resend. When the client app is reconnected, the SDK then attempts to resend the message.

If the message is successfully sent, the client app receives a response from the Sendbird server. Then onMessagesUpdated is called to change the pending message to a sent message in the data source and updates the chat view.

A file message can be sent through either the WebSocket connection or an API request.

When sending a file message, the attached file must be uploaded to the Sendbird server as an HTTP request. To do so, the Chat SDK checks the status of the network connection. If the network isn't connected, the file can't be uploaded to the server. In this case, the SDK handles the file message as a pending message and adds to the queue for auto resend.

If the network is connected and the file is successfully uploaded to the server, its URL is delivered in a response and the SDK replaces the file with its URL. At first, the SDK attempts to send the message through the WebSocket. If the WebSocket connection is lost, the client app checks the network connection once again to make another HTTP request for the message. If the SDK detects the network as disconnected, it gets an error code that marks the message as a pending message, allowing the message to be automatically resent when the network is reconnected.

On the other hand, if the network is connected but the HTTP request fails, the message isn't eligible for auto resend.

If the message is successfully sent, the client app receives a response from the Sendbird server. Then onMessagesUpdated is called to change the pending message to a sent message in the data source and updates the chat view.

If a message couldn't be sent due to some other error, onMessagesUpdated is called to re-label the pending message as a failed message. Messages labeled as such can't be queued for auto resend. The following shows some of these errors.

SendBirdError.ERR_NETWORK
SendBirdError.ERR_ACK_TIMEOUT

Note: A pending message can last in the queue only for three days. If the WebSocket connection is back online after three days, the onMessagesUpdated method is called to mark any three-day-old pending messages as failed messages.