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
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

atul added inline comments.
lib/utils/ens-cache.js
123–131 ↗(On Diff #21497)

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 ↗(On Diff #21497)

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