Proposal: Refactor Wallet SDK Structure for Enhanced Flexibility and Maintainability

[jinoosss]

Description

Current Structure

• Methods Implementation: Currently, the functions provided in the methods directory directly interact with the window object to execute Adena-specific functions.
• Issues Identified:
  • State Management: Direct interaction with the window object creates challenges in state management and handling data effectively.
  • Limited Extensibility: The current structure is tightly coupled with Adena, making it difficult to extend the SDK to support other providers or RPC services.

wallet-sdk
└── src
    ├── methods                # Function methods (direct window object access)
    │   ├── connect.ts
    │   ├── disconnect.ts
    │   ├── getBalance.ts
    │   └── broadcastTransaction.ts
    ├── utils                  # Utility functions
    ├── types                  # Common type definitions
    └── ...

Proposed Changes

• Provider Injection: Refactor the existing methods to use an injected provider object, allowing for more flexible and extensible function execution. This change will enable the SDK to support not only Adena but also other providers like tm2-wallet.
• Support for RPC Providers: Extend functionality to allow the SDK to work with RPC providers alongside wallet providers.

wallet-sdk/
└── src/
    ├── providers
    │   ├── wallet             # In addition to Wallet, it manages other providers
    │   │   ├── errors
    │   │   ├── adena-wallet-provider
    │   │   └── tm2-wallet-provider
    │   └── ...                # Other providers
    ├── utils 
    ├── types                  # Common type definitions
    ├── config
    ├── core
    │   ├── sdk
    │   └── ...
    └── ...

Expected Outcomes

• Enhanced Extensibility: The new structure will allow for easier integration of additional providers (e.g., different wallet types, RPC services), making the SDK more versatile.
• Improved State Management: By abstracting the provider interactions, the SDK will achieve better state management and data handling, reducing potential errors.

[dongwon8247]

@RezaRahemtola @clockworkgr What do you guys think?

[RezaRahemtola]

Looks interesting !

Agree on the provider abstraction to build an SDK that is wallet provider agnostic.

For this part:

Support for RPC Providers: Extend functionality to allow the SDK to work with RPC providers alongside wallet providers.

Isn't gno-js-client already supporting RPC providers and more officially linked to Gno ?

Introducing state management hooks for popular web framework would really simplify the usage. In my mind we should hopefully end up with library/ies similar to viem and wagmi on Ethereum in term of devx