Update examples to the most recent, yet unreleased near-api-js version
#6
Conversation
| }; | ||
| const nearConnection = await connect(connectionConfig); | ||
| // Create a connection to testnet RPC | ||
| const provider = new providers.JsonRpcProvider({ |
There was a problem hiding this comment.
should we add networkId to the providers? I think it makes sense for them to know what network they are operating with... but I also understand if we prefer to not add it
Does ethers or [insert name of the other library] instanciate providers passing a networkId?
There was a problem hiding this comment.
I prefer adding a method async getNetwork(): Promise<string> method to a provider to retrieve the network name on demand and avoid issues if somebody instantiates Provider as testnet while the actual RPC points out to mainnet
There was a problem hiding this comment.
I like that idea, lets do it
There was a problem hiding this comment.
I would just cache the answer (since I don't expect the network to ever change for an instantiated provider), it would even be cool to maybe just do it once in the constructor and set it up
javascript/examples/batch-actions.js
Outdated
|
|
||
| const myKeyStore = new keyStores.InMemoryKeyStore(); | ||
| const keyPair = KeyPair.fromString(privateKey); | ||
| await myKeyStore.setKey("testnet", accountId, keyPair); | ||
| // Create a signer from a private key string | ||
| const signer = KeyPairSigner.fromSecretKey(privateKey); // ed25519:5Fg2... | ||
|
|
||
| const connectionConfig = { | ||
| networkId: "testnet", | ||
| keyStore: myKeyStore, | ||
| nodeUrl: "https://test.rpc.fastnear.com", | ||
| }; | ||
| const nearConnection = await connect(connectionConfig); | ||
| // Create a connection to testnet RPC | ||
| const provider = new providers.JsonRpcProvider({ | ||
| url: "https://test.rpc.fastnear.com", | ||
| }); | ||
|
|
||
| const account = await nearConnection.account(accountId); | ||
| // Create an account object | ||
| const account = new Account(accountId, provider, signer); // example-account.testnet |
There was a problem hiding this comment.
Might be an unpopular opinion, but if signer and provider are always created from just one arg why not just pass those directly into the Account constructor?
const privateKey = process.env.PRIVATE_KEY;
const accountId = process.env.ACCOUNT_ID;
const rpcUrl = process.env.RPC_URL
const account = new Account(accountId, rpcUrl, privateKey);
Might not work for other provider and signer types
There was a problem hiding this comment.
I always end up recreating this util in every single project I work on
There was a problem hiding this comment.
the privateKey makes sense to be honest, the rpcUrl not so much, as a provider might need authentication
There was a problem hiding this comment.
I wouldn't change that as I hope in the future the KeyPairSigner won't be the only implementation of Signer
but I like the idea of having a function to create an account in one line, so I suggest we add a static function to an Account
const account = Account.fromPrivateKey(accountId, rpcUrl, privateKey);…rever it's possible
…ar-examples/near-api-examples into update_examples_to_recent_near-api-js
It's a companion PR that demonstrates the new API of
near-api-js(introduced in near/near-api-js#1513) in action