Open paouvrard opened 3 years ago
I don't think accessing several bridges simultaneously will be needed soon, so this is no high priority.
However the current design is very error prone for developers that switch between network only for testing (which should be common).
Note: when testing, switching bridge/network is done via process.env
and when testing a localhost dapp, different instances for different bridges can be tested on different ports so that transfers of different bridges don't conflict.
Moving the discussion here from https://github.com/near/rainbow-bridge-client/pull/4#pullrequestreview-604714953 and https://github.com/near/rainbow-bridge-client/pull/4#issuecomment-791079039
Dapps may want to connect to different bridges simultaneously and record bridge transfers of different bridges on the same URL. The current lib design assumes that dapps like https://github.com/near/rainbow-bridge-frontend will be connecting to a single bridge per URL (rinkeby.bridge.near.org for example) and uses
process.env
to access bridge contract addresses (process.env.ethLockerAddress for example). Transfers recorded in localStorage do not contain information about token connectors, bridges or networks.