Skip to content

Refactor client initialization logic to use a generic lazy-loaded method #265

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

cypherpepe
Copy link

Replaced individual client initializations with a getClient method that lazily loads and stores clients in a single object. This reduces code duplication and simplifies the management of client instances.

Description

This PR refactors the client initialization logic by introducing a getClient method that lazily loads and caches clients in a single object. The previous approach initialized each client separately, leading to duplicated code and less maintainability. The new method reduces redundancy and makes the code more modular and easier to extend.

Test Plan

  1. Ensure that lazy initialization occurs without errors and that subsequent calls retrieve the cached instance.
  2. Confirm that client functionality is not impacted by the refactoring using both wallet and account configurations.

Related Issue

No related issue. This is an internal refactoring to improve code structure.

Notes

No additional front-end or navigation changes required.

Replaced individual client initializations with a getClient method that lazily loads and stores clients in a single object. This reduces code duplication and simplifies the management of client instances.
Copy link
Collaborator

@bonnie57 bonnie57 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @cypherpepe,

Thank you so much for your contribution and for taking the time to submit this PR! We really appreciate your effort and insights.

The idea of a generic lazy-loaded method is excellent! I’ve left a few comments for potential enhancements. Please take a look when you have a chance.

Thanks again for your support and for helping us improve! 🚀

private _ipAccount: IPAccountClient | null = null;
private _royalty: RoyaltyClient | null = null;
private _nftClient: NftClient | null = null;
private _clients: { [key: string]: any } = {};
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need to create a type-safe client to avoid using any. For example, define client-specific types:

type ClientRegistry = {
  ipAsset: IPAssetClient;
  permission: PermissionClient;
  // ...
};

* this method is called.
*
* @returns the IPAssetClient instance
* @param clientName - the name of the client
* @param ClientClass - the class of the client
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We now prefer using inline annotation. Could you use it as well?

public get ipAsset(): IPAssetClient {
if (this._ipAsset === null) {
this._ipAsset = new IPAssetClient(this.rpcClient, this.wallet, this.config.chainId);
private getClient<T>(clientName: string, ClientClass: new (...args: any[]) => T): T {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the client type is ClientRegistry, you can use the following code. You also need to consider the chainId inconsistency issue.

private getClient<K extends keyof ClientRegistry>(
    clientName: K,
    ClientClass: new (
        rpcClient: PublicClient, 
        wallet: SimpleWalletClient, 
        chainId?: ChainIds
    ) => ClientRegistry[K] 
): ClientRegistry[K]

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants