Focused composer LiveComponent for attaching the first comment to a newly-drawn Etcher annotation in the MediaBrowser modal sidebar.
Why a separate component
PhoenixKitComments.Web.CommentsComponent is a monolithic bundle of
thread rendering + composer + edit/delete/likes. We want only the
composer slice, with explicit Post / Cancel control flow that owns the
annotation lifecycle: clicking Post commits the comment AND
"solidifies" the annotation, clicking Cancel rolls the annotation
back. Extracting that out of CommentsComponent is harder than
building a thin wrapper that calls the same context functions
underneath (PhoenixKitComments.create_comment/4,
PhoenixKitComments.search_giphy/2,
PhoenixKit.Modules.Storage.store_file/2).
Required assigns
:annotation_uuid— UUID of the annotation being annotated:file_uuid— UUID of the file the annotation lives on. The created comment is tied to the file (resource_type: "file",resource_uuid: file_uuid) so it appears in the file's comments thread alongside non-annotated discussion. The annotation linkage lives inmetadata.annotation_uuid— the tooltip preview filters on this key.:current_user— the user composing the comment (must be present):parent_id— DOM id of the parentMediaBrowserLC so we cansend_update/2lifecycle notifications back to it
Lifecycle notifications
On submit success or explicit cancel the composer calls
Phoenix.LiveView.send_update(MediaBrowser, id: parent_id, action: ...).
MediaBrowser's update/2 translates the action into either a
rollback (cancel) or a "solidify" (post). No host-LV plumbing needed
— send_update/2 works LC-to-LC inside the same LiveView process.
Scope
Text + file uploads (image / video / audio / pdf / archive) + Giphy
picker. Audio recording (which the full CommentsComponent supports
via a JS hook) is intentionally skipped for v1; falling back to the
existing thread UI on an existing annotation is the path for replies
with audio.