Page MenuHomePhabricator

[lib] Refactor ENSCache lambdas a little bit
ClosedPublic

Authored by ashoat on Jan 28 2023, 7:18 AM.
Tags
None
Referenced Files
F2858298: D6429.diff
Tue, Oct 1, 10:27 AM
Unknown Object (File)
Mon, Sep 30, 7:16 AM
Unknown Object (File)
Thu, Sep 19, 11:29 PM
Unknown Object (File)
Mon, Sep 16, 6:13 PM
Unknown Object (File)
Mon, Sep 16, 5:44 PM
Unknown Object (File)
Mon, Sep 16, 5:36 PM
Unknown Object (File)
Sat, Sep 14, 10:02 PM
Unknown Object (File)
Thu, Sep 12, 1:52 AM
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