decentraland / sites / 34630295497

94%

push

github

feat: migrate community reads to the social-service v2 endpoints (#751)

* feat: migrate community reads to the social-service v2 endpoints

The v2 community read endpoints return addresses only, skipping the
Catalyst profile enrichment v1 does server-side. Point the single
community, members, member-requests, communities-list and discover
communities-list reads at them and resolve the display fields
client-side: useProfileAvatar for the owner row, one batched useProfiles
lookup per members page.

Writes and /v1/members/:address/communities have no v2 counterpart and
stay on v1.

Layer a requested-address guard on top of the batch profile parse: both
userId and ethAddress are deployer-controlled, so an avatar claiming an
address the batch did not ask for is dropped rather than filling that
member's row.

* fix: hold the members skeleton until the profile batch resolves

Address-only members render before their Catalyst batch lands, so the
list flashed raw hex addresses where v1 went straight from skeleton to
named rows.

Move the enrichment into useCommunityMemberCards, which gates the list
until the batch covers the members on screen. Coverage, not emptiness,
is the test: the profile cache is shared, so it can already hold entries
for a community being switched into. Once a community has resolved once,
an appended page holds back only its own pending rows instead of
blanking the list. A member with no deployed profile still gets a cache
entry, so nobody is hidden and the address fallback stands.

Also type the card role as Role instead of string, which caught two spec
fixtures using an "admin" role this endpoint never returns.

* refactor: serve every profile read from a single cache

useProfiles kept a second hand-rolled cache in features/cast2/peer.ts,
so the community detail resolved its owner through profile.client and
its members through peer.ts — two caches, two requests for the same
address.

Point useProfiles at profile.client, which since #4... (continued)

5771 of 6660 branches covered (86.65%)

Branch coverage included in aggregate %.

81 of 83 new or added lines in 12 files covered. (97.59%)

13957 of 14239 relevant lines covered (98.02%)

22.88 hits per line