Allow RpcRequest params to be of any type, instead of requiring an array #2751
Conversation
This provides flexibility for APIs that do not use an array of params
🦋 Changeset detectedLatest commit: 78619c9 The changes in this PR will be included in the next version bump. This PR includes changesets to release 36 packages
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 |
| @@ -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; | |||
There was a problem hiding this comment.
Do we still want the array enforced for input here?
There was a problem hiding this comment.
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.
|
I checked the JSON-RPC 2.0 spec, and your change checks out! https://www.jsonrpc.org/specification#parameter_structures |
The spec allows both. |
|
🎉 This PR is included in version 1.91.9 🎉 The release is available on: Your semantic-release bot 📦🚀 |
|
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. |
This provides flexibility for APIs that do not use an array of params. For example Helius' non-standard APIs expect
paramsto 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:But currently this is a type error, because
parametersTransformeris required to returnunknown[]. This PR allows it to just returnunknownso that the above is no longer a type error.