Question / Feature: account:Account param in certain util methods may only need SA address

[livingrockrises]

Describe the feature you would like

below methods

  client,
  account,
  permissionId,
}: {
  client: PublicClient
  account: Account
  permissionId: Hex
}) => {
  return (await client.readContract({
    address: SMART_SESSIONS_ADDRESS,
    abi,
    functionName: 'getNonce',
    args: [permissionId, account.address],
  })) as bigint
}

export const isSessionEnabled = async ({
  client,
  account,
  permissionId,
}: {
  client: PublicClient
  account: Account
  permissionId: Hex
}) => {
  return (await client.readContract({
    address: SMART_SESSIONS_ADDRESS,
    abi,
    functionName: 'isSessionEnabled',
    args: [permissionId, account.address],
  })) as boolean
}

requires a whole Account object to be passed. can it be just smartAccountAddress or conditional optional params

Additional context

No response

[kopy-kat]

tbh I dont like how we handle accounts and clients in the sdk now - for v0.2 I have some ideas for how we can streamline the ux and open to feedback here

[Dhruv-Mishra]

This extends to other methods as well which do not leverage any additional property from the account object other than the address.

Should this change extend to those methods as well?

[kopy-kat]

yeah I wonder what the best solution here is - one option would be to still use the account but make it into a class and have the methods be called on this class, like account.installModule but not sure how useful that is as well and it could become quite unwieldy to maintain

what do you think the best solution would be here?

[Dhruv-Mishra]

Where are these methods being leveraged and are these only used in a TS environment?
To what extent do we wish to enforce type safety here? Are we willing to allow any json object with an address field, containing a valid address, to be accepted as the input for our methods or do we want the object to strictly adhere to our definition of Account and Address?

Since TS types and interfaces don’t exist at runtime, if type safety is a priority, then we should either use a class or use Typeguards for our function arguments.

I will review any similar or related projects to see what they follow

[kopy-kat]

fixed by https://github.com/rhinestonewtf/module-sdk/pull/113/files