Also rewrite useStringForUser to call into useENSNames.
Details
Details
Tested existing calls of useStringForUser, both when logged in as an ENS user and when not
Diff Detail
Diff Detail
- Repository
- rCOMM Comm
- Lint
No Lint Coverage - Unit
No Test Coverage
Event Timeline
Comment Actions
- Don't check isViewer in useENSNames, that check is handled in useStringForUser. This was causing an issue where useENSNames wasn't doing looking for the viewer's ENS name
- Move optionality to type parameter. Now if you pass an array with no nulls/undefineds, Flow will understand that the result will have no nulls/undefineds
Comment Actions
Keep stringForUser's advantageous property of only querying for ENS names if !isViewer
| lib/hooks/ens-cache.js | ||
|---|---|---|
| 27–30 ↗ | (On Diff #21493) | I'd maybe pull cachedResult out of the return statement (similar to ethAddress) just since it's 4 lines here, but whatever you prefer. |
| 53 ↗ | (On Diff #21493) | I'd maybe put the !ethAddress and fetchedAddresses.has(ethAddress) checks next to each other, but really doesn't matter. |
| 75–79 ↗ | (On Diff #21493) | Might be missing something here, or just not know enough about Javascript, but is there a benefit to using a Map instead of a plain old Object as a key-value store? This just seems a bit more verbose than for example: setENSNames({
...ensNames,
[ethAddress]: result
}); |