Enhanced offline-support for Talk web + desktop clients

[Antreesy]

Tip

How to use GitHub

• Please use the 👍 reaction to show that you are affected by the same issue.
• Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue.
• Subscribe to receive notifications on status change and new comments.

---

Offline support

Prerequisites

1. Vuex to Pinia Migration: All left Vuex stores (conversationsStore.js, messagesStore.js, participantsStore.js) must be fully migrated to Pinia.
2. Optimized Message List Rendering: message display mechanism must be refactored to handle large message volumes efficiently. Instead of "easing" the entire list, implement a strategy to render only the currently visible messages plus a small buffer (context) above and below (virtual list / windowing)

Proposed Plan for Offline Support

1. Database Layer (IndexedDB)

   • Pick a library (promise-based wrapper around IndexedDB):
     • Dexie.js
     • db.js
     • RxDB
     • other suggestions?
   • Define Schema Design (what goes in):
     • settings + local/remote capabilites
     • conversations: metadata and last messages (migrate from current BrowserStorage approach)
     • participants
     • threads
     • scheduled messages / drafts
     • messages
     • chat / thread blocks: coupled with messages
     • polls and reactions

2. Persistence & Hydration

   • APP >> DB: utilize Pinia's $subscribe in all relevant stores to trigger persistence of state changes
   • DB >> APP: during app initialization load data from IndexedDB into the Pinia stores
     • step 2: lazy load some data on demand
     • step 3: persist less data in stores, and more in db

3. Connection Management & Operation Queue

   • Monitor connection status globally (use @vueuse/core useOnline or custom solution)
   • Better handle offline state (instead of bombing with requests)
   • Queue requests while offline, when the online event is detected, process the queue
   • Handle conflict resolutions

4. UI/UX Enhancements

   • Connectivity Indicators: status bar or badge indicating "Working Offline" or "Synchronizing..."
   • Optimistic UI Extensions: Update the message list to visually distinguish states
   • Toast Notifications: Provide feedback when the app successfully reconnects and finishes syncing pending changes

5. Implementation Phases

   1. Setup & Schema: Integrate DB wrapper and define the database structure, including tables for all identified data.
   2. Core Data Persistence & Eager Hydration: Implement store-to-DB synchronization and eager loading for conversations and settings
   3. Lazy Loading for Messages: Implement on-demand loading for messages, ensuring efficient display and pagination
   4. On-Demand Loading for Auxiliary Features: Implement loading for participants, chat blocks, threads, scheduled messages, polls, and reactions when their respective UI components are activated.
   5. Mutation Queuing: Implement the operationQueue for sending messages and other mutations while offline.
   6. Sync & Conflicts: Implement reconnection logic and basic conflict resolution for the operationQueue.
   7. UI/UX & Testing: Add visual indicators and perform rigorous offline testing.

[Antreesy]

From hackweek discussion:

• We should not keep 1:1 sync of all data with the reactive store (e.g. for messages)
• Reach feature parity with mobile clients for kept data and offline mode:
  • Define list of features that are allowed to make online and queue
  • Loading indicators/ connection errors

Step 1

• Schema and layers designing
  • DB connector, update/sync mechanism, CRUD operations
• Start with conversations list prototype
  • Ref issue: follow-up(LeftSidebar) - caching, broadcast optimizations #10283
  • Broadcast - sync data between multiple tabs via DB layer, not postMessage
  • Cache - migrate away from BrowserStorage caching, check performance implications for 1:1 sync (rel. small amount of data) / interval sync