Clarification on getMessagesPage behavior change in latest tinode-js SDK version

[Jeetjyoti Deka]

Hello everyone,

I’m looking for some clarification regarding a change in the getMessagesPage function signature and behavior in the latest SDK version.

In version 0.23.0, the function signature was:

getMessagesPage(limit, forward)

In our implementation, this worked as follows:

• getMessagesPage(24, true) fetched the latest 24 messages and displayed them to the user.

• When the user scrolled up, we called getMessagesPage(24, false) to fetch the next (older) 24 messages.

This provided a straightforward and predictable pagination experience.

In the latest version (0.25.1), the function signature has changed to:

getMessagesPage(limit, gaps, min, max, newer)

With this new signature, the only way I’ve been able to fetch messages is by calling:

getMessagesPage(24, undefined, 1, undefined, true)

However, this ends up fetching all messages starting from sequence number 1, rather than just the most recent 24 messages. I haven’t been able to replicate the earlier behavior of:

• loading only the latest N messages initially, and

• progressively loading older messages as the user scrolls.

My question is: Is there a recommended way to achieve the same pagination behavior as in v0.23.0 using the new getMessagesPage API?
If so, could you please share the intended usage pattern or an example?

Thanks in advance for your help, and appreciate the work that’s gone into evolving the SDK.

[Gene]

It seems like you removed indexDB caching?

So, to get up to 24 newer messages you should do something like 

topic.getMessagesPage(24, undefined, topic.maxMsgSeq() + 1, true);

[Jeetjyoti Deka]

Thanks for the response.

Regarding IndexedDB — that is not implemented on our side at the moment, so there’s no local cache available when the topic is first opened.

I did try the suggested approach:

topic.getMessagesPage(24, undefined, topic.maxMsgSeq() + 1, true)

However, the issue I’m seeing is that topic.maxMsgSeq() returns 0 before the first getMessagesPage call. The same is true for messageCount() and latestMessage() — they only get populated after at least one successful getMessagesPage execution.

This creates a circular dependency for the initial load:

• maxMsgSeq() is required to fetch the latest messages

• but maxMsgSeq() itself is only set after messages are fetched

Could you clarify the recommended pattern for the initial message load with the new API when there’s no IndexedDB cache available? Or the only solution is to use indexDB ?
Is there a supported way to fetch only the latest N messages without already knowing maxMsgSeq()?

--
You received this message because you are subscribed to a topic in the Google Groups "Tinode General" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/tinode/47s9S-dfCR4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to tinode+un...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/tinode/eaabdff2-d3dc-4ed4-a71c-23ebbaa42aban%40googlegroups.com.

[Gene S]

On Fri, Jan 2, 2026 at 8:06 PM Jeetjyoti Deka <jeetjy...@gmail.com> wrote:

Thanks for the response.

Regarding IndexedDB — that is not implemented on our side at the moment, so there’s no local cache available when the topic is first opened.

I did try the suggested approach:

topic.getMessagesPage(24, undefined, topic.maxMsgSeq() + 1, true)

However, the issue I’m seeing is that topic.maxMsgSeq() returns 0 before the first getMessagesPage call. The same is true for messageCount() and latestMessage() — they only get populated after at least one successful getMessagesPage execution.

If you have no messages cached at all and just want to fetch the page of most recent messages, then do 

 topic.getMessagesPage(24, undefined, undefined, false);

 

You received this message because you are subscribed to the Google Groups "Tinode General" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tinode+un...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/tinode/CAM2U063Ua79Qbsu1vmn%2BChSjORCkzSyDWe2kpEcK0pnvZ1hLMw%40mail.gmail.com.

[Gene]

Actually, even simpler:

topic.getMessagesPage(24);

[Jeetjyoti Deka]

I tried calling the method in the simplified form as suggested:

topic.getMessagesPage(24)

and also tested these variants:

topic.getMessagesPage(24, undefined, undefined, undefined, true)
topic.getMessagesPage(24, undefined, undefined, undefined, false)

In all of these cases, the SDK does not trigger a data fetch. No data message is sent over the socket — only hi, login, ctrl, sub, and meta messages are exchanged. I’ve attached a screenshot of the socket traffic showing this behavior.

I also wired up the following callback:

topic.onAllMessagesReceived = () => {
  console.log("all messages received");
  console.log("message count:", topic.messageCount());

  const msgs = [];
  topic.messages((m) => {
    msgs.push(m);
  });

  console.log("cached messages:", msgs);
};

This callback is never triggered when calling the function as mentioned above which further suggests that the data request itself is not being initiated.

The topic state (maxMsgSeq(), messageCount(), latestMessage()) also remains unchanged after these calls.

At the moment, the only calls that reliably result in a data request are those where either min or max is explicitly provided. Without those parameters, getMessagesPage appears to be a no-op in our setup.

To view this discussion visit https://groups.google.com/d/msgid/tinode/bdfe13e5-0f7e-4391-9672-e83c68fa804dn%40googlegroups.com.

[Gene]

Given that you are working with a forked SDK, I can't really debug your code through the forum. The official app works fine. Yours does not. So, there must be something different between the official app and yours. Find out what is different.

[Jeetjyoti Deka]

Thanks for the response, really appreciate it.

To view this discussion visit https://groups.google.com/d/msgid/tinode/c597d9f0-75c9-4544-9d48-3d5d1ccf1fa1n%40googlegroups.com.