Skip to content

Adopt createViemFallbackClient in manual viem client call sites #167

Description

@L03TJ3

Adopt createViemFallbackClient in manual viem client call sites

Summary

Several widgets and app/example entry points still create viem clients manually with fixed http() transports. These are good follow-up candidates for @goodwidget/core's createViemFallbackClient so they can share cached RPC discovery, viem fallback ranking, and consistent RPC ordering.

Suggested replacement candidates

  • /home/runner/work/GoodWidget/GoodWidget/packages/goodreserve-widget/src/useReserveBootstrap.ts (around lines 176-183)
    • Replace the manual read client createPublicClient({ chain, transport: http() }).
    • Keep the provider-backed wallet client behavior intact.
  • /home/runner/work/GoodWidget/GoodWidget/packages/streaming-widget/src/adapter/useStreamingClients.ts (around lines 33-37)
    • Replace the manual per-chain public client using http(chain.rpcUrls.default.http[0]).
    • Keep the wallet client on custom(provider).
  • /home/runner/work/GoodWidget/GoodWidget/packages/streaming-widget/src/adapter/chains.ts (around lines 21-25)
    • Replace createBasePublicClient()'s fixed Base RPC client with a fallback-enabled public client.
  • /home/runner/work/GoodWidget/GoodWidget/packages/citizen-claim-widget/src/adapter.ts (around lines 277-280)
    • Replace the non-custodial http(rpcUrl) read client returned by getPublicClientForChain().
    • Leave custodial/integrator-supplied clients unchanged.
  • /home/runner/work/GoodWidget/GoodWidget/packages/ai-credits-widget/src/adapter.ts (around lines 450-463 and 1184-1189)
    • Replace the CELO read clients created with http().
    • Keep provider-backed wallet clients unchanged.
  • /home/runner/work/GoodWidget/GoodWidget/packages/ai-credits-widget/src/chainClient.ts (around lines 93-104)
    • Evaluate replacing the fixed Base/Celo read clients while preserving explicit baseRpcUrl / celoRpcUrl inputs as primary RPCs.
  • /home/runner/work/GoodWidget/GoodWidget/packages/staking-migration-widget/src/adapter.ts (around lines 453-469)
    • Replace the fixed Fuse read client.
    • Keep the wallet client on the active provider.
  • /home/runner/work/GoodWidget/GoodWidget/examples/storybook/src/fixtures/custodialEip1193.ts (around lines 69-79)
    • Replace the per-chain public/wallet http(config.rpcUrl) clients so Storybook fixtures exercise the same fallback behavior.

Required states, flows, and behaviors

  • Preserve all existing widget flows and chain-specific behavior.
  • Keep integrator/provider-backed wallet clients on custom(provider) where signing should continue through the connected wallet.
  • Preserve explicit widget/app RPC overrides as the primary endpoints when provided.
  • Avoid changing custodial client injection contracts or existing client-factory APIs unless needed for helper adoption.
  • Do not broaden this work into unrelated RPC/theming/widget refactors.

Execution plan

  1. Add a small helper adoption strategy per target file instead of one repo-wide refactor.
  2. Start with read-only public client call sites that currently use http() with chain defaults.
  3. For mixed public/wallet setups, use createViemFallbackClient for the public client first and keep the existing wallet client transport if it depends on the provider.
  4. For configurable RPC URLs, pass the explicit app/widget RPCs as primary fallbackRpcs so discovered RPCs stay secondary.
  5. Add targeted tests for any changed client-construction logic in widgets that already have coverage.

Acceptance criteria

  • Every adopted call site uses createViemFallbackClient or a small local wrapper around it instead of manually constructing fixed http() viem public clients.
  • Provider-backed wallet clients continue to behave exactly as before.
  • Explicit widget/app RPC URLs remain primary when configured.
  • Existing widget/example tests continue to pass, and any new targeted tests cover the adopted client-construction paths.
  • The work is delivered outside the current fallback-helper PR.

Human-reviewer checklist

  • The selected call sites are limited to the widgets/examples listed above or a justified subset.
  • Provider-backed wallet flows were not accidentally rerouted away from custom(provider).
  • Any explicit RPC override inputs still take precedence over discovered RPCs.
  • No unrelated widget behavior changed while swapping client construction.
  • Validation covers the affected packages/examples.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    Projects

    Status
    Prepare AI Task

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions