Page MenuHomePhabricator

[lib] Introduce `*AvatarDBContent` types
ClosedPublic

Authored by atul on Mar 17 2023, 12:17 PM.
Tags
None
Referenced Files
Unknown Object (File)
Thu, Mar 21, 6:50 AM
Unknown Object (File)
Mar 8 2024, 8:21 AM
Unknown Object (File)
Mar 7 2024, 3:58 AM
Unknown Object (File)
Mar 7 2024, 3:58 AM
Unknown Object (File)
Mar 7 2024, 3:58 AM
Unknown Object (File)
Mar 5 2024, 11:41 PM
Unknown Object (File)
Feb 27 2024, 12:34 PM
Unknown Object (File)
Feb 27 2024, 12:34 PM
Subscribers

Details

Summary

Introduce basic [Emoji/Avatar]DBContent types that will be stringified and stored in the avatar columns of the users and threads tables.

These aren't in use yet, just putting up types so Ginsu and I have the interfaces agreed upon to make implementation easier.

Test Plan

NA,

Diff Detail

Repository
rCOMM Comm
Branch
master
Lint
No Lint Coverage
Unit
No Test Coverage

Event Timeline

lib/types/avatar-types.js
11

This uploadID probably won't be used in the fetch query. Instead we'd use the container column of the uploads column to join with the users/threads table.

We could separately introduce an avatars table?

atul published this revision for review.Mar 17 2023, 12:19 PM
atul added inline comments.
lib/types/avatar-types.js
6

I know we exclude the # elsewhere, but we end up having to pre-pend it a lot throughout our code. I think it makes sense to store with the #, but happy to remove to keep consistent with thread color and whatnot.

ginsu added inline comments.
lib/types/avatar-types.js
6

When I was working on the rendering of the avatars I was under the impression that we wouldn't have #. If it's not a big deal, I would prefer that we drop # to keep it consistent

This revision is now accepted and ready to land.Mar 17 2023, 2:16 PM
lib/types/avatar-types.js
3

Also nit but could we rename to EmojiAvatarContent I probably will have to use these types in the client and I feel like having "db types" in the client is a little strange

lib/types/avatar-types.js
3

The way we're going to represent avatars on the client isn't necessarily how we're going to represent them in the DB. For example, for ImageAvatars on the client, we'll want localMediaUpload and filePaths instead of uploadID. If they end up being the same we can make EmojiAvatarContent an alias of EmojiAvatarDBContent or vice versa.

6

When I was working on the rendering of the avatars I was under the impression that we wouldn't have #. If it's not a big deal, I would prefer that we drop # to keep it consistent

Will make that change

address feedback (and sneak in ENSAvatarDBContent)

ENSAvatarDBContent will just be the type since everything else is handled on the client.

This revision was landed with ongoing or failed builds.Mar 20 2023, 7:32 AM
This revision was automatically updated to reflect the committed changes.