Description
In PostCard (components/post-card.tsx), the isBurned state is a local useState(false) variable. When a user burns a post, the counter increments in memory via the context burnPost action, but no request is sent to POST /api/posts/[id]/burn. On page reload, the burn count reverts, and the user can burn the same post again.
The same pattern applies to likes — there is no mechanism to track whether the current user has already liked or burned a post, so the UI cannot reflect the current state on load.
More info
- Working API:
POST /api/posts/[id]/burn, DELETE /api/posts/[id]/burn, POST /api/posts/[id]/like, DELETE /api/posts/[id]/like.
GET /api/posts/[id]/stats returns { likes, burns, entries } counts.
- The fix involves:
- Calling the appropriate API when a user clicks like/burn.
- Using the returned count from the API response to update UI.
- Fetching the user's own interactions on mount (or embedding them in the post response) so buttons show the correct active state.
- The
burnPost context action can remain for optimistic UI but must be backed by an API call.
Description
In
PostCard(components/post-card.tsx), theisBurnedstate is a localuseState(false)variable. When a user burns a post, the counter increments in memory via the contextburnPostaction, but no request is sent toPOST /api/posts/[id]/burn. On page reload, the burn count reverts, and the user can burn the same post again.The same pattern applies to likes — there is no mechanism to track whether the current user has already liked or burned a post, so the UI cannot reflect the current state on load.
More info
POST /api/posts/[id]/burn,DELETE /api/posts/[id]/burn,POST /api/posts/[id]/like,DELETE /api/posts/[id]/like.GET /api/posts/[id]/statsreturns{ likes, burns, entries }counts.burnPostcontext action can remain for optimistic UI but must be backed by an API call.