bytes32 type is too strict

[roninjin10]

Is there an existing issue for this?

• I have searched the existing issues

Package Version

latest

TypeScript Version

latest

Current Behavior

The type for bytes32 only accepts hex numbers of type 0x..... Have to awkwardly convert bytes to a hex value. I think not accepting a string makes sense as it could be a mistake but literal bytes should be valid

Expected Behavior

Should loosen type to accept bytes arrays too

Link to Minimal Reproducible Example (TypeScript Playground)

https://github.com/ethereum-optimism/optimism/blob/ef8d1454ddd68cc6a42129549595cb0f1d84af87/packages/atst/src/index.ts

Steps To Reproduce

Pass in any bytes array to a contract method that accepts bytes32

Anything else?

No response

[Raiden1411]

You could try extending the config like it's shown here.

For the wagmi package something like this should work

import "abitype";

declare module "wagmi/node_modules/abitype" {
  export interface Config {
    BytesType: Uint8Array | string;
  }
}

[roninjin10]

Nice! I still think it should be the default. It’s odd for literal bytes to not match type for something expecting bytes

[roninjin10]

Looks really easy to make it the default I can do the pr

[Raiden1411]

Ethers does use something similar Reference

Could possibly make sense in having a similar default

[tmm]

The default used to be string | ArrayLike<number> and I changed it to `0x${string}` to be stricter. Ideally, the defaults represent the most basic types that still adhere to the ABI spec.

When thinking about defaults, I think about ABI item inputs and outputs. Does `0x${string}` | Uint8Array make sense? For inputs, they both work since you likely need to do some encoding to get usable data. For outputs though, likely you would decode to a single type `0x${string}` insead of the union of both values.

For example, if I want to decode '0x0123456789abcdef000000000000000000000000000000000000000000000000' with 'bytes8' as the ABI type, the most basic result type is `0x${string}` (value: '0x0123456789abcdef') versus converting that to Uint8Array.

Think there are two approaches here:

• Keep default BytesType the same and consumers can configure ABIType however they like
• Allow for configurable input and output types (something like BytesInputType, BytesOutputType)

[Raiden1411]

I think that option two could possibly make more sense given that signMessage already uses something similar to this and there are other methods that could possibly leverage from this.

[tmm]

Agree. Let's go with that. PR welcome!

[Raiden1411]

Being worked on #78

[roninjin10]

fwiw I disagree with past me here. Consistently using hex strings is quite nice

[roninjin10]

I always wonder if there are peformance reasons to use bytes array rather than hex strings though