SyncManager JS v1
SyncManager JS
SyncManager
JS
Home
/
SyncManager
/
JavaScript

Local caching

Local caching is a better option than SyncManager for Javascript for rapid access to the data from the local cache and Sendbird server. If you are currently using SyncManager, we strongly encourage you to migrate to the Chat SDK with local caching for enhanced usability and easier maintenance.

Note: SyncManager will be deprecated soon.

The following table displays the full range of differences between local caching and SyncManager.

Local cachingSyncManager

Implementation

Integrated to Chat SDK

Add-on to Chat SDK

Architecture

View-driven

Event-driven

Synchronization

Changelog sync and background sync

Background sync

Auto resend

Supported

Not supported

One distinct advantage of local caching over SyncManager is that it provides an event context and a callback for identifying what changes are made to which group channels and messages. This facilitates locating and debugging issues in those channels.

SyncManager relies on an event-driven architecture where its collection handlers receive all events that pass through the WebSocket connection along with the data in the local cache. In contrast, local caching relies on a view-driven structure where only those events that directly affect the user’s channel list and chat view are delivered to their respective collections.

Another advantage of local caching is that messages that were not sent the first time are automatically resent at a later time. When the WebSocket connection is lost, messages considered “pending” are stored locally until the connection comes back on, at which point the pending messages are automatically sent. This new functionality unique to local caching is called auto resend.

Note: SyncManager will continue to work if the dependency to SyncManager is not removed. The dependency should be deleted once the migration to local caching is completed.


Initialization

You can initialize the Chat SDK with or without local caching. The localCacheEnabled is the boolean that determines if you are going to be using local caching. By default, the Chat SDK is initialized without local caching, the localCacheEnabled set to false. If the localCacheEnabled is set to true, the Chat SDK is initialized with local caching.

Note: If initialization fails to complete while the localCacheEnabled is set to true, the Chat SDK will operate as if the localCacheEnabled is set to false.

Connect to Sendbird server

Local caching and SyncManager are alike in keeping chat in the client app up-to-date even when the app is not connected to Sendbird server. The key difference between SyncManager and local caching at the initialization stage is that local caching requires calling the sendbird.connect() after the new SendBird. Calling the sendbird.connect() after the new SendBird is optional when using SyncManager because the SendBirdSyncManager.setup() is called immediately after the new SendBird during the initialization process. Calling the sendbird.connect() after the new SendBird is required when using local caching because some platforms receive the result of new SendBird as a callback.

Local cachingSyncManager
// Initialize with the localCacheEnabled set to true.
const sendbird = new SendBird({ appId: APP_ID, localCacheEnabled: true });
sendbird.setErrorFirstCallback(true);
sendbird.connect(USER_ID)
  .then(user => {
    // ...
  })
  .catch(error => {
    // Handle error.
  });

Other methods

Local caching’s sendbird.clearCachedMessages, which clears the cached messages in a specified channel, replaces the functionality of SyncManager’s clearCache(), which deletes the entire data file. Local caching's sendbird.clearCachedMessages must be called after the new SendBird().

Local cachingSyncManager
sendbird.clearCachedMessages(CHANNEL_URLS)
  .then(() => {
    // ...
  })
  .catch(error => {
    // Handle error.
  });