Add react hooks for transaction-planning and -sending - #1869
Conversation
🦋 Changeset detectedLatest commit: 4b5f5bb The changes in this PR will be included in the next version bump. This PR includes changesets to release 48 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 |
BundleMonFiles updated (3)
Unchanged files (147)
Total files change +317B +0.06% Final result: ✅ View report in BundleMon website ➡️ |
|
Documentation Preview: https://kit-docs-1kwzd706s-anza-tech.vercel.app |
trevor-cortex
left a comment
There was a problem hiding this comment.
Adds four new hooks (usePlanTransaction, usePlanTransactions, useSendTransaction, useSendTransactions) that wrap the corresponding methods on ClientWithTransactionPlanning / ClientWithTransactionSending as useAction-based reactive actions. Each is a ~one-line delegation into useAction((abortSignal, input) => client.method(input, { abortSignal })), plus tests, typetests, README, and a minor changeset.
The pattern matches the design goals set up by useAction — fresh AbortSignal per dispatch, supersede-aborts-previous, stale-while-revalidate on data/error. Because the hooks are so thin, the real coverage is useAction's own; the added tests just verify the plumbing (input forwarded, signal injected, resolve/reject surfaced), which is the right scope. Docs are thorough — JSDoc has @param / @returns / @example / @see, README has a grouped section with a runnable snippet.
One consistency nit worth flagging (inline): the send-hook typetests use ActionResult<never, ...> where the plan-hook typetests use precise ActionResult<[input: ...], ...>. Both compile, but the never variant is a weaker assertion. Non-blocking.
Notes for subsequent reviewers
- Input unions are duplicated from the client method signatures.
useSendTransactionre-declaresInstructionPlanInput | SingleTransactionPlan | SingleTransactionPlan['message'], anduseSendTransactionsre-declaresInstructionPlanInput | TransactionPlanInput. If the client methods inkit-pluginsgrow another accepted input shape, these hooks (and their typetests) will silently narrow the accepted set. Worth confirming these unions match the currentClientWithTransactionSendingdefinitions inkit-plugins, and consider whether deriving viaParameters<typeof client.sendTransaction>[0]would be more future-proof. - README section deviates slightly from the surrounding style. The other hooks in this file each get their own H3; this PR groups the four new ones under a single "Transaction planning & sending" H3 with a bullet list. Reads fine, but if the intent is to give each hook a dedicated API-reference entry, four sub-headings would match the pattern.
Overall LGTM — behavior is correct, follows the established useAction shape, docs and changeset are in order. (Would approve if I had write access; leaving as a comment review.)
3d13640 to
2066a9f
Compare
2066a9f to
eecae8b
Compare
b940dc7 to
8744015
Compare
8744015 to
8458772
Compare
eecae8b to
8da5a8a
Compare
Merge activity
|
8da5a8a to
eb09af5
Compare
8458772 to
119873a
Compare
eb09af5 to
4b5f5bb
Compare
|
🔎💬 Inkeep AI search and chat service is syncing content for source 'Solana Kit Docs' |

Summary of Changes
This PR adds hooks for the functions from
ClientWithTransactionPlanningandClientWithTransactionSendingto the@solana/reactpackageusePlanTransactionusePlanTransactionsuseSendTransactionuseSendTransactionsAll are just
useAction-shaped wrappers around these client functions. As with the wallet hooks, they take aclientwith the required plugin as a param.