-
Notifications
You must be signed in to change notification settings - Fork 1.4k
docs: add docs for tx deps prefetching optimisation #3499
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
Changes from 2 commits
6142254
4b69693
885d5a2
f4ff5d2
91103a3
ab0b6ca
76b97dd
85f738f
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,2 @@ | ||
--- | ||
--- |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,106 @@ | ||
# Optimising Contract Calls | ||
Dhaiwat10 marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
When you call a contract function via the SDK, it makes two major network requests: | ||
Dhaiwat10 marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
1. **Preparing the transaction**: This involves creating the transaction request, fetching dependencies for it, and funding it properly. | ||
Dhaiwat10 marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
2. **Sending the transaction**: This involves sending the transaction to the network and waiting for it to be confirmed. | ||
|
||
The below flowchart shows this entire process: | ||
|
||
 | ||
|
||
Since the SDK prepares the contract call _after_ the user presses 'Submit Transaction' (or your code invokes the `call` method), the chain feels slower to the user than it actually is. This is because of the network request needed to prepare the transaction. | ||
Dhaiwat10 marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
This can be mitigated by preparing the contract call _before_ the user presses 'Submit Transaction'. If the transaction is prepared beforehand, the SDK only has to send the transaction to the network and wait for it to be confirmed. This reflects the actual speed of the chain to the user. | ||
Dhaiwat10 marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
You can experience this yourself by trying out this [demo](https://fuel-wallet-prefetch-experiment-75ug.vercel.app/). | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Hmm should this be brought inside the SDK? Is it more beneficial for this to live inside a snippet? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This = demo or the hook? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Where does this URL come from? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The demo, usually we don't have any external deps for the docs, the links is from an external projects on Dhai's github |
||
|
||
 | ||
|
||
Because of the massive performance gains, we recommend this strategy for all contract calls. | ||
|
||
## Recommended Implementation | ||
|
||
> [!Note] This is an example for React, but the same logic can be applied to any framework. | ||
|
||
We recommend creating a `usePrepareContractCall` hook: | ||
|
||
```tsx | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Should this all be in a snippet for forwards compatibility? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It could be; but that would mean us having to create a new project for snippets since this is a React snippet. In the interest of speed and considering how important this info is for our ecosystem projects, I think it is fine if we create the snippets in a separate PR. Nick wants us to announce this asap on Twitter There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. As much as we love teaching devs how to fetch data in React, we still have two more weeks of code freeze. 🙂 There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I disagree, this is not about teaching people how to fetch data in React. It's about the overall idea of preparing contract calls in advance, leading to a faster transaction experience. About the code freeze, this is not adding any new code. Can we not get this in? |
||
import { FunctionInvocationScope, ScriptTransactionRequest } from "fuels"; | ||
import { useEffect, useState, useCallback, useRef } from "react"; | ||
|
||
export const usePrepareContractCall = (fn?: FunctionInvocationScope) => { | ||
const [preparedTxReq, setPreparedTxReq] = | ||
useState<ScriptTransactionRequest>(); | ||
const fnRef = useRef(fn); | ||
|
||
useEffect(() => { | ||
if (fn && fn !== fnRef.current) { | ||
fnRef.current = fn; | ||
(async () => { | ||
const txReq = await fn.fundWithRequiredCoins(); | ||
setPreparedTxReq(txReq); | ||
})(); | ||
} | ||
}, [fn]); | ||
|
||
const reprepareTxReq = useCallback(async () => { | ||
if (!fnRef.current) { | ||
return; | ||
} | ||
const txReq = await fnRef.current.fundWithRequiredCoins(); | ||
setPreparedTxReq(txReq); | ||
}, []); | ||
|
||
return { | ||
preparedTxReq, | ||
reprepareTxReq, | ||
}; | ||
}; | ||
``` | ||
|
||
This hook will prepare the transaction request for your contract call beforehand, and you can use the `reprepareTxReq` function to reprepare the transaction request if needed. | ||
|
||
You can use this hook in your UI logic like this: | ||
|
||
```tsx | ||
function YourPage() { | ||
// It is important to memoize the function call object. | ||
const incrementFunction = useMemo(() => { | ||
if (!contract || !wallet) return undefined; | ||
return contract.functions.increment_counter(amount); | ||
}, [contract, wallet, amount]); | ||
|
||
const { preparedTxReq, reprepareTxReq } = | ||
usePrepareContractCall(incrementFunction); | ||
|
||
const onIncrementPressed = async () => { | ||
if (preparedTxReq) { | ||
// Use the prepared transaction request if it is available. Much faster. | ||
await wallet.sendTransaction(preparedTxReq); | ||
} else { | ||
// Fallback to the regular call if the transaction request is not available. | ||
await contract.functions.increment_counter(1).call(); | ||
} | ||
|
||
/* | ||
* Reprepare the transaction request since the user may want to increment again. | ||
* This is important, since the old `preparedTxReq` will not be valid anymore | ||
* because it contains UTXOs that have been used among other things. | ||
* | ||
* You *must* re-prepare any prepared transaction requests whenever | ||
* the user does any transaction. | ||
*/ | ||
await reprepareTxReq(); | ||
}; | ||
} | ||
``` | ||
|
||
You can view the full code for this example [here](https://github.com/Dhaiwat10/fuel-wallet-prefetch-experiment/blob/main/src/components/Contract.tsx). | ||
|
||
## Important Things to Note | ||
|
||
- You _must_ re-prepare any prepared transaction requests whenever the user does any transaction. This is because the prepared transaction request will contain UTXOs that have been used among other things, and will therefore not be valid anymore. | ||
|
||
- You _must_ memoize the function call object. This is because the function call object is used to prepare the transaction request, and if it is not memoized, the function call object will be recreated on every render, and the transaction request will not be prepared correctly. |
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think eliminated is the wrong wording here, as we are instead optimistically preparing the transaction. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Doesn't it makes sense in the context of a tranasction's lifetime for the end user? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @danielbate Agreed, the request is optimistically fetched, not eliminated. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It is eliminated from the contract call's lifecycle, so I strongly think it is eliminated in that context. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems confusing to mix React tips with core
contract
documentation.A simple React recipe demoing the example hook may suffice.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I disagree that this is a React tip. Like I mentioned here: #3499 (comment)