constellation · actor grid

<atproto-likers>

Avatar grid of accounts that liked a post. Each DID resolves to a profile via their own PDS.

Live

<atproto-likers src="at://..." limit="16"></atproto-likers>

Attributes

Name	Type	Default	Description
`src` *	`string`	—	Post AT-URI or bsky.app URL.
`limit`	`number`	`16`	Avatars per page.
`constellation`	`string`	—	Override the Constellation endpoint.

Parts

External CSS can target these via atproto-likers::part(<name>) { ... }.

Part	What it is
`head`	'N likes' counter.
`grid`	Avatar grid container.
`actor / actor-avatar`	Each avatar tile (link to bsky profile).
`loadmore / empty`	Pagination button and empty-state.

What it does

Given a post, asks Constellation: "who has a app.bsky.feed.like record pointing at this?" The response is a page of DIDs. For each, the component fetches the liker's profile from their own PDS to get the avatar + handle, and renders a linked avatar tile.

Common pattern: "X, Y, and 23 others liked this"

The actor grid is the full-fledged UI. For a denser presence (say, three avatars + count in a byline), compose atomics instead:

<div class="likers-byline">
  <atproto-like-count src="at://..."></atproto-like-count> likes
</div>

Or grab the same DIDs the grid uses and render your own treatment. See the source — the fetchPage method returns the DID list.

Fan-out

Per page: 1 Constellation backlinks call + up to limit parallel profile+DID-doc lookups. At default limit=16, that's ~33 network requests. The cache layer dedupes DIDs across pages, so scrolling through 500 likers doesn't re-fetch profiles you've seen.