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
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