-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactoring single source of truth for dapp state #510
base: develop
Are you sure you want to change the base?
Refactoring single source of truth for dapp state #510
Conversation
…get into feature/si-1641-refactoring-single-source-of-truth-for-chainid-and-rpc
…get into feature/si-1641-refactoring-single-source-of-truth-for-chainid-and-rpc
Preview stand statusPreview stand available on testnet |
…get into feature/si-1641-refactoring-single-source-of-truth-for-chainid-and-rpc
@@ -19,7 +19,7 @@ const URL_CID_REGEX = | |||
/[/.](?<cid>Qm[1-9A-HJ-NP-Za-km-z]{44,}|b[A-Za-z2-7]{58,}|B[A-Z2-7]{58,}|z[1-9A-HJ-NP-Za-km-z]{48,}|F[0-9A-F]{50,})([./#?]|$)/; | |||
|
|||
export const useVersionCheck = () => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The name does not reflect the return type. I mean that this hook does not expect to receive remoteCid, currentCid, remoteCidLink (I expect to receive the status).
I can suggest renaming the hook to "useVersionControl" or "useVersionStatus"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am all in on that, but maybe in other PR. Want to focus on daap/chain state.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, lets set TODO
const router = useRouter(); | ||
|
||
const isChainTypeUnlocked = useMemo( | ||
() => router.pathname === '/wrap/[[...mode]]', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Lets set "TODO: in the future this condition will change (will depend by router.pathname and chainType)"
detectNetwork(): Promise<Network> { | ||
// eslint-disable-next-line @typescript-eslint/no-misused-promises | ||
if (!this._cache['detectNetwork']) { | ||
this._cache['detectNetwork'] = this._uncachedDetectNetwork(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
will this code break in the future?
it seems that this._cache['detectNetwork'] was not intended to be overridden
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not really, because ethers.js is being deprecated. The reason for this is override is we can only funnel ethers trough wagmi via ether's Web3Provider. But Web3Provider is built for connecting to the wallet rpc that can change chain id anytime, and it's constantly requesting it to keep it's state updated. This override removes cache reset logic for chainId and allows web3provider to act as JsonRpcProvider.
useDappChain, | ||
SupportOnlyL1Chains, | ||
DAPP_CHAIN_TYPE, | ||
} from './web3-provider'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not just use provider
naming, like part of the "namespace" of web3?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To keep code structure convention:
- web3-provider(folder)
- web3-provider.ts (exports Web3Provider)
- index.ts(exports from web3-provider.ts)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This allows us to always find root module/file by component name.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
move up in the file structure:
from 'modules/web3/web3-provider/connect-wallet-modal'
to 'modules/web3/modals'
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's only used by web3-provider that's why it's nested inside, see https://feature-sliced.design/. Things like web3/hooks are used all over the place and that's why they are grouped by type. Generally we have to avoid grouping files by type.
modules/web3/hooks/index.ts
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Adding a module breaks the current "feature-sliced" structure (I agree that there is no suitable entity within the "feature-sliced" design).
Considering that the module is a large independent part of a app, it seems we should move 'consts/chains.ts' to 'web3' module.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Modules are part of feature-sliced design. I agree though that we should move some const there. But I want to scope this PR, let's put this into roadmap.
chainType: DAPP_CHAIN_TYPE; | ||
setChainType: React.Dispatch<React.SetStateAction<DAPP_CHAIN_TYPE>>; | ||
isChainTypeUnlocked: boolean; | ||
isDappChainTypeMatched: boolean; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
isChainTypeMatched? (consistency naming with other fields)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
or:
- dappChainType
- setDappChainType
- isDappChainTypeUnlocked
context.displayName = 'SupportedChainsContext'; | ||
|
||
export const useSupportedChain = () => { | ||
const { chainId: dappChain } = useLidoSDK(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why dappChain, not sdkChainId?
By my opinion: it may confuse and create conflict for the code reader.
|
||
export const useSupportedChain = () => { | ||
const { chainId: dappChain } = useLidoSDK(); | ||
const { chainId: walletChain } = useAccount(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not walletChainId?
Description
problem is SUPPORTED_CHAINS inlcude L2 chains but other pages only support ethereum chains and not l2 chains
Demo
Code review notes
Testing notes
Checklist: