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

Allow RpcRequest params to be of any type, instead of requiring an array #2751

Merged
merged 1 commit into from
May 31, 2024

Conversation

mcintyre94
Copy link
Collaborator

@mcintyre94 mcintyre94 commented May 30, 2024

This provides flexibility for APIs that do not use an array of params. For example Helius' non-standard APIs expect params to be an object and don't use an array wrapper, like this:

{
    "jsonrpc": "2.0",
    "id": "text",
    "method": "getTokenAccounts",
    "params": {
        "owner": "some-address",
        "limit": 100
    }
}

This can be handled with a parametersTransformer:

const api = createRpcApi<HeliusDasApi>({
    parametersTransformer: (params) => params[0],
});

But currently this is a type error, because parametersTransformer is required to return unknown[]. This PR allows it to just return unknown so that the above is no longer a type error.

This provides flexibility for APIs that do not use an array of params
Copy link

changeset-bot bot commented May 30, 2024

🦋 Changeset detected

Latest commit: 78619c9

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 36 packages
Name Type
@solana/rpc-spec Patch
@solana/accounts Patch
@solana/rpc-api Patch
@solana/rpc-transformers Patch
@solana/rpc-transport-http Patch
@solana/rpc Patch
@solana/sysvars Patch
@solana/web3.js-experimental Patch
@solana/rpc-subscriptions-api Patch
@solana/rpc-subscriptions Patch
@solana/rpc-graphql Patch
@solana/transaction-confirmation Patch
@solana/addresses Patch
@solana/assertions Patch
@solana/codecs-core Patch
@solana/codecs-data-structures Patch
@solana/codecs-numbers Patch
@solana/codecs-strings Patch
@solana/codecs Patch
@solana/compat Patch
@solana/errors Patch
@solana/fast-stable-stringify Patch
@solana/functional Patch
@solana/instructions Patch
@solana/keys Patch
@solana/options Patch
@solana/programs Patch
@solana/rpc-parsed-types Patch
@solana/rpc-spec-types Patch
@solana/rpc-subscriptions-spec Patch
@solana/rpc-subscriptions-transport-websocket Patch
@solana/rpc-types Patch
@solana/signers Patch
@solana/transaction-messages Patch
@solana/transactions Patch
@solana/webcrypto-ed25519-polyfill Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

Copy link
Collaborator

@buffalojoec buffalojoec left a comment

Choose a reason for hiding this comment

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

Seems fairly inconsequential, and the JSON RPC spec actually also uses objects not arrays.

@@ -3,7 +3,7 @@ import { Callable } from '@solana/rpc-spec-types';
import { RpcRequest } from './rpc-request';

export type RpcApiConfig = Readonly<{
parametersTransformer?: <T extends unknown[]>(params: T, methodName: string) => unknown[];
parametersTransformer?: <T extends unknown[]>(params: T, methodName: string) => unknown;
Copy link
Collaborator

Choose a reason for hiding this comment

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

Do we still want the array enforced for input here?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I think so, because the developer doesn't control that - it's just the input params to their function. From a JS perspective that'll always be a list, I think.

@steveluscher
Copy link
Collaborator

I checked the JSON-RPC 2.0 spec, and your change checks out! https://www.jsonrpc.org/specification#parameter_structures

@steveluscher
Copy link
Collaborator

…also uses objects not arrays.

The spec allows both.

@mcintyre94 mcintyre94 merged commit 6340744 into master May 31, 2024
8 checks passed
@mcintyre94 mcintyre94 deleted the params-transformer-nolist branch May 31, 2024 10:42
Copy link
Contributor

github-actions bot commented Jun 3, 2024

🎉 This PR is included in version 1.91.9 🎉

The release is available on:

Your semantic-release bot 📦🚀

Copy link
Contributor

Because there has been no activity on this PR for 14 days since it was merged, it has been automatically locked. Please open a new issue if it requires a follow up.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Jun 18, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants