After some discussion with @ashoat and @atul about how to fetch the ens uri for ens avatars we decided to have two separate components to render avatars: UserAvatar and ThreadAvatar this diff handles UserAvatar and a future diff will handle ThreadAvatar.

Here is a quick overview of why we went this way (thanks @atul):

Forgive me if I'm missing something, but this is what I was thinking for user avatars.

1. userStore.userInfos is the "source of truth" for ClientAvatars on the client.
2. The ClientAvatar for a given user can be directly queried from userStore.userInfos with a userID.
3. Therefore, the Avatar component ONLY needs a userID prop in order to get "everything it needs" to render the user avatar.
4. The simplest possible API for the Avatar component is a single userID prop.
5. The Avatar component can use userID and a hook named eg useClientAvatarForUserID in order to query userStore.userInfos to get the ClientAvatar for a given user (if it exists)

This prevents us from having to compute anything "outside" of the Avatar component to then be passed in. All we need is to pass in the userID, which we almost certainly have anywhere we're displaying Avatars since they're usually displayed alongside username. I also think it's cleaner and easier to reasonable about if everything happens internally "within" the Avatar component instead of counting on the containing component to determine what should be displayed in the contained Avatar component.

Depends on D7187

I was able to render all three avatar types: Emoji, Image, and ENS

Emoji:

Image by hardcoding: const avatarInfo = { type: 'image', uri: 'https://picsum.photos/200' }

ENS by hardcoding const avatarInfo = { type: 'ens' } and the other values like the provider and ethAddress from this gist