Skip to content

feat(eventing): emit lifecycle events for update, delete, reply CRUD#761

Draft
jackiejou wants to merge 3 commits into
box:masterfrom
jackiejou:feat/eventing-update-delete-reply
Draft

feat(eventing): emit lifecycle events for update, delete, reply CRUD#761
jackiejou wants to merge 3 commits into
box:masterfrom
jackiejou:feat/eventing-update-delete-reply

Conversation

@jackiejou
Copy link
Copy Markdown
Collaborator

Stacked on #760. Until #760 merges, the "Files changed" tab will include the reply edit/delete commit. After #760 merges I will rebase this branch onto master and the diff will collapse to only the eventing changes. Please review only after #760 lands.

Summary

  • box-annotations only emitted lifecycle events for the create flow. Other thunks ran their API calls and updated internal state, but withAnnotations listeners on the box-ui-elements side never fired, so the activity feed went stale until reload.
  • This adds outbound eventing for five thunks following the existing create.ts pattern:
    • updateAnnotationAction emits annotations_update (also covers resolve/unresolve via annotation.status)
    • deleteAnnotationAction emits annotations_delete
    • createReplyAction emits annotations_reply_create
    • updateReplyAction emits annotations_reply_update
    • deleteReplyAction emits annotations_reply_delete
  • Each handler emits via the singleton eventManager with { annotation, error, meta: { requestId, status } }. Reply handlers add an annotationReply field carrying the reply object.
  • Generalizes AsyncAction<TArg, TPayload> so each handler can type its action precisely.
  • Each success-phase handler short-circuits when the necessary payload is missing instead of emitting a contradictory success event.

Test plan

  • In a host app with a linked box-annotations build, edit an annotation message in the in-document popup and verify the activity feed entry text updates inline (no reload).
  • Resolve an annotation in the popup, verify the feed entry reflects resolved state. Unresolve and verify it reverses.
  • Delete the parent annotation from the popup, verify the entire feed entry disappears.
  • Add a reply via the popup, verify the reply appears under the parent in the feed.
  • Edit a reply via the popup, verify the reply text updates in the feed.
  • Delete a reply via the popup, verify the reply disappears from the feed.
  • Confirm yarn jest --testPathPattern="store/eventing" passes (61 tests across 14 suites).

jackiejou added 3 commits May 29, 2026 12:06
Threads in PopupV2 can now edit and delete replies. Reply edits dispatch
to PUT /undoc/comments/{id} and reply deletes to DELETE
/undoc/comments/{id} via the box-ui-elements ThreadedComments client.

- Adds updateReplyAction and deleteReplyAction thunks. Both reject
  upfront when the reply is not present in state so callers receive a
  typed error instead of an opaque server response.
- Adds reducer cases that replace or remove the targeted reply on
  fulfilled.
- Threads the canEdit permission through replyToTextMessage so the
  edit affordance reflects backend permissions.
- Widens the Token type with TokenMap so consumers can pass a per-typed
  file id resolver for avatar fetching.
replyToTextMessage was not setting updatedAt on the message, so the
edit indicator never appeared on edited replies even though the
backend returns modified_at on the comment object. The Reply type
also did not declare the field.
box-annotations only emitted lifecycle events for the create flow.
Other thunks ran their API calls and updated internal state, but
withAnnotations listeners on the box-ui-elements side never fired,
so the activity feed went stale until reload.

Adds outbound eventing for five thunks following the existing
create.ts pattern:

- updateAnnotationAction emits annotations_update (covers resolve
  and unresolve via annotation.status)
- deleteAnnotationAction emits annotations_delete
- createReplyAction emits annotations_reply_create
- updateReplyAction emits annotations_reply_update
- deleteReplyAction emits annotations_reply_delete

Each handler emits via the singleton eventManager with the
{ annotation, error, meta: { requestId, status } } envelope. Reply
handlers add an annotationReply field carrying the reply object.

Generalizes AsyncAction over arg/payload so each handler can type
its action precisely. Each success-phase handler short-circuits
when the necessary payload is missing instead of emitting a
contradictory success event.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant