Get Provider Chain Data by ChainId (number or hex) Instead of Chain name string

[Adamj1232]

Issue: Retrieving chain data when creating a provider with a non-standardized chain name requires mapping the chain ID to the Viem chain name. This introduces additional code complexity and increases the potential for errors.

Solution: Implement a Viem chain object keyed by chain ID, supporting both decimal and hexadecimal formats. It is recommended to primarily use the decimal value since it reflects current industry trends. This approach simplifies the code without adding extra complexity, although it does require developers to update their existing implementations. For backwards compatibility, a similar solution can be provided for currently supported chains and marked as deprecated.

Alternative Solution: Introduce a new Viem method that accepts a chain ID as input (either in hexadecimal or decimal format) and returns the corresponding chain name. This approach maintains backwards compatibility but adds extra weight to the Viem package and increases maintenance requirements when new chains are added.

I would love to open up the conversation more around this topic.

If help is wanted as this conversation evolves I would be happy to create a PR.

Note: I am an engineer at Blocknative and we are currently integrating and loving Viem!

[tmm]

Thanks for creating this discussion! Can you elaborate more on the following. Not sure I fully understand. Code snippets, etc. would be helpful.

Retrieving chain data when creating a provider with a non-standardized chain name requires mapping the chain ID to the Viem chain name. This introduces additional code complexity and increases the potential for errors.

[izayl]

@Adamj1232
I think it can be resolved by create a Record<number, Chain> in your own business.
because the Chain type has many configuration, and you can custom your own. If use chainId as the specific key, what if there are two Chain with the same chainId but different config?

[Adamj1232]

@izayl so you are saying there shouldn't be a standard to access the default chains and every dev would need to create a Record for this?
My proposed map is the same as you have said Record<number, Chain> but would be contained within the Viem project so it doesnt have to be reproduced over and over again which is it will with you current approach.
This is not flexible in that every time a project wants to expand they have to go through the list and find that custom string used as a key which is way more effort than necessary - bad devEx.
Why not use the current standard chainId (hex or number) to index?
Yes there are lots of configs for a chain but for most default chain objects there is only one per chainId.
If Viem is to make life better for devs dont make them add a bunch of code to integrate like a giant map for all chains.
Another option would to be remove the requirement of the Chain obj on initialization of the Client and just allow passing of the chainId and rpc.
@tmm For a project like web3-onboard we need the flexibility to support all EVM chains which Ethers does but for making the case to switch to Viem this is a very challenging lift without following some sort of standard here.

[jxom]

Hey @Adamj1232, chain is optional on the viem client, but it's highly recommended to pass one in to infer multicall & ENS resolver contract addresses, among other things like block/txn types for chains (e.g. some chains like Celo may not support gasLimit, etc).

The reason why we inverted control to the consumer to pass in a chain config instead of a chainId that maps to a config internally is because we are focused on keeping bundle size low, and having support for an indefinite amount of EVM chains will have a pretty large burden there.

FWIW, ethers controls this map internally, but they only have a very limited set of supported chains. Plus, ethers breaks when you use chains that have a different block/txn schema (as I mentioned above).

[jxom]

If you would rather a chainId approach, you could probably pass in a chain with an id and noop the other attributes.

const client = createPublicClient({
  chain: { 
    id,
    ...
  }
})

[Adamj1232]

@jxom ah gotcha, that will work for me! I was under the impression for some reason that the chain was required.
We are integrating Viem into web3-onboard and we can define the chains for ens support for grabbing token balances we need to be very flexible and support across evms. We too are working to keep our package slim so I want to avoid adding in mapping for chainId -> viem import
Really appreciate the work you are doing.
Would love to have one of you on for a Blocknative twitter spaces when our viem support goes live.