Chat message with infinite scroll pagination and real time refresh

I have implemented a messaging system in which I perform a backend query with “single time query” disabled (see image). This allows all users participating in the chat to have messages updated in real time. It works, but the backend query does not allow me to take advantage of the power of pagination, so I retrieve the entire message history at once, even though users will probably not scroll through it all 😟

So I opted for a query via API Call because this is the only method that allows me to use pagination (used on a list view of course). Once again, it works, the oldest messages are loaded in chunks, everything is fine, youpie tralala ! But API Call requests don't benefit from the disabled “single time query”, you have to refresh manually using a subscription on the relevant table and activate real time on it. The problem is not the subscription but the refresh itself... it will re-render the list view and therefore display a loading spinner between each message. So typically, if I'm in a group and I'm writing a message, I'll have loading spinners everywhere if they send their messages before me, and it's important to note that even if the “Backend Query Loading Widget” is set to “unset,” the loading spinner is displayed by default 😢

What I need is a messaging page with pagination where the data is retrieved as if I had a “single time query” disabled, so without loading or freezing.

I don't want to do any hacking by that I mean using non-standard or improper techniques, like redirecting the user to another page and then bringing them back just to force a refresh.

Api Call + Pagination but manual "refresh database request" on the list view

Backend query with "single time query" disabled but no pagination

The problem is specific to Flutterflow because it is responsible for refreshing the UI, so :

👉 I imagined an integration where we would have a backend query with “single time query” disabled and a limit of 50 messages. On the list view, I would add a “Pull to Refresh” action that would make the same request but with an increased limit (100, 150, 200 etc). Unfortunately, the “limit” in the backend query cannot be made dynamic, so the idea didn’t work out.
👉 I looked into whether it was possible to disable the loading spinner, but it turns out it isn’t. So I rebuilt my list view (since the loading state is only set to “unset” when it’s first created). However, as i mentioned above, the loading spinner still appears by default.
👉 I wanted to add a second list view. The first would make an API call with pagination and have an opacity of 1. The second would make a backend query with a limit (say 20) and have an opacity of 0. When a user posts a message, the subscription is triggered to swap the opacities of the two list views > refresh the pagination list view (during this time, users see their updated messages since they are on the second list view with single time query disabled) > and then, when the paginated list view is OK, we reverse the opacities. I didn't pursue this idea because i thought it sounded like a hack, which I didn't want to do in the first place.

Another solution would be to not use pagination and have ephemeral messages...