# `PhoenixKitComments.Web.CommentsComponent`
[🔗](https://github.com/BeamLabEU/phoenix_kit_comments/blob/v0.4.7/lib/phoenix_kit_comments/web/comments_component.ex#L1)

Reusable LiveComponent for displaying and managing comments on any resource.

## Usage

    <.live_component
      module={PhoenixKitComments.Web.CommentsComponent}
      id={"comments-#{@post.uuid}"}
      resource_type="post"
      resource_uuid={@post.uuid}
      current_user={@current_user}
    />

## Required Attrs

- `resource_type` - String identifying the resource type (e.g., "post")
- `resource_uuid` - UUID of the resource
- `current_user` - Current authenticated user struct
- `id` - Unique component ID

## Optional Attrs

- `enabled` - Whether comments are enabled (default: true)
- `show_likes` - Show like/dislike buttons (default: true)
- `title` - Section title (default: "Comments")
- `rich_text` - Use the rich-text (Leaf) editor in the composer
  (default: the `comments_rich_text` setting, which defaults to `true`).
  Pass `false` to force the plain `<textarea>` — useful when the host
  hasn't registered Leaf's JS hook, since the Leaf editor otherwise hangs
  on its loading text with no server-side error. See the README's
  "JavaScript wiring" section.

## Slots

- `:form_extras` - Custom markup rendered inside the new-comment form. Use it to
  inject parent-project inputs whose names are `metadata[<key>]`; their values are
  merged into `comment.metadata` on submit. The `"giphy"` key is reserved for the
  built-in Giphy picker, and any key listed in `decoration_keys` is dropped —
  a client may not claim the link between a comment and one of your records.
  Make that link server-side, in your own `create_comment/4` call.

      <:form_extras>
        <input type="color" name="metadata[box_color]" value="#ff5555" />
      </:form_extras>

## Parent Notifications

After create/edit/delete, sends to the parent LiveView:

    {:comments_updated, %{resource_type: "post", resource_uuid: uuid, action: :created | :updated | :deleted}}

The same message (plus `action: :reaction`) arrives over PubSub for
changes made elsewhere — `PhoenixKitComments.subscribe/2` — so one
`handle_info` clause covers both. A host rendering a preview or count of
the resource's comments should reload on ANY action rather than matching
a subset.

# `forward_leaf_event`

Forward a Leaf content-changed message from a host LiveView's
`handle_info` into the comments component. Routes only events
whose `editor_id` starts with `"pk-comments:"`; returns `:pass`
for unrelated editors so the caller can fall through to its own
handler.

## Example

    def handle_info({:leaf_changed, _} = msg, socket) do
      PhoenixKitComments.Web.CommentsComponent.forward_leaf_event(msg, socket)
    end

Returns `{:noreply, socket}` on a match (already wrapped, ready
to return from handle_info), or `:pass` when the editor isn't
ours.

# `render`

---

*Consult [api-reference.md](api-reference.md) for complete listing*
