Skip to content
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

Fix API_VERSION #20

Open
tabaktoni opened this issue Oct 10, 2024 · 1 comment
Open

Fix API_VERSION #20

tabaktoni opened this issue Oct 10, 2024 · 1 comment

Comments

@tabaktoni
Copy link
Collaborator

From @PhilippeR26

I received an interesting question : why ApiVersion and SpecVersion do not have the same type? Why an object on one side and a string on the other side?

/**
* A Starknet RPC spec version, only two numbers are provided
* @pattern ^[0-9]+\\.[0-9]+$
*/
export type SpecVersion = string;

/**
* The version of wallet API the request expecting. If not specified, the latest is assumed
*/
export interface ApiVersion {
api_version?: string;
}

Honestly, the question is legit.

From @tabaktoni

  1. Question ?
    _The second question I have here, and I can't remember what it is, is how developers correlate API_VERSION and SPEC_VERSION.

API_VERSION is the version of the API provided by the wallet (internally whatever), and it can be whatever let's say: 33.7.56
SPEC_VERSION is the version of the RPC Specification wallet provided, and It can be only one of the versions of the spec let's say: 0.7.1

Now, how do you correlate these two as there is no specification correlation is I guess wallets provide some table on their documentation saying:
API_VERSION SPEC_VERSION
33.7.56 | 0.7.1
33.7.55 | 0.7.1
33.7.53 | 0.7.1
33.7.32 | 0.7.0_

  1. Fix
    But I think I could do:
    export type API_VERSION = string;

and

export interface ApiVersionRequest {
  api_version?: API_VERSION;
}

And avoid using ApiVersion NAME in this case i think all should be ok with naming collision

@PhilippeR26
Copy link

Wallet teams are interested to have rather quickly a new version of this lib, including the string types for both versions responses.

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

No branches or pull requests

2 participants