[common, core] Update: allow instantiation with only chain id

[leightkt]

Description

Issue: #1520

Allows a new web-3-onboard instance to be instantiated with only an id required in the Chain object.
Updates setChain function to accept optional arguments of rpcUrl, label, and token to add if needed to add a chain and chain was only instantiated with an id.

Test Notes:
To run this demo use the command yarn && yarn dev to get the project running at http://localhost:8080/

In the Onboard object, set a chain or two (I used Goerli and Optimism) to only their Ids:
{ id: '0x5' },

{ id: 10 },

Test switching chains.

after testing that initial behavior- add optional arguments to Optimism button and retest switch chains:
<button on:click={() => onboard.setChain({ chainId: 10, rpcUrl: 'https://mainnet.optimism.io', label: 'Optimism', token: 'OETH'})} >Set Chain to Optimism</button >

PLEASE NOTE- Checklist must be complete prior to review.

Checklist

• Increment the version field in package.json of the package you have made changes in following semantic versioning and using alpha release tagging
• Check the box that allows repo maintainers to update this PR
• Test locally to make sure this feature/fix works
• Run yarn check-all to confirm there are not any associated errors
• Confirm this PR passes Circle CI checks
• Add or update relevant information in the documentation

Docs Checklist

• Include a screenshot of any changes (see docs README on running locally)
• Add/update the appropriate package README (if applicable)
• [NA ] Add/update the related module in the docs demo (if applicable)
• Add/update the related package in the docs/package.json file (if applicable)

If this PR includes changes to add an injected wallet or SDK wallet module:

Please complete the following using the internal demo package.

Tests with demo app (injected)

• send transaction
• switch chains
• sign message
• sign typed message
• disconnect

Tests with demo app (SDK)

• send transaction
• switch chains
• sign message
• sign typed message
• disconnect

Docs Changes:

To test changes: start the svelte project demo (yarn && yarn dev from root directory). Goerli and Optimism Chains have been instantiated with just a chainId.

Video of Testing Changes:
LOOM VIDEO

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated
web3-onboard-docs	❌ Failed (Inspect)			Mar 20, 2023 at 9:02PM (UTC)

[MOZGIII]

Looks good to me! Although, not sure demo app changes are intended...

[MOZGIII]

Just noting a good accompanying feature is to allow RPC URL to be passed explicitly in the appropriate places: i.e. when adding the chain to an injected wallet the RPC URL is required - but it's only then, and if it's needed.

---

I don't actually see the changes in this PR that would handle the chain addition without the URL. Will the wallet just return an error here?

---

@sesh92, could please provide a review here?

[MOZGIII]

I'd expect some changes around here:

web3-onboard/packages/core/src/chain.ts

Line 76 in 5dcf0c9

chain,

To either allow passing the whole chain to add (when it's not in the init config), rather than chainId, or to handle the case where the RPC URL is not provided. Or is the latter not necessary because we'll be just getting an error, which is already handled?

[leightkt]

@MOZGIII Sounds like you're looking for allowing for the passing of a rpcUrl (and token and label) as optional parameters in setChain i.e.:
onboard.setChain({ chainId: 10, rpcUrl: 'https://mainnet.optimism.io', label: 'Optimism', token: 'OETH'}) to pass any needed parameters if they weren't set on instantiation. Is that correct?
Can you provide some use case details? It will help me to better understand the end goal.

[MOZGIII]

end goal.

No goal in particular except for the better alignment of the internally available APIs and what they allow/offer with the potential use cases.

Currently, the setChain can't be used unless the chain was fully specified during the core initialization. It makes it impossible to add just the Chain ID to the chains list and init the core, and then, if and when the chain addition is required, dynamically obtain the parameters to add the chain (i.e. interactively from the user, or from a backend of some sort) - and then use them during setChain.

Ultimately, the way things would be set up after this PR, it would be possible to omit the parameters that are only required for addChain from the core initialization, which is good. It enables us to just use custom code for adding/switching the chain if needed, and doesn't force us to provide dummy values at core init.

I'd even put the newly optional values into a subobject to be more explicit about their nature and separate them from the rest (i.e. chainId is actually the only essential parameter, and the rest can be placed under addChainParams?: AddChainParams, where all AddChainParams fields are non-optional).

I.e. like:

type ChainId = number | biting | ...;
type Chain = {
  chainId: ChainId;
  addChainParams?: AddChainParams;
}
type AddChainParams = {
  rpcUrl: string;
  label: string;
  token: string;
  // ...
}

This way the API users know what the parameters are for, and the implementors know for what purpose the RPC URL is supposed to be used (i.e. don't accidentally start calling it directly instead of passing it to the wallet).

[Adamj1232]

What happens if label, token or rpcUrl aren't defined on init and one or any subset are missing when this is called?

[MOZGIII]

In theory, the call should fail, and the provider should throw an implementation-dependent error. Not sure what will happen in practice, and how it's handled here...

[leightkt]

correct- the call will fail. We currently throw and error and display this message:

My understanding is that it would be up to the dapp to handle?

[MOZGIII]

Yep. This modal is good enough for the case where the app doesn't care - if it does care, I think the whole addChain invocation logic can be implemented on the app side - to then follow with the onboard switch chain call. This is not the most straightforward way around the use of the available API for the users, but a good one for those who know what they're doing. We might want to note it in the docs though.

[Adamj1232]

Nice!! Good work!!

[lnbc1QWFyb24]

Nice work, looks good!