Page MenuHomePhabricator

[lib] introduce getAvatarForThreadEntity function
AbandonedPublic

Authored by ginsu on Mar 21 2023, 10:43 PM.
Tags
None
Referenced Files
Unknown Object (File)
Mon, Nov 25, 6:34 AM
Unknown Object (File)
Wed, Nov 6, 3:38 PM
Unknown Object (File)
Wed, Nov 6, 3:16 AM
Unknown Object (File)
Mon, Nov 4, 11:14 PM
Unknown Object (File)
Mon, Nov 4, 11:14 PM
Unknown Object (File)
Thu, Oct 31, 5:45 PM
Unknown Object (File)
Thu, Oct 31, 5:45 PM
Unknown Object (File)
Thu, Oct 31, 5:44 PM
Subscribers

Details

Reviewers
ashoat
atul
Summary

getAvatarForThreadEntity handles the personal thread avatars. For personal thread avatars, I should see the other user's avatar on my screen, and they should see mine. For example, in my 1on1 chat with atul, I should see atul's avatar on my screen and atul should see my avatar on his screen. To handle this behavior I looked at what we did when getting the uiName in useResolvedThreadInfo and used it as inspiration to get the correct avatar for this thread type.

The majority of this function is just making sure that the`threadEntity` argument is the correct type. Once we validate that we can grab the non viewer user in this thread, we return their user avatar. If any of these checks fail then we should return null since this is not considered a personal thread, and useGetAvatarForThread will then later make sure we give this thread a channel thread avatar.


Depends on D7132

Test Plan

Please check out the screenshots to see that I am getting the correct user avatars for personal threads:

My friends list:

Screenshot 2023-03-22 at 3.01.06 AM.png (1×1 px, 740 KB)

My chats with dan, ryan and nicola all show each user's user avatar

Screenshot 2023-03-22 at 3.01.20 AM.png (1×1 px, 924 KB)

Diff Detail

Repository
rCOMM Comm
Lint
No Lint Coverage
Unit
No Test Coverage

Event Timeline

ginsu edited the test plan for this revision. (Show Details)

removed some unnecssary checks

ashoat requested changes to this revision.Mar 22 2023, 12:22 PM

I am skeptical that you need to be touching entity-text.js or entity-helpers.js at all. Can you explain what updates you think you need to the EntityText framework and why?

If you just want to populate a field of ThreadInfo as a function of the underlying RawThreadInfo and Redux store, you almost certainly need to be looking at threadInfoFromRawThreadInfo.

useResolvedThreadInfos handles converting a ThreadInfo to a ResolvedThreadInfo, the latter of which does ENS resolution. Maybe the reason you're doing this here is that you think you'll eventually need ENS resolution in getAvatarForThreadEntity? If so, I'm not sure this approach will work with our previously discussed useENSAvatar approach... if we're fetching ENS avatars for a batch of threads at once, we'll need something more like useENSAvatars (plural).

lib/utils/entity-text.js
186 ↗(On Diff #23971)

Do you need to update this to include avatar?

199 ↗(On Diff #23971)

This returns a UserEntity (see type on line 215). Do you need to update this to include avatar?

This revision now requires changes to proceed.Mar 22 2023, 12:22 PM

you almost certainly need to be looking at threadInfoFromRawThreadInfo.

useResolvedThreadInfos handles converting a ThreadInfo to a ResolvedThreadInfo, the latter of which does ENS resolution.

This cleared up a huge misunderstanding I had between ThreadInfo and ResolvedThreadInfo I should never have touched entity-text.js and entity-helpers.js. I did some digging and I'm going to want to do something similar to how we used to get the uiName before we introduced all the logic for entities for getting the correct personal thread avatars.

No longer necessary with D7178