The idea is to provide a facade API composed of interconnected factory methods.
The aim is to shortcut the interaction with fuel nodes by:
Providing a single fuels entry point within the fuels library (aka a provider factory)
The returned object from the previous step should contain module initializers for:
wallet
contract
predicate
script
From there, most methods can be chained and used fluidly.
This proposal can enable:
Intuitive API that doesn't require memorization
Concise onliners to be easily composed and exchanged
Seamless usage across different platforms (node, browser)
Easily digestible code snippets to be used in documentation
Etc.
A public API crafted around this idea can narrow the user journey to what matters, hiding away most of the internal implementation details (not all) and paving the way for broader refactorings down the road, in which we can change or swap underlying pieces without changing the public APIs, reducing the occurrences of breaking changes.
Pseudo-code
[!IMPORTANT]
All code samples in this page are pesude code.
API
Here's a rough example of how it would look.
// single import from fuels, the rest comes from the dApps
import { fuels, TESTNET_NETWORK_URL } from 'fuels';
// typegen'd classes
import {
MyContractFactory,
MyContract2Factory,
MyContract3Factory,
} from './sway-api';
// usage example
const options: fuels.Options = { ... };
(await fuels(TESTNET_NETWORK_URL, options))
.contract(MyContractFactory)
.addContracts([ MyContract2Factory, MyContract3Factory ])
.get_counter()
.callParams({
forward: CoinQuantityLike;
gasLimit: BigNumberish;
})
.txParams({
gasPrice: BigNumberish;
gas limit: BigNumberish;
maturity?: number;
maxFee?: BigNumberish;
witnessLimit?: BigNumberish;
variableOutputs: number;
})
.<get|dryRun|simulate|call>();
Promises
The fuels entry point is a provider factory that returns a promise.
The promise is resolved after initializing the connection with the node.
TL;DR
The idea is to provide a facade API composed of interconnected factory methods.
The aim is to shortcut the interaction with
fuel
nodes by:fuels
entry point within thefuels
library (aka a provider factory)This proposal can enable:
A public API crafted around this idea can narrow the user journey to what matters, hiding away most of the internal implementation details (not all) and paving the way for broader refactorings down the road, in which we can change or swap underlying pieces without changing the public APIs, reducing the occurrences of breaking changes.
Pseudo-code
API
Here's a rough example of how it would look.
Promises
The
fuels
entry point is a provider factory that returns a promise.The promise is resolved after initializing the connection with the node.
From there, the user has everything to move on.
Callbacks (+ transfer example)
The same can be seamlessly achieved with callbacks.
Oneliners
Normalized TX cost estimation
Custom TX Builder