Fix Private Message Issue in Next.js
Budget / Salary$30–250
TypeFreelance project
LocationRemote
Posted1 hour ago
Bug fix in a Next.js/TypeScript/Prisma real-time chat application.
Context: chat messages are stored as generic ChatEvent rows in Postgres, with
no dedicated flag distinguishing a private message from a public one — private
messages currently arrive with a text-based marker prefixed to the message
body (e.g. a bracketed tag at the start of the string).
The frontend chat component already has a fully built, distinct rendering
path for private messages (different visual treatment) — it just never gets
used, because the API route that serves chat events to the frontend maps
every single row to the generic "chat" type regardless of content, so the
private-message type the frontend already knows how to render is never
actually emitted.
Task: update the API route so it correctly detects the private-message
marker in the stored message body and emits the distinct type the frontend
already expects, instead of always emitting the generic type. This should
require no frontend changes — the rendering path is already built and just
needs real data reaching it.
I'll share the specific route file, the relevant type definitions, and a
schema excerpt once we're talking — a few isolated files, not the full repo.
Small, contained, fixed-price. Clean git history and a short before/after
description of your fix expected on delivery.
Context: chat messages are stored as generic ChatEvent rows in Postgres, with
no dedicated flag distinguishing a private message from a public one — private
messages currently arrive with a text-based marker prefixed to the message
body (e.g. a bracketed tag at the start of the string).
The frontend chat component already has a fully built, distinct rendering
path for private messages (different visual treatment) — it just never gets
used, because the API route that serves chat events to the frontend maps
every single row to the generic "chat" type regardless of content, so the
private-message type the frontend already knows how to render is never
actually emitted.
Task: update the API route so it correctly detects the private-message
marker in the stored message body and emits the distinct type the frontend
already expects, instead of always emitting the generic type. This should
require no frontend changes — the rendering path is already built and just
needs real data reaching it.
I'll share the specific route file, the relevant type definitions, and a
schema excerpt once we're talking — a few isolated files, not the full repo.
Small, contained, fixed-price. Clean git history and a short before/after
description of your fix expected on delivery.
Apply on Freelancer →
Project sourced from Freelancer.com. Applications happen directly on the original platform — we never collect your data.