Skip to content

Conversation

@JkrishnaD
Copy link
Contributor

Problem

Implement the sendTransaction call as a hook

Summary of Changes

as mentioned in #167 to create a sendTransaction hook i have done

  • i have added the useSendTransaction in hooks/send-transaction.ts
  • added typeset file for send-transaction.ts - ensures type safety and correct response shapes for all supported encodings
  • export the hook from main index.ts
  • updated the react package README.md
  • followed existing naming convention and changeset rules for consistency

@changeset-bot
Copy link

changeset-bot bot commented Aug 31, 2025

🦋 Changeset detected

Latest commit: d9dce41

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

This PR includes changesets to release 4 packages
Name Type
@gillsdk/react Minor
@gillsdk/examples-basics Minor
@gillsdk/examples-tokens Minor
@gillsdk/tests-e2e Minor

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

@JkrishnaD
Copy link
Contributor Author

@nickfrosty check this out once (my bad multiple commits in order to fix the changeset file)

@macalinao
Copy link
Contributor

What's the benefit of using a mutation over something like useCallback, or adding this to createSolanaClient?

@JkrishnaD
Copy link
Contributor Author

@macalinao here we used useMutation because it is a state changing rpc-call as we are sending the transaction on-chain which changes the state. so i have used it there

Copy link
Collaborator

@GuiBibeau GuiBibeau left a comment

Choose a reason for hiding this comment

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

Hey! Nice work on this hook 🎉

Just noticed a small naming issue: the parameter signature in line 19 should probably be wireTransaction or transaction instead.

Currently it's a bit confusing because:

  • We're passing IN a transaction (base64 encoded)
  • We're getting OUT a signature (the transaction ID)

Using signature for the input makes it seem like we're passing in a signature, when we're actually passing in the whole transaction. What do you think about renaming it?

@JkrishnaD
Copy link
Contributor Author

@GuiBibeau thanks for the review i'll make sure all the changes which are reviewed will be added by tomorrow

Copy link
Collaborator

@nickfrosty nickfrosty left a comment

Choose a reason for hiding this comment

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

The idea for this hook is good but the usage pattern is wrong...

Think about how a dev would actually use this hook as its currently written: you have to have the transaction already before even instantiating the hook. Which means you could only really uses this inside a guard component that has the transaction passed to it. That makes no sense.

Instead, developer usage should look something like this:

const { sendTransaction } = useSendTransaction({
      config: {
        encoding: "base64",
        preflightCommitment: "confirmed",
        skipPreflight: false,
      },
    });
    
    const signature = await sendTransaction(...validTransaction);

Please rework this hook to:

  • rebase to master
  • reword the hook as described above
  • fix the imports in the files you added to use .js file extensions (see the other hooks and typeset tests)
  • fix the incorrect readme entry (that does not even match how you would use this as currently written) to be correct for the updated usage
  • remove your retry delay since it does not give users any flexibility of control
  • remove your incorrect comment for return the transaction signature as a base-64 encoded string. its a Signature, which is a base58 encoded string

edit: this hook also needs to support the options and config, similarly to how all the other hooks accept them.

@JkrishnaD
Copy link
Contributor Author

@nickfrosty I'm doing all the changes you mentioned.

questions: the edit you mentioned about the options and the config these are not defined for the useMutation in the gillRpc types so i'm thinking to define the mutationOptions in the hook itself.

thought: it is good to have them globally by defining them in the hooks/types.ts file

@JkrishnaD JkrishnaD requested a review from nickfrosty October 9, 2025 05:15
@catmcgee catmcgee requested a review from tobeycodes October 22, 2025 16:11
Copy link
Collaborator

@tobeycodes tobeycodes left a comment

Choose a reason for hiding this comment

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

It looks like no commits have been made since this comment so this is still a work in progress.

#229 (review)

@JkrishnaD
Copy link
Contributor Author

JkrishnaD commented Oct 22, 2025

@tobeycodes #229 (comment) for this question can you give the clarity for me

in this the types mentioned there are only for the useQuery hook they are not working for the useMutation which we are using in the sendTransaction.

Thinking: to add these types in the sendTransaction hook itself. i need the clarification on this.

@JkrishnaD JkrishnaD requested a review from tobeycodes October 23, 2025 07:42
Copy link
Collaborator

@tobeycodes tobeycodes left a comment

Choose a reason for hiding this comment

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

Nice work.

question: can you give me an example when you would use sendTransaction instead of signAndSendTransaction?

Comment on lines 71 to 74
return {
...mutation,
sendTransaction: mutation.mutateAsync,
};
Copy link
Collaborator

Choose a reason for hiding this comment

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

request: if we rename mutateAsync we should also rename mutate

Copy link
Contributor Author

Choose a reason for hiding this comment

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

ha it make sense i'll add that as send: mutation.mutate

// Returns a transaction Signature
return response;
},
mutationKey: [GILL_HOOK_CLIENT_KEY, "sendTransaction"],
Copy link
Collaborator

Choose a reason for hiding this comment

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

request: key should also include urlOrMoniker

Copy link
Contributor Author

Choose a reason for hiding this comment

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

problem:There is no scope to get this urlOrMoniker you have mentioned.

approach: we can add the network parameter in the inputs which has the rpc's like this
type SolanaNetwork = "devnet" | "mainnet-beta" | "testnet" | string; and in the inputs we can use this network?: SolanaNetwork; this makes the key unique

other than this not getting any approaches to make this unique

Copy link
Collaborator

Choose a reason for hiding this comment

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

@JkrishnaD There is. Take a look at the other hooks that use it

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Hey @tobeycodes, I’ve reviewed how other hooks are implemented, and I noticed that all of them include their input parameters (like address, mint, signature) in the queryKey/mutationKey to ensure uniqueness.

pattern for key looks like Key: [GILL_HOOK_CLIENT_KEY, "methodName", ...uniqueParams]

problem: Using urlOrMoniker to make the mutationkey unique doesn’t work. Multiple transactions can happen on the same network (mainnet, devnet, etc.), so the key would not be unique per transaction.

approach: We include the transaction itself in the hook inputs and in the mutationKey.

reasoning: This ensures each transaction has a unique key, following the same pattern as other hooks like useTransaction or useBalance. It guarantees correct caching, mutation states, and avoids collisions between different transactions.

mutationFn: async (tx: SendTransactionArgument) => {
// The RPC method expects the base-64 encoded transaction as the first argument.
const response = await rpc
.sendTransaction(tx as Base64EncodedWireTransaction, {
Copy link
Collaborator

Choose a reason for hiding this comment

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

question: why not sendAndConfirmTransaction per the docs? https://www.gillsdk.com/docs/react/hooks/transactions#current-approach

request: can we remove type casting?

Copy link
Contributor Author

@JkrishnaD JkrishnaD Oct 23, 2025

Choose a reason for hiding this comment

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

Using sendTransaction here is intentional, this hook is designed to send transactions non-blocking and handle confirmation separately for better UX and flexibility.

sendAndConfirmTransaction waits for full confirmation before returning, which would block the mutation response and delay UI updates. With sendTransaction, we can immediately return the signature and confirm in the background.

and we can't remove the type casting there without that we are getting the No overload error

async function handleClick() {
try {
// Create a new transaction
const transaction = createTransaction(...);
Copy link
Collaborator

Choose a reason for hiding this comment

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

thought: i could be wrong but I do not believe createTransaction returns Base64EncodedWireTransaction | string;. Is this correct?

export function createTransaction<

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yes you were right it doesn't returns the Base64EncodedWireTransaction but there is no other function in there returns the Base64EncodedWireTransaction.
approach: thinking to remove this and just keep the hook usage like structure of hook.

...(config),
})
.send({ abortSignal });
// Returns a transaction Signature
Copy link
Collaborator

Choose a reason for hiding this comment

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

request: lets remove comments like this throughout the pull request. the code itself expresses this comment

Copy link
Contributor Author

Choose a reason for hiding this comment

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

ha i'll remove all the comments in the hook

@JkrishnaD JkrishnaD requested a review from tobeycodes October 31, 2025 19:47
Copy link
Collaborator

@tobeycodes tobeycodes left a comment

Choose a reason for hiding this comment

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

For @nickfrosty to review

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

Successfully merging this pull request may close these issues.

5 participants