-
git clone https://github.com/OffchainLabs/arb-token-bridge
-
cd ./arb-token-bridge && yarn install
-
cd ./packages/use-wallet && yarn build
-
Set env vars:
-
touch ./packages/arb-token-bridge-ui/.env
-
In
.env
, addREACT_APP_INFURA_KEY=my-infura-key
-
For custom urls, set optional vars:
REACT_APP_ETHEREUM_RPC_URL=my-eth-node
REACT_APP_RINKEBY_RPC_URL=my-rinkeby-node
REACT_APP_GOERLI_RPC_URL=my-goerli-node
(see .env.sample) If no custom URL is provided, Infura will be used by default.
-
-
(back in root dir:)
yarn start_sdk
-
Open new terminal tab
-
yarn start_ui
-
Visit
http://localhost:3000/
- install
serve
:npm install -g serve
- (back in root dir:)
yarn build
yarn serve
-
Run the token bridge UI locally
-
Set env vars:
-
At this repository's root,
cp ./packages/arb-token-bridge-ui/.e2e.env.sample ./packages/arb-token-bridge-ui/.e2e.env
-
In the newly created file,
.e2e-env
, update yourSECRET_WORDS, ADDRESS, etc
in the format mentioned in the file.
-
-
cd ./packages/arb-token-bridge-ui/ && yarn e2e:run
Read more about the setup here.
We use a couple of tools to automate things (e.g. code formatting), maintain consistency and reduce noise for code reviews. For the optimal development experience, install the following tools:
- Yarn - Package manager
- Find Yarn install guide for your system here
- Prettier - Automatic code formatting
- Find Prettier integration for your code editor here
- EditorConfig - Automatic file formatting
- Find EditorConfig integration for your code editor here
- ESLint - Static analysis for JavaScript
- Find ESLint integration for your code editor here
A Deposit is tracked via a single Transaction
entry (in the useTransactions
hook) which represents its initiated L1 transaction; its L2 status is tracked via the L1ToL2MessageData
field.
-
Deposit is initiated via one of the deposit methods in
useArbTokenBridge
; its initialL1ToL2MessageData.status
is set toNOT_YET_CREATED
. -
The
RetryableTxnsIncluder
regularly polls forl1DepositsWithUntrackedL2Messages
(and finds it).- Note that the "normal" case for a found
l1DepositsWithUntrackedL2Messages
is one whose status isNOT_YET_CREATED
; it also looks for deposits with noL1ToL2MessageData
field at all — this is solely for backwards compatibility with cached transactions in the old UI.
- Note that the "normal" case for a found
-
fetchAndUpdateL1ToL2MsgStatus
is called; this immediately sets the L2 message's current status, and, if that status is non-terminal (i.e.,NOT_YET_CREATED
), it makes a call that waits for the status to return, and updates it accordingly.- We track the state of whether we're currently waiting for a terminal status to return via the
fetching
field; this prevents multiple redundant/asynchronous queries from being made. Note that when we cache transactions in localStorage, we set allfetching
fields to false (seelocalStorageReducer
); i.e., if we leave a page mid-fetch, we should start fetching again upon returning to the page.
- We track the state of whether we're currently waiting for a terminal status to return via the
-
If a retryable fails, a very similar lifecycle to 2-3 takes place, in which we poll to see if that status has been changed (to, i.e., redeemed). See
getFailedRetryablesToRedeem
.
The L1ToL2MessageData.l2TxID
field will be populated when/if the deposit succeeds; in the case of token deposits, this will be the execution transaction. For Eth deposits, this will be equal to the retryableCreationTxID
(Eth deposits have no execution transaction.)