feat: Allow address as optional parameter to hooks

[technophile-04]

Description:

This is helpful, especially while playing around with proxy contracts.

cc @phipsae he requested this feature since he has playing around with new challenges, and always find himselfs updating the hooks to take in adddress as optional parameter

[phipsae]

Hey!

I've implemented address override support for scaffold-eth hooks in my ZK voting dApp, and also for a prediction market. I think a lot of apps in production have some factory contract pattern.

The voting app has a VotingFactory contract that deploys new Voting contracts on-demand. Users create votes through the factory, and the frontend needs to interact with these dynamically-deployed contracts using the same ABI but different addresses.

SE-2 hooks only read the contract address from deployedContracts.ts, which doesn't work when contracts are deployed at runtime.

I updated the hooks to accept an optional address override for both useScaffoldWriteContract and useScaffoldReadContract. Super simple change, and it worked immediately with Cursor :)

Happy to discuss (I think there was already discussion about this before):)

[rin-st]

Hey! Thanks for the implementation example!

[1] So as I understand it in your case useScaffoldReadContract works with Voting since you already have Voting contract in your deployment file.

[2] But if there's no Voting deployment in that file, just VotingFactory it won't work since useScaffoldReadContract (and others) can only read contracts from packages/nextjs/deployments, it's kind of hardcoded from types which is complex. There will be no Voting contract in that folder.

Not sure if it makes sense to make the changes only for [1] since I think in most of the cases we need [2] and it's not so easy to implement. We need to find a way to put data of the contracts created by factories to packages/nextjs/deployments. Maybe try to get contracts data also from /artifacts, not only from /deployments.
So, [1] looks like a workaround for [2] and it's absolutely not clear that you need mock instance contract in deployments.

What do you think, should we try to implement [2], go with [1] or just omit the issue?

The easiest way is just use wagmi's useReadContract with abi, you can get abi from /hardhat/artifacts/contracts or block explorer. (contract is created from factory, without deployment in deployment file, case [2]):

  const { data: greeting } = useReadContract({
    address: "<address>",
    abi,
    functionName: "greeting",
  });

So maybe let's just add this somewhere in the docs?

cc @technophile-04