Page MenuHomePhabricator

[lib] Refactor ENSCache lambdas a little bit
ClosedPublic

Authored by ashoat on Jan 28 2023, 7:18 AM.
Tags
None
Referenced Files
Unknown Object (File)
Fri, Dec 6, 12:23 PM
Unknown Object (File)
Nov 1 2024, 1:54 PM
Unknown Object (File)
Oct 29 2024, 7:54 PM
Unknown Object (File)
Oct 29 2024, 7:54 PM
Unknown Object (File)
Oct 29 2024, 7:54 PM
Unknown Object (File)
Oct 29 2024, 7:51 PM
Unknown Object (File)
Oct 2 2024, 6:38 PM
Unknown Object (File)
Oct 2 2024, 1:35 PM
Subscribers

Details

Summary

This code had some many-to-many branching behavior, so I had previously defined a lambda to avoid code duplication.

In this diff I swap the lambda vs. main function body parts, as this will be beneficial for the following diffs. Arguably it reads cleaner this way anyways if you're familiar with the async IIFE pattern.

Depends on D6428

Test Plan

cd lib && ALCHEMY_API_KEY=... yarn test utils/ens-cache.test.js

Diff Detail

Repository
rCOMM Comm
Branch
ashoat/ens
Lint
No Lint Coverage
Unit
No Test Coverage

Event Timeline

atul added inline comments.
lib/utils/ens-cache.js
123–131

Might be a dumb question, but what's the point of immediately awaiting an IIFE like this?

Would something like

const ethAddress = await this.provider.resolveName(normalizedENSName);
const normalizedEthAddress = ethAddress ? normalizeETHAddress(ethAddress) : undefined;

be equivalent?

This revision is now accepted and ready to land.Jan 28 2023, 12:55 PM
lib/utils/ens-cache.js
123–131

It's only laid out this way for convenient access to fetchETHAddressPromise in a later diff