-
Notifications
You must be signed in to change notification settings - Fork 430
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Social proof blocks #2603
Social proof blocks #2603
Conversation
bidirectionalBlocks: mergeMaps( | ||
stateA.bidirectionalBlocks, | ||
stateB.bidirectionalBlocks, | ||
), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The way bidirectionalBlocks
works, I think this would allow some clobbering to happen. For example, how should these two merge?
{ did:example:a -> { did:example:b -> true } }
{ did:example:a -> { did:example:c -> true } }
I think we'd want to find something like this:
{ did:example:a -> { did:example:b -> true, did:example:c -> true } }
As-is I think it would end-up like this, and we'd lose did:example:b
:
{ did:example:a -> { did:example:c -> true } }
Co-authored-by: devin ivy <devinivy@gmail.com>
export const mergeMaps = <V, M extends HydrationMap<V>>( | ||
mapA?: M, | ||
mapB?: M, | ||
): M | undefined => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@devinivy special note: I axed the Merges
interface here so that I could use this more easily within mergeNestedMaps
. No change to types or functionality that I can tell, but unsure if I knocked over Chesteron's Fence anywhere else.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also general note that I extracted these and made a util.test.ts
test
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good stuff!
…cements * origin/main: (181 commits) Minor OAuth client fixes (#2640) Version packages (#2639) OAuth: 2FA (#2633) Version packages (#2622) Update data source for `getSuggestedFollowsByActor` (#2630) Add in-memory did cache to Ozone backend (#2635) Filter out reference lists from `getLists` (#2629) lexicons: add missing ozone Tag event type to unions (#2632) ✨ Add ozone proxy for getLikes and getRepostedBy (#2624) Upgrade pnpm/action-setup in workflows (#2625) ✨ Add proxy for user typeahead through ozone (#2612) Fix development commands (#2623) Add starter packs to post hydration (#2613) Social proof blocks (#2603) Appview: apply hosting status in getRecord (#2620) Add `labelersPref` to `getPreferences` union return types (#2554) Version packages (#2618) Add new preference and api for bsky app state; also put preference updates within transactional lock regions (#2492) remove mentions of sandbox (#2611) Appview: simple fix for no-hosted known followers (#2609) ...
This PR ensures that if I follow Daniel, and Daniel follows Devin, but Devin blocks Daniel, when I view Devin's profile I do not see Daniel as part of
knownFollowers
.I also extracted some utils and added a few tests + added a new seed specifically for
knownFollowers
testing to handle these 2nd-party blocks more clearly/easily.