refactor: Update ENS utils to accept chain ID #7150
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Codecov ReportPatch coverage:
Additional details and impacted files@@ Coverage Diff @@
## main #7150 +/- ##
==========================================
+ Coverage 32.94% 32.97% +0.02%
==========================================
Files 1005 1005
Lines 32638 32649 +11
Branches 8383 8384 +1
==========================================
+ Hits 10753 10765 +12
+ Misses 21885 21884 -1
☔ View full report in Codecov by Sentry. |
Gudahtt
force-pushed
the
refactor-ens-cache-to-accept-chain-id
branch
from
91215d2
to
b8d439d
Compare
Gudahtt
added
needs-dev-review
Gudahtt
added
the
No QA Needed/E2E Only
Gudahtt
force-pushed
the
refactor-ens-cache-to-accept-chain-id
branch
4 times, most recently
from
4069161
to
ffe0248
Compare
|
Passing E2E smoke test run: https://app.bitrise.io/app/be69d4368ee7e86d/pipelines/c43d4b77-534d-47f0-9fed-008e4be16058 |
|
This is ready for review, but I am moving it back into draft temporarily because there is one more related change that I'm planning to add. |
Gudahtt
force-pushed
the
refactor-ens-cache-to-accept-chain-id
branch
from
422fb94
to
4d51b55
Compare
Gudahtt
force-pushed
the
refactor-ens-cache-to-accept-chain-id
branch
2 times, most recently
from
03b69cf
to
65c1152
Compare
The ENS utility functions now accept chain ID instead of network ID. Chain ID is easier for us to access because we know the chain ID for all configured networks at all times, as it's a required property. The network ID has to be looked up dynamically at runtime, meaning that we don't know what it is until after the network has loaded. The network ID is still used internally by the ENS utility functions because the library we use for ENS support still expects network ID rather than chain ID. This was done to simplify the upcoming network controller update. The new update replaces `network` with `networkId` and `networkStatus`, where the ID is `null` while the network is loading. This forces us to handle that loading state anywhere the network ID had been used. Reducing the usages of network ID means avoiding that work. This relates to MetaMask/mobile-planning#1226
The new `getCachedENSName` function will retrieve a cached name from the cache, ensuring that we don't need to reference the cache directly from elsewhere in the codebase. This removes another reference to the network ID. The testing setup was a bit awkward because `ENSCache.cache` is a property, which Jest offers no way to mock out at the moment. But this is resolved in jest v29 with the `replaceProperty` method. A workaround using hooks has been used as an interim solution.
Gudahtt
force-pushed
the
refactor-ens-cache-to-accept-chain-id
branch
from
65c1152
to
ea9e94d
Compare
|
Kudos, SonarCloud Quality Gate passed! |
Gudahtt
removed
the
needs-dev-review
metamaskbot
added
the
release-7.8.0
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Development & PR Process
release-xxlabel to identify the PR slated for a upcoming release (will be used in release discussion)needs-dev-reviewlabel when work is completedneeds-qa: PR requires manual QA.No QA/E2E only: PR does not require any manual QA effort. Prior to merging, ensure that you have successful end-to-end test runs in Bitrise.Spot check on release build: PR does not require feature QA but needs non-automated verification. In the description section, provide test scenarios. Add screenshots, and or recordings of what was tested.QA Passedlabel when QA has signed off (Only required if the PR was labeled withneeds-qa)team-(orexternal-contributorlabel if your not a MetaMask employee)Description
The ENS utility functions now accept chain ID instead of network ID. Chain ID is easier for us to access because we know the chain ID for all configured networks at all times, as it's a required property. The network ID has to be looked up dynamically at runtime, meaning that we don't know what it is until after the network has loaded.
The network ID is still used internally by the ENS utility functions because the library we use for ENS support still expects network ID rather than chain ID.
This was done to simplify the upcoming network controller update. The new update replaces
networkwithnetworkIdandnetworkStatus, where the ID isnullwhile the network is loading. This forces us to handle that loading state anywhere the network ID had been used. Reducing the usages of network ID means avoiding that work.Issue
This relates to https://github.com/MetaMask/mobile-planning/issues/1226
Checklist