Skip to content

Chat Frontend — Current State Change Log

Status

Paused for now.

Reason: The current custom chat frontend reached a workable prototype stage, but not a level that is likely to compete with WhatsApp-like UX strongly enough to justify immediate continued investment.

Decision: Put the feature on hold and keep the current implementation as a documented checkpoint for later continuation.

What is already in place

Shared system layer

A shared @system/chat/ structure is in place with:

  • API hook factories
  • websocket client/factory
  • normalized message mapping
  • shared thread state orchestration
  • attachment upload support
  • typing support
  • conversation list sync helpers

This means the architectural base is already laid down for:

  • mobile
  • web
  • future reuse

Current frontend architecture

Shared API factories

Implemented:

  • conversation hooks
  • message hooks
  • attachment hooks
  • participant hooks
  • read-state hooks

Also added:

  • websocket client factory
  • createUseChatThread(...)
  • useChatTyping(...)
  • message normalization helpers

Shared thread state

Implemented:

  • REST history loading
  • websocket live message receive
  • optimistic local message insertion
  • reconciliation of websocket echo
  • attachment upload flow
  • typing state tracking
  • conversation list sync support

Mobile screens

Implemented prototype screens:

  • conversation list screen
  • chat thread screen

These are usable as prototype-level screens, not production-polished screens.

What currently works

Conversations

Working:

  • list conversations
  • open thread
  • show basic metadata
  • sync with backend conversation serializers

Messages

Working:

  • load message history
  • paginate older messages
  • receive live websocket messages
  • send text messages
  • optimistic text-message insertion
  • reconcile sent messages after websocket echo
  • day dividers in thread
  • bottom auto-scroll behavior improved significantly

Attachments

Working:

  • pick images/videos/documents from mobile
  • upload attachments
  • preserve filename/extensions in upload
  • send attachment messages
  • show attachment previews in bubbles
  • open attachments in MediaViewerModal

Typing

Working:

  • send typing websocket events
  • receive typing websocket events
  • render typing bubble in thread

Delete

Partially implemented / in progress:

  • long-press delete flow wired through frontend
  • delete endpoint integration added
  • frontend rendering prepared for “Message deleted”

But final delete UX depends on backend/service behavior and final local state handling.

Main problems / reasons for pause

UX gap versus established chat apps

Even though the module works technically, the user experience still falls short in important ways compared to mature chat apps such as WhatsApp.

Key gaps observed during implementation:

  • high polish expectations for chat UX
  • attachment flow complexity
  • message reconciliation complexity
  • delete/edit/read-state edge cases
  • subtle scrolling behavior requirements
  • typing/seen states needing refinement
  • live multi-client consistency still needing more work

Cost-benefit concern

Conclusion reached during development:

  • the module is functional as a custom internal chat prototype
  • but unlikely to become a heavily used feature soon
  • therefore continued investment is not currently justified

Current unresolved or unfinished items

Delete behavior

Needs final alignment across backend and frontend:

  • message should remain visible as deleted
  • attachments should be removed on backend delete
  • frontend should show:
  • Message deleted
  • no attachment previews
  • stable row position

At the moment this was being actively refactored.

Local delete reconciliation

State helpers were being updated so deleted messages would not disappear entirely from the thread.

This was not fully finalized when work paused.

Read-state / seen-state

Not finished.

Desired future work:

  • show seen state on newest outgoing message
  • compute from participants last_read_at
  • render WhatsApp-style lightweight read indicator

Message editing UX

Backend support exists, but frontend edit UX is not fully implemented.

Web frontend parity

The shared system layer was designed to support both mobile and web, but the frontend work mainly progressed on mobile first.

Web UI is not yet completed.

Final attachment UX polish

Attachment previews work, but further polish remains desirable:

  • better upload progress feedback
  • retry affordance for failed attachment uploads
  • stronger non-image file UX
  • more polished loading/fade states

Realtime deletion / edit broadcast

Websocket live handling currently focuses mainly on:

  • new messages
  • typing

Future improvement would be:

  • delete event broadcast
  • edit event broadcast

so all participants see updates live without relying on refetch.

Important implementation notes for future restart

Shared frontend entry points

Main areas touched:

  • @system/chat/api/...
  • @system/chat/model/...
  • mobile chat screens/components
  • thread components
  • websocket factory/client
  • attachment pick/upload helpers
  • media viewer integration

Key working concepts already established

These should be kept when resuming:

  • factory-based hooks pattern
  • centralized websocket client
  • normalized message model
  • optimistic message state layer
  • separation between:
  • list rendering
  • bubble rendering
  • typing bubble
  • day divider
  • message-list utilities

Attachment sending lesson

A major lesson learned:

  • React Native / Expo uploads should use { uri, name, type }
  • not raw Blob
  • otherwise filenames/extensions are lost

This is already solved in the current code.

Websocket base URL lesson

Another important lesson:

  • websocket must use the API host, not the frontend host

For this setup:

  • REST base: https://api.lacasacomes.nl/api/v1
  • websocket base: wss://api.lacasacomes.nl

This was a major issue earlier and is now understood.

If this module is resumed in the future, the best restart order would be:

  1. finalize backend delete semantics
  2. finalize frontend deleted-message rendering
  3. stabilize read-state / seen-state
  4. finish message edit UX
  5. test multi-device / multi-participant realtime consistency
  6. build web chat screens on top of the shared system layer
  7. only then decide whether the module is worth production rollout

Bottom line

The chat frontend is no longer at zero.

It now has:

  • a real architectural base
  • working realtime transport
  • message history
  • optimistic send flow
  • attachment sending and preview
  • typing state
  • prototype mobile screens

But it is paused before final product-quality polish.

This module can be resumed later from a meaningful intermediate state rather than restarted from scratch.