Page MenuHomePhabricator

[lib] Add support for EntityText uiName to entity-text.js
ClosedPublic

Authored by ashoat on Feb 4 2023, 10:06 AM.
Tags
None
Referenced Files
Unknown Object (File)
Tue, May 14, 12:03 AM
Unknown Object (File)
Sun, Apr 28, 11:13 AM
Unknown Object (File)
Sun, Apr 28, 11:13 AM
Unknown Object (File)
Sun, Apr 28, 11:11 AM
Unknown Object (File)
Sun, Apr 28, 11:11 AM
Unknown Object (File)
Sun, Apr 28, 11:10 AM
Unknown Object (File)
Sun, Apr 28, 11:10 AM
Unknown Object (File)
Sun, Apr 28, 11:10 AM
Subscribers

Details

Summary

In the following diffs I'll update ThreadInfo.uiName so that it can return an EntityText, which have to be resolved at callsites to show ENS names.

But since EntityText itself can contain ThreadEntitys that are represented by their uiName, we need to add the capability for resolving these to EntityText itself.

Nesting an EntityText type within itself feels a bit hacky, but I think it's necessary. I considered resolving ThreadEntitys that have ENS names in their uiName at an earlier step, eg. in the ET tag function... but if we resolve them that early, we'll lose the context we need for linking (the uiName should be linked to the thread, and not to the individual user profiles). So instead we have to keep the "structure" here represented in the AST until it's resolved at the final step.

Test Plan

Tested in combination with following diffs

Diff Detail

Repository
rCOMM Comm
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

Don't swap out a ThreadEntity until we have at least one ENS name resolved

This revision is now accepted and ready to land.Feb 4 2023, 12:10 PM

Design changed a little bit. Now instead of having ThreadInfo.uiName be a pluralized EntityText containing the users, it's going to be an array of UserEntitys (which is technically a subtype of EntityText).

I moved the pluralization to a later part in the pipeline because we want to decide whether we need to filter the viewer out of the list of members BEFORE we pluralize, and that decision isn't made until we know the value of ignoreViewer, which is during the resolution step.

ab9584.png (792×1 px, 193 KB)

Failure from the Codegen JSI workflow. Not sure why it wasn't also flagged by ESLint & Flow & Jest workflow?

EDIT: Getting the same thing locally:

9d0333.png (888×1 px, 606 KB)

EDIT: It should've actually failed on yarn eslint --max-warnings=0:

345cba.png (498×1 px, 134 KB)