From b3c7925d9f3f2d4acc1d5dc84d1a3f6135a0263e Mon Sep 17 00:00:00 2001 From: gagdiez Date: Wed, 31 Jan 2024 11:52:40 +0100 Subject: [PATCH] General Fixes (#1697) * fix: renamed class to className * fix: removed unnecesary file * feat: added time-traveling testing * fix: more broken links * fix: broken links --- .../1.concepts/basics/accounts/access-keys.md | 4 +- docs/1.concepts/basics/actors.md | 4 +- docs/1.concepts/basics/overview.md | 6 +- docs/1.concepts/basics/protocol.md | 2 +- .../basics/transactions/gas-advanced.md | 4 +- docs/1.concepts/basics/transactions/gas.md | 4 +- docs/1.concepts/basics/validators.md | 4 +- docs/1.concepts/storage/storage-staking.md | 2 +- docs/2.develop/contracts/actions.md | 2 +- docs/2.develop/contracts/anatomy.md | 14 +- docs/2.develop/contracts/serialization.md | 6 +- docs/2.develop/contracts/storage.md | 8 +- docs/2.develop/deploy.md | 4 +- docs/2.develop/integrate/frontend.md | 4 +- docs/2.develop/integrate/quickstart.md | 10 +- docs/2.develop/integrate/welcome.md | 36 +- docs/2.develop/relevant-contracts/dao.md | 4 +- docs/2.develop/relevant-contracts/ft.md | 12 +- docs/2.develop/relevant-contracts/nft.md | 10 +- docs/2.develop/testing/integration.md | 56 ++-- .../testing/workspaces-migration-guide.md | 316 ------------------ docs/2.develop/upgrade.md | 4 +- .../crosswords/02-beginner/00-overview.md | 2 +- .../crosswords/02-beginner/03-actions.md | 6 +- .../04-cross-contract-calls.md | 2 +- docs/3.tutorials/examples/factory.md | 10 +- docs/4.tools/cli.md | 4 +- docs/4.tools/explorer.md | 10 +- docs/4.tools/indexer4explorer.md | 4 +- docs/4.tools/near-api-js/naj-account.md | 32 +- docs/4.tools/near-api-js/naj-contract.md | 6 +- docs/4.tools/near-api-js/naj-utils.md | 4 +- docs/4.tools/near-api-js/naj-wallet.md | 16 +- docs/4.tools/near-api-js/quick-reference.md | 14 +- docs/4.tools/welcome.md | 2 +- docs/5.api/rpc/access-keys.md | 16 +- docs/5.api/rpc/block-chunk.md | 12 +- docs/5.api/rpc/contracts.md | 28 +- docs/5.api/rpc/introduction.md | 6 +- docs/5.api/rpc/maintenance-windows.md | 2 +- docs/5.api/rpc/setup.md | 4 +- docs/5.api/rpc/transactions.md | 18 +- docs/6.integrator/errors/introduction.md | 2 +- docs/7.primitives/dao.md | 2 +- docs/7.primitives/nft.md | 6 +- docs/bos/api/near.md | 2 +- docs/bos/api/social.md | 4 +- docs/bos/api/state.md | 2 +- docs/bos/api/web-methods.md | 2 +- docs/bos/components.md | 153 --------- docs/bos/index.md | 39 --- docs/bos/overview.md | 12 +- docs/bos/tutorial/hello-lido.md | 90 ++--- docs/bos/tutorial/hello-near.md | 16 +- .../tutorial/indexer-tutorials/nft-indexer.md | 2 +- docs/bos/tutorial/quickstart.md | 94 +++--- docs/index.md | 100 +++--- docs/sdk/js/testing/integration-tests.md | 6 - docs/sdk/rust/testing/integration-tests.md | 2 - website/sidebars.js | 1 - 60 files changed, 365 insertions(+), 884 deletions(-) delete mode 100644 docs/2.develop/testing/workspaces-migration-guide.md delete mode 100644 docs/bos/components.md delete mode 100644 docs/bos/index.md diff --git a/docs/1.concepts/basics/accounts/access-keys.md b/docs/1.concepts/basics/accounts/access-keys.md index be21daff86d..42985447064 100644 --- a/docs/1.concepts/basics/accounts/access-keys.md +++ b/docs/1.concepts/basics/accounts/access-keys.md @@ -38,7 +38,7 @@ When needed, that third-party component could trigger the recovery process, help NEAR implements two types of access keys: `FullAccess` keys and `FunctionCall` keys. -
+
### Full Access Keys {#full-access-keys} As the name suggests, `FullAccess` keys have full control of an account, similar to having administrator privileges on your operating system. @@ -58,7 +58,7 @@ If you hand a `FullAccess` to someone, they will have **total control over the a You **add the first** Full Access Key of the account when [the account is created](creating-accounts.md). ::: -
+
### Function Call Keys {#function-call-keys} diff --git a/docs/1.concepts/basics/actors.md b/docs/1.concepts/basics/actors.md index 2a336ebd7b3..a0d56485bb6 100644 --- a/docs/1.concepts/basics/actors.md +++ b/docs/1.concepts/basics/actors.md @@ -10,7 +10,7 @@ There are 3 main actors interacting to form the NEAR ecosystem: -
+
## Users Users can have one or multiple [NEAR accounts](./accounts/introduction.md), which they can use to: @@ -19,7 +19,7 @@ Users can have one or multiple [NEAR accounts](./accounts/introduction.md), whic 2. **Execute** [decentralized apps](https://awesomenear.com) stored in the network, known as [smart contracts](./accounts/smartcontract.md). 3. **Develop** their own decentralized app and store it in the network. -
+
## Validators Validators are people distributed around the world, running the infrastructure that underlies the NEAR network. They serve two main jobs: diff --git a/docs/1.concepts/basics/overview.md b/docs/1.concepts/basics/overview.md index 5abf0f03bde..dc67db8572f 100644 --- a/docs/1.concepts/basics/overview.md +++ b/docs/1.concepts/basics/overview.md @@ -17,7 +17,7 @@ These accounts also have the permission to create subaccounts such as `nft.alice For more information see the **[accounts section](/concepts/basics/accounts/model)**. ::: -
+
## Keys @@ -32,7 +32,7 @@ Full access keys allow for full control of the account. You can send funds, crea For more information see the **[access keys section](/concepts/basics/accounts/access-keys)**. ::: -
+
### Contracts @@ -44,7 +44,7 @@ As an example, benji could have the root account `benji.near`. He then stores al For more information see a guide on **[deploying contracts](/sdk/rust/promises/deploy-contract)**. ::: -
+
### Storage diff --git a/docs/1.concepts/basics/protocol.md b/docs/1.concepts/basics/protocol.md index 9e35f1a0fc4..a13e5f722c6 100644 --- a/docs/1.concepts/basics/protocol.md +++ b/docs/1.concepts/basics/protocol.md @@ -10,7 +10,7 @@ In technical terms, NEAR is a [layer one](https://blockchain-comparison.com/bloc In simple terms, NEAR is **blockchain for everyone**. -
+
## Why Choose NEAR? {#why-build-on-near} NEAR has been developed with a focus on performance and usability, both for developers and users. diff --git a/docs/1.concepts/basics/transactions/gas-advanced.md b/docs/1.concepts/basics/transactions/gas-advanced.md index ef4f33c4626..68924452b44 100644 --- a/docs/1.concepts/basics/transactions/gas-advanced.md +++ b/docs/1.concepts/basics/transactions/gas-advanced.md @@ -35,7 +35,7 @@ Given the general-purpose nature of NEAR, function calls win the award for most With this level of complexity, it's no longer useful to walk through an example, enumerating each (see `ext_costs` under `wasm_config` using the [`protocol_config`](/api/rpc/protocol#protocol-config) RPC endpoint) of the gas calculations as we go (you can research this yourself, [if you want](https://github.com/near/nearcore/pull/3038)). Instead, let's approach this from two other angles: ballpark comparisons to Ethereum, and getting accurate estimates with automated tests. -
+
**How much of the gas fee goes as a 30% reward to the smart contract account?** The NEAR Whitepaper mentions that [30% of all gas fees](https://near.org/papers/the-official-near-white-paper/) go to smart contract accounts on which the fees are expensed. @@ -188,7 +188,7 @@ The price of 1 unit of gas at this block was 5000 yoctoNEAR (10^-24 NEAR). ## Some closing thoughts from the whitepaper {#some-closing-thoughts-from-the-whitepaper} -
+
Fundamentally, the NEAR platform is a marketplace between willing participants. On the supply side, operators of the validator nodes and other fundamental infrastructure need to be incentivized to provide these services which make up the “community cloud.” On the demand side, the developers and end-users of the platform who are paying for its use need to be able to do so in a way which is simple, clear and consistent so it helps them. A blockchain-based cloud provides several specific resources to the applications which run atop it: diff --git a/docs/1.concepts/basics/transactions/gas.md b/docs/1.concepts/basics/transactions/gas.md index fd49c1efa65..cb6c585f7da 100644 --- a/docs/1.concepts/basics/transactions/gas.md +++ b/docs/1.concepts/basics/transactions/gas.md @@ -92,7 +92,7 @@ To give you a starting point for what to expect for costs on NEAR, the table bel | Add Full Access Key | 0.42 | 0.042 | 4.2⨉10⁻⁵ | | Delete Key | 0.41 | 0.041 | 4.1⨉10⁻⁵ | -
+
Where do these numbers come from? NEAR is [configured](https://github.com/near/nearcore/blob/master/core/primitives/res/runtime_configs/parameters.yaml) with base costs. An example: @@ -145,7 +145,7 @@ Function calls are more complex and need you to attach an explicit amount of gas This maximum value of prepaid gas is subject to change but you can query this value by using the [`protocol_config`](/api/rpc/protocol#protocol-config) RPC endpoint and search for `max_total_prepaid_gas`. ::: -
+
How many tokens will these units cost? Note that you are greenlighting a maximum number of gas _units_, not a number of NEAR tokens or yoctoNEAR. diff --git a/docs/1.concepts/basics/validators.md b/docs/1.concepts/basics/validators.md index 0dfbccaac77..18e82786a9f 100644 --- a/docs/1.concepts/basics/validators.md +++ b/docs/1.concepts/basics/validators.md @@ -34,7 +34,7 @@ Since Validators validate all shards, high requirements are set for running them The current active Validators are available on the Explorer. The minimum seat price to become a block-producing validator is based on the 300th proposal. (If more than 300 proposals are submitted, the threshold will simply be the stake of the 300th proposal, provided that it’s larger than the minimum threshold of 25,500 $NEAR.) The current seat price to become a block-producing validator is updated live on the Explorer. Any validator nodes with stakes higher than the seat price can join the active set of Validators. -
+
Is there a plan to support GPU compute if certain validator nodes can offer that or is it just CPU?

We don't need GPU support as we are a POS chain and we require very little compute power. @@ -54,7 +54,7 @@ Like Validators, Chunk-Only Producers will receive, at minimum, 4.5% annual rewa If you'd like to further explore Validators and Nodes in general, you can visit the [Dedicated Validator Documentation Site](https://near-nodes.io/). -
+
If a developer writes a vulnerable or malicious dApp, is a validator implicitly taking on risk?

No. We have handled the potential damages to the network on the protocol level. For example, we have a lot of limiters that constrain how much data you can pass into a function call or how much compute you can do in one function call, etc. diff --git a/docs/1.concepts/storage/storage-staking.md b/docs/1.concepts/storage/storage-staking.md index 16323053fe1..4f62f2978d8 100644 --- a/docs/1.concepts/storage/storage-staking.md +++ b/docs/1.concepts/storage/storage-staking.md @@ -8,7 +8,7 @@ sidebar_label: Storage Staking > > In storage staking (sometimes called _state_ staking), the account that owns a smart contract must stake (or lock) tokens according to the amount of data stored in that smart contract, effectively reducing the balance of the contract's account. -
+
Coming from Ethereum?

If you’re familiar with Ethereum’s pricing model, you may know that, like NEAR, the protocol charges a fee (called "gas") for each transaction. Unlike NEAR, Ethereum's gas fee accounts for the amount of data stored via that transaction. This essentially means that anyone can pay once to store permanent data on-chain. This is a poor economic design for at least two reasons: 1. The people running the network (miners, in the case of Ethereum 1) are not appropriately incentivized to store large amounts of data, since a gas fee far charged in the distant past can increase storage costs forever, and 2. The users of a smart contract are charged for the data they send to store in it, rather than charging the owner of the smart contract. diff --git a/docs/2.develop/contracts/actions.md b/docs/2.develop/contracts/actions.md index e0b0a99f259..c60eaa2336f 100644 --- a/docs/2.develop/contracts/actions.md +++ b/docs/2.develop/contracts/actions.md @@ -232,7 +232,7 @@ Sub-accounts are simply useful for organizing your accounts (e.g. `dao.project.n When you create an account from within a contract, it has no keys by default. If you don't explicitly [add keys](#add-keys) to it or [deploy a contract](#deploy-a-contract) on creation then it will be [locked](../../1.concepts/basics/accounts/access-keys.md#locked-accounts). ::: -
+
#### Creating Other Accounts Accounts can only create immediate sub-accounts of themselves. diff --git a/docs/2.develop/contracts/anatomy.md b/docs/2.develop/contracts/anatomy.md index 624782d0cae..9478161a38e 100644 --- a/docs/2.develop/contracts/anatomy.md +++ b/docs/2.develop/contracts/anatomy.md @@ -36,7 +36,7 @@ Under the hood, the `NEAR Bindgen` decorator/macro traverses the class, generati 2. Expose public methods, so they can be called externally. 3. Serialize objects for internal storage and communication with external actors. -
+
### The State Each account has its own state (storage), which **only they can modify** but [anyone can see](../../4.tools/cli.md#near-view-state-near-view-state). @@ -66,7 +66,7 @@ There are two ways to initialize the account's state, and they can co-exist: 2. A **default state**, which will be used until `init` is invoked, or a method writes into the state -
+
### Initialization Method To define an initialization method simply decorate it with the [initialization macro](#decorators--macros). @@ -106,7 +106,7 @@ To make the initialization mandatory use `#[derive(PanicOnDefault)]` in the cont -
+
### Default State Contracts can define a **default state** to use if no initialize method is called. This is, if any method is invoked @@ -189,7 +189,7 @@ All the **public methods** are exposed to the network as the contract's interfac -
+
### Public Methods Public methods can be categorized in three types: `init` methods, `view` methods, and `call` methods. @@ -209,7 +209,7 @@ as `call` methods. By default `init` methods are public, make sure to [decorate them as `private`](#private-methods), or [batch call the initialization on deploy](../deploy.md#initializing-the-contract) ::: -
+
### Private Methods Sometimes you will want some methods to remain public, but only be callable by the contract's @@ -240,7 +240,7 @@ For this, you can use the `private` macro/decorator. -
+
### Payable Methods By default **all methods panic** if a user **attaches money** while calling them. To enable a @@ -269,7 +269,7 @@ method to receive money use the payable decorator. -
+
### Input & Return Types diff --git a/docs/2.develop/contracts/serialization.md b/docs/2.develop/contracts/serialization.md index bf62743df40..a5b71603de5 100644 --- a/docs/2.develop/contracts/serialization.md +++ b/docs/2.develop/contracts/serialization.md @@ -22,7 +22,7 @@ This process of translating **complex objects into simpler single-value** repres Lets give a quick overview of both serialization formats, including their pros and cons, as well as an example on how their serializations look like. -
+
### [JSON](https://www.json.org/json-en.html): Objects to Strings @@ -43,7 +43,7 @@ Example{ "{\"number\": 2, \"arr\": [0, 1]}" ``` -
+
### [Borsh](https://borsh.io/): Objects to Bytes @@ -232,7 +232,7 @@ the vector now has 2 elements. At the same time, a new key-value was added adding the new vector entry: the `1u8` we just added. -
+
diff --git a/docs/2.develop/contracts/storage.md b/docs/2.develop/contracts/storage.md index c8882241196..833b1359e5e 100644 --- a/docs/2.develop/contracts/storage.md +++ b/docs/2.develop/contracts/storage.md @@ -54,7 +54,7 @@ in the [serialized state](./serialization.md#borsh-state-serialization) ::: -
+
### Vector @@ -74,7 +74,7 @@ Implements a [vector/array](https://en.wikipedia.org/wiki/Array_data_structure) -
+
### Map @@ -134,7 +134,7 @@ class StatusMessage { } ```
-
+
### Set @@ -154,7 +154,7 @@ Implements a [set](https://en.wikipedia.org/wiki/Set_(abstract_data_type)) which -
+
### Tree diff --git a/docs/2.develop/deploy.md b/docs/2.develop/deploy.md index cec45da93d1..b8ad53515a2 100644 --- a/docs/2.develop/deploy.md +++ b/docs/2.develop/deploy.md @@ -129,7 +129,7 @@ You can initialize your contract [during deployment](#deploying-the-contract) us ## Calling the Contract Once your contract is deployed you can interact with it right away using [NEAR CLI](../4.tools/cli.md). -
+
### View methods View methods are those that perform **read-only** operations. Calling these methods is free, and do not require to specify which account is being used to make the call: @@ -154,7 +154,7 @@ View methods are those that perform **read-only** operations. Calling these meth View methods have by default 200 TGAS for execution ::: -
+
### Change methods Change methods are those that perform both read and write operations. For these methods we do need to specify the account being used to make the call, diff --git a/docs/2.develop/integrate/frontend.md b/docs/2.develop/integrate/frontend.md index 02f6082bfe9..acd3897f827 100644 --- a/docs/2.develop/integrate/frontend.md +++ b/docs/2.develop/integrate/frontend.md @@ -169,7 +169,7 @@ Signing in is as simple as requesting the `wallet` object to `signIn`, the same When the user clicks in the button, it will be asked to select a wallet and use it to login. -
+
### Function Call Key @@ -220,7 +220,7 @@ Remember that you can use the `wallet` to call methods in **any** contract. If y ::: -
+
### Wallet Redirection diff --git a/docs/2.develop/integrate/quickstart.md b/docs/2.develop/integrate/quickstart.md index 81c45587c1f..6a721b05870 100644 --- a/docs/2.develop/integrate/quickstart.md +++ b/docs/2.develop/integrate/quickstart.md @@ -62,7 +62,7 @@ Once the app starts you will see the landing page, rendering a navigation bar th Go ahead and sign in with your NEAR account. If you don't have one, you can create one on the fly. -
+
### Under the Hood @@ -82,7 +82,7 @@ The wallet selector is a component that allows users to select their preferred N
-
+
### Navigation Bar & Login The navigation bar implements buttons to `login` and `logout` users with their Near wallet. @@ -102,7 +102,7 @@ Now that you understand how the landing page works, we can move to the `Near Int Login if you haven't done it yet and you will see a simple form that allows you to store a greeting in the smart contract. -
+
### Under the Hood Interactions with NEAR are done using the `useWallet` hook to retrieve both the `viewMethod` and `callMethod` methods and the `signedAccountId` property from the `wallet selector`. @@ -134,7 +134,7 @@ To interact with the Ethereum components (a Lido) you will need to have Metamask While the component's code is stored in the **Near testnet**, the Lido component is connected to the **Ethereum mainnet**. ::: -
+
### Under the Hood @@ -157,8 +157,6 @@ Particularly, the `Component` in the main page are wrappers around the `Widget` That's it for our quickstart tutorial. You have now seen a fully functional frontend that can talk with NEAR contracts and render Web3 components. - - If you have any questions, do not hesitate in joining us on [Discord](https://near.chat). We regularly host Office Hours, in which you can join our voice channel and ask questions. Happy coding! diff --git a/docs/2.develop/integrate/welcome.md b/docs/2.develop/integrate/welcome.md index bfd87dc8adf..3370a616142 100644 --- a/docs/2.develop/integrate/welcome.md +++ b/docs/2.develop/integrate/welcome.md @@ -10,54 +10,54 @@ import ContactUs from '@site/src/components/ContactUs.mdx'; Welcome! Here you will find documentation on how to build Web3 applications using NEAR. What are you planning to build? -
-
-
+
+
+
-
-
+ -
+
-
-
+ -
+
-
-
+ -
+
-
-
+
+
Learn
-
+

Backend Integration

Use NEAR in your server.
diff --git a/docs/2.develop/relevant-contracts/dao.md b/docs/2.develop/relevant-contracts/dao.md index 0ef0880234b..045c768185c 100644 --- a/docs/2.develop/relevant-contracts/dao.md +++ b/docs/2.develop/relevant-contracts/dao.md @@ -52,7 +52,7 @@ When the vote policy is `RoleWeight(role)`, the vote weigh is computed as "one o Both voting policies further include a "threshold" for passing a proposal, which can be a ratio or a fixed number. The ratio indicates that you need a proportion of people/tokens to approve the proposal (e.g. half the people need to vote, and to vote positively). A fixed number indicated that you need a specific number of votes/tokens to pass the proposal (e.g. 3 people/tokens are enough to approve the proposal). -
+
## Adding a Proposal By default, anyone can add a proposal to the DAO, but a minimum of 1Ⓝ needs to be attached as a bond. This however can be changed by [setting roles in the DAO](https://github.com/near-daos/sputnik-dao-contract#roles-and-permissions). The type of proposals that can be added [is predefined](https://github.com/near-daos/sputnik-dao-contract#proposal-types), and include actions such as: @@ -77,7 +77,7 @@ Each action has its own kind of arguments. The complete list of actions can be [ -
+
## Acting on a Proposal Once a proposal is added, **council members** can act on them calling the `act_proposal` method. The available actions are one of the following: AddProposal, RemoveProposal, VoteApprove, VoteReject, VoteRemove, Finalize, or MoveToHub. diff --git a/docs/2.develop/relevant-contracts/ft.md b/docs/2.develop/relevant-contracts/ft.md index 5180d407d4f..d8aecbe5f7c 100644 --- a/docs/2.develop/relevant-contracts/ft.md +++ b/docs/2.develop/relevant-contracts/ft.md @@ -41,7 +41,7 @@ Creating a new FT is as simple as deploying a new FT contract and initializing i On initialization you will define an **owner**, who will own **ALL** the tokens. ::: -
+
## Querying Metadata You can query the FT's metadata by calling the `ft_metadata`. @@ -56,7 +56,7 @@ You can query the FT's metadata by calling the `ft_metadata`. -
+
## Registering a User In order for a user to own and transfer tokens they need to first **register** in the contract. This is done by calling `storage_deposit` and attaching 0.00125Ⓝ. This method also allows to pay for other users to register them. @@ -80,7 +80,7 @@ You can make sure a user is registered by asserting they have a `storage_balance After you call the `storage_deposit` the FT will appear in the NEAR WALLET. ::: -
+
## Getting Balance To know how many coins a user has you will need to query the method `ft_balance_of`. @@ -99,7 +99,7 @@ To know how many coins a user has you will need to query the method `ft_balance_ Keep in mind the `decimals` from the [metadata](#query-metadata). A balance of `150 FT` for a token with 2 `decimals` actually represents `1.50 FT`. ::: -
+
## Transferring To send FT to another account you will use the `ft_transfer` method, indicating the receiver and the amount of FT you want to send. @@ -122,7 +122,7 @@ Implement [events](https://nomicon.io/Standards/Tokens/FungibleToken/Event) to b In order to send a fungible token to an account, both the sender and receiver must be [registered](#register-a-user) in the FT contract. ::: -
+
## Attaching FTs to a Call Natively, only NEAR tokens (Ⓝ) can be attached to a method calls. However, the FT standard enables to attach fungible tokens in a call by using the FT-contract as intermediary. This means that, instead of you attaching tokens directly to the call, you ask the FT-contract to do both a transfer and a method call in your name. @@ -154,7 +154,7 @@ From the workflow above it follows that the receiver we want to call needs to im The `ft_on_transfer` **must** return **how many FT tokens have to be refunded**, so the FT contract gives them back to the sender. -
+
## Events You can track real time events (such as transfers) by implementing the [FT Event Standards](https://nomicon.io/Standards/Tokens/FungibleToken/Event). diff --git a/docs/2.develop/relevant-contracts/nft.md b/docs/2.develop/relevant-contracts/nft.md index 6821d1282db..dc6e5955faa 100644 --- a/docs/2.develop/relevant-contracts/nft.md +++ b/docs/2.develop/relevant-contracts/nft.md @@ -54,7 +54,7 @@ Implement [events](https://nomicon.io/Standards/Tokens/NonFungibleToken/Event) t ::: -
+
## Querying Metadata You can query the NFT's metadata by calling the `nft_metadata`. @@ -69,7 +69,7 @@ You can query the NFT's metadata by calling the `nft_metadata`. -
+
## Approving Users You can authorize other users to transfer an NFT you own. This is useful, for example, to enable listing your NFT in a marketplace. In such scenario, you **trust** that the marketplace will only transfer the NFT upon receiving a certain amount of money in exchange. @@ -94,7 +94,7 @@ If the `msg` parameter is included, then a cross-contract call will be made to ` ::: -
+
## Transferring an NFT Transferring an NFT can happen in two scenarios: (1) you ask to transfer an NFT, and (2) an authorized account asks to transfer the NFT. In both cases, it is necessary to invoke the `nft_transfer` method, indicating the token id, the receiver, and an (optionally) an [approval_id](https://nomicon.io/Standards/Tokens/NonFungibleToken/ApprovalManagement). @@ -113,7 +113,7 @@ Transferring an NFT can happen in two scenarios: (1) you ask to transfer an NFT, Implement [events](https://nomicon.io/Standards/Tokens/NonFungibleToken/Event) to be able to [track NFT transfers in real time](../../4.tools/events.md). ::: -
+
## Attaching NFTs to a Call Natively, only NEAR tokens (Ⓝ) can be attached to a method calls. However, the NFT standard enables to attach a non-fungible tokens in a call by using the NFT-contract as intermediary. This means that, instead of you attaching tokens directly to the call, you ask the NFT-contract to do both a transfer and a method call in your name. @@ -149,7 +149,7 @@ From the workflow above it follows that the receiver we want to call needs to im The `nft_on_transfer` **must return true** if the NFT has to be **returned to the sender**. -
+
## Events You can track real time events (such as transfers) by implementing the [NFT Event Standards](https://nomicon.io/Standards/Tokens/NonFungibleToken/Event). diff --git a/docs/2.develop/testing/integration.md b/docs/2.develop/testing/integration.md index 1f394229498..8a1baa206f0 100644 --- a/docs/2.develop/testing/integration.md +++ b/docs/2.develop/testing/integration.md @@ -1,6 +1,6 @@ --- id: integration-test -title: Integration Test +title: Integration Tests #sidebar_label: 🥼 Integration Test --- import {CodeTabs, Language, Github} from "@site/src/components/codetabs" @@ -15,10 +15,11 @@ Moreover, when using the local `sandbox` you gain complete control of the networ 2. Simulate errors on callbacks. 3. Control the time-flow and fast-forward into the future (Rust ready, TS coming soon). -### NEAR Workspaces +:::tip NEAR Workspaces In NEAR, integration tests are implemented using a framework called **Workspaces**. Workspaces comes in two flavors: [🦀 Rust](https://github.com/near/workspaces-rs) and [🌐 Typescript](https://github.com/near/workspaces-js). -If you used one of our [examples](https://github.com/near-examples/docs-examples) as template, then integration testing using `workspaces-js` is already implemented, and you simply need to run `yarn test:integration` from the project's root folder. +All of our [examples](https://github.com/near-examples/docs-examples) come with integration testing. +::: --- @@ -26,17 +27,17 @@ If you used one of our [examples](https://github.com/near-examples/docs-examples Lets take a look at the test of our [Quickstart Project](../quickstart.md) [👋 Hello NEAR](https://github.com/near-examples/hello-near-rs), where we deploy the contract on an account and test it correctly retrieves and sets the greeting. - + --- + ## Snippet II: Testing Donations In most cases we will want to test complex methods involving multiple users and money transfers. A perfect example for this is our [Donation Example](https://github.com/near-examples/donation-js), which enables users to `donate` money to a beneficiary. Lets see its integration tests: - - + + ```ts const refFinance = await root.importContract({ @@ -75,7 +76,7 @@ This would copy the Wasm bytes and contract state from [v2.ref-finance.near](htt See a [TypeScript example of spooning](https://github.com/near/workspaces-js/blob/main/__tests__/05.spoon-contract-to-sandbox.ava.ts) contracts. - + Specify the contract name from `testnet` you want to be pulling, and a specific block ID referencing back to a specific time. (Just in case the contract you're referencing has been changed or updated) @@ -135,8 +136,8 @@ You can alter contract code, accounts, and access keys using normal transactions Keep in mind that you cannot perform arbitrary mutation on contract state with transactions since transactions can only include contract calls that mutate state in a contract-programmed way. For example, with an NFT contract, you can perform some operation with NFTs you have ownership of, but you cannot manipulate NFTs that are owned by other accounts since the smart contract is coded with checks to reject that. This is the expected behavior of the NFT contract. However, you may want to change another person's NFT for a test setup. This is called "arbitrary mutation on contract state" and can be done with `patchState`: - - + + ```js const {contract, ali} = t.context.accounts; @@ -165,7 +166,7 @@ Keep in mind that you cannot perform arbitrary mutation on contract state with t To see a complete example of how to do this, see the [patch-state test](https://github.com/near/workspaces-js/blob/main/__tests__/02.patch-state.ava.ts). - + ```rust // Grab STATE from the testnet status_message contract. This contract contains the following data: @@ -218,17 +219,17 @@ This approach is more complex to do and also cannot be performed without restart ### Time Traveling -`workspaces` testing offers support for forwarding the state of the blockchain to the future. This means contracts which require time sensitive data do not need to sit and wait the same amount of time for blocks on the sandbox to be produced. We can simply just call `worker.fast_forward` to get us further in time: +`workspaces` offers support for forwarding the state of the blockchain to the future. This means contracts which require time sensitive data do not need to sit and wait the same amount of time for blocks on the sandbox to be produced. We can simply just call `worker.fast_forward` to get us further in time: - - + + -:::note -Time Traveling in `workspaces-js` is currently unavailable. -::: + - + ```rust #[tokio::test] @@ -243,12 +244,11 @@ async fn test_contract() -> anyhow::Result<()> { .await?; } ``` +_[See the full example on Github](https://github.com/near/workspaces-rs/blob/main/examples/src/fast_forward.rs)._ -For a full Rust example, take a look at [examples/src/fast_forward.rs](https://github.com/near/workspaces-rs/blob/main/examples/src/fast_forward.rs). - --- ## Using Testnet @@ -270,8 +270,8 @@ You can switch to testnet mode in three ways. 1. When creating Worker set network to `testnet` and pass your master account: - - + + ```ts const worker = await Worker.init({ @@ -281,7 +281,7 @@ const worker = await Worker.init({ ``` - + ```rust #[tokio::main] // or whatever runtime we want @@ -300,8 +300,8 @@ let worker = workspaces::testnet().await?; 2. Set the `NEAR_WORKSPACES_NETWORK` and `TESTNET_MASTER_ACCOUNT_ID` environment variables when running your tests: - - + + ```bash NEAR_WORKSPACES_NETWORK=testnet TESTNET_MASTER_ACCOUNT_ID= node test.js @@ -314,8 +314,8 @@ If you set this environment variables and pass `{network: 'testnet', testnetMast 3. If using `near-workspaces` with AVA, you can use a custom config file. Other test runners allow similar config files; adjust the following instructions for your situation. - - + + Create a file in the same directory as your `package.json` called `ava.testnet.config.cjs` with the following contents: diff --git a/docs/2.develop/testing/workspaces-migration-guide.md b/docs/2.develop/testing/workspaces-migration-guide.md deleted file mode 100644 index d732067528a..00000000000 --- a/docs/2.develop/testing/workspaces-migration-guide.md +++ /dev/null @@ -1,316 +0,0 @@ ---- -id: workspaces-migration -sidebar_label: "Workspaces Migration" -title: "Migrating from Simulation Testing to Workspaces" ---- - -# Migrating from Simulation Testing to Workspaces - -### Why did we stop supporting Simulation Testing? - -Simulation tests were not suitable for purpose for a few reasons, namely: - -- `near-sdk-sim` was hooking into parts of nearcore that were not meant to be released, in the most recent version those crates aren't released so `near-sdk-sim` is currently using duplicate dependencies (maintenance nightmare). -- Not a fully accurate simulation because it just used a subset of the runtime in a specific way - we can't rely on this. And thus couldn't measure gas burnt accurately. Also, all the intricacies of nearcore (like protocol features) wouldn't be one-to-one with the runtime since the runtime was just code built on top of VM logic. People would also need to write their own automation scripts to deploy to testnet, so we'd end up with very split workflows for testing. -- Bulky dependencies pulled in (drastically increases compile time). -- Unergonomic API, not specific to this strategy, but likely would have had to be re-built. -- Can't test parallel transactions easily - current pattern would process blocks until a transaction succeeded but you can't create specific conditions, which is required for a strategy like this that isn't fully simulated. - -:::info -This guide presumes that you are transitioning from near-sdk-sim `3.2.0` (the last non-deprecated release) to `workspaces-rs` `0.2.1`. Given that near-sdk-sim is deprecated, it is very unlikely that its API will ever change, but future releases of `workspaces-rs` might. Hopefully, this guide will be helpful even if you are migrating your project to a more recent workspaces version. If workspaces have changed, feel free to migrate your tests to `0.2.1` first using this guide and upgrade to the most recent workspaces-rs version later by looking at the release notes to see how public API has changed since `0.2.1`. -::: - -## Async Runtime and Error Handling - -In this section we will be working purely with test signatures, so it applies to pretty much all NEAR contract tests regardless of what is written inside. We will walk through each change one by one. Let's start with how your tests look like right now; chances are something like this: - -```rust -#[test] -fn test_transfer() { - ... -} -``` - -First big change is that `workspaces-rs` API is asynchronous, meaning that contract function calls return values that implement `Future` trait. You will not be able to operate on the call results in a synchronous environment, thus you will have to add an async runtime (if you do not already have one). In this guide we are going to be using [`tokio`](https://tokio.rs/), but you should be able to use any other alternative (e.g. [`async-std`](https://async.rs/), [`smol`](https://github.com/smol-rs/smol)). Rewrite the test above like this: - -```rust -#[tokio::test] -async fn test_transfer() { - ... -} -``` - -:::note -If you are using another attribute on top of the standard `#[test]`, make sure it plays nicely with the async runtime of your choosing. For example, if you are using [`test-env-log`](https://crates.io/crates/test-env-log) and `tokio`, then you need to mark your tests with
`#[test_env_log::test(tokio::test)]`. -::: - -The second change is that `workspaces-rs` makes an extensive use of [`anyhow::Result`](https://docs.rs/anyhow/latest/anyhow/type.Result.html). Although you can work with `Result` directly, our recommendation is to make your tests return `anyhow::Result<()>` like this: - -```rust -#[tokio::test] -async fn test_transfer() -> anyhow::Result<()> { - ... -} -``` - -This way you can use `?` anywhere inside the test to safely unpack any `anyhow::Result` type to `R` (will be very useful further down the guide). Note that the test will fail if `anyhow::Result` cannot be unpacked. - -## Initialization and Deploying Contracts - -Unlike NEAR Simulator, `workspaces-rs` uses an actual NEAR node and makes all calls through it. First, you need to decide which network you want your tests to be run on: - -- `sandbox` - perfect choice if you are just interested in local development and testing; `workspaces-rs` will instantiate a [sandbox](https://github.com/near/sandbox) instance on your local machine which will run an isolated NEAR node. -- `testnet` - an environment much closer to the real world; you can test integrations with other deployed contracts on testnet without bearing any financial risk. -- `mainnet` - a network with reduced amount of features due to how dangerous it can be to do transactions there, but can still be useful for automating deployments and pulling deployed contracts. - -In this guide we will be focusing on `sandbox` since it covers the same use cases NEAR Simulator did. But of course feel free to explore whether other networks can be of potential use to you when writing new tests/workflows. - -One of the ways to initialize simulator and deploy a contract is shown below (the other way is through `deploy!` macro which we will look at in the next section): - -```rust title="Deployment - near-sdk-sim" -use near_sdk_sim::{init_simulator, to_yocto}; - -near_sdk_sim::lazy_static_include::lazy_static_include_bytes! { - WASM_BYTES => "res/contract.wasm", -} - -const ID: &str = "contract-id"; - -... - -let root = init_simulator(...); -let contract = root.deploy(&WASM_BYTES, ID.parse().unwrap(), to_yocto("5")); -``` - -Although `workspaces-rs` provides a way to specify the account id for a contract to be deployed, usually it does not matter in the context of a single test. If you are fine with generating a random developer account and initializing it with 100N, then you can replace the snippet above with this: - -```rust title="Deployment - workspaces-rs" -let worker = workspaces::sandbox().await?; -let contract = worker.dev_deploy(include_bytes!("../res/contract.wasm")).await?; -``` - -Alternatively, use this if you care about the account id: - -```rust title="Deployment - workspaces-rs (with explicit account id)" -let worker = workspaces::sandbox().await?; -let (_, sk) = worker.dev_generate().await; -let id: AccountId = "contract-id".parse()?; -let contract = worker - .create_tla_and_deploy( - id, - sk, - include_bytes!("../examples/res/non_fungible_token.wasm"), - ) - .await? - .result; -``` - -:::danger -'dev_deploy' can't supply the initial balance since testnet controls this amount in the helper contract which is what we're using to create dev accounts on testnet. So, to make it simple, we don't supply it at all (sandbox included). It is however possible to create a **subaccount** with a certain balance in sandbox, they can grab the root account and do: - -```rust title="Deployment - workspaces-rs (with initial balance)" -let root = worker.root_acount(); -root.create_subaccount(...) - .initial_balance(...) - ... -``` - -::: - -:::caution -You might have noticed that `init_simulator` used to accept an optional genesis config. Unfortunately, `workspaces-rs` does not support this feature yet, but we are trying to understand the need for this and properly design it. Please feel free to share your use case [here](https://github.com/near/workspaces-rs/issues/68). -::: - -## Making Transactions and View Calls - -As always, let's take a look at how we used to make calls with NEAR Simulator: - -```rust title="Calls - near-sdk-sim" -// Example 1: No Macros -root.call( - ft.account_id(), - "ft_transfer", - &json!({ - "receiver_id": alice.account_id(), - "amount": U128::from(transfer_amount) - }) - .to_string() - .into_bytes(), - 300_000_000_000_000, - 1, -); - -let root_balance: U128 = root.view( - ft.account_id(), - "ft_balance_of", - &json!({ - "account_id": root.account_id() - }) - .to_string() - .into_bytes(), -) -.unwrap_json(); - -// Example 2: With Macros -call!( - root, - ft.ft_transfer(alice.account_id(), transfer_amount.into(), None), - deposit = 1 - gas = 300_000_000_000_000 -); - -let root_balance: U128 = view!(ft.ft_balance_of(root.account_id())).unwrap_json(); -``` - -Note how Example 2's `call!` and `view!` macros accept a contract function invocation as if it was just regular Rust. Unlike NEAR Simulator, `workspaces-rs` never stores metadata about the deployed contract and hence does not support high-level syntax like that. This might change in the future once our ACI implementation is ready, but for the remainder of this section we will be migrating Example 1. - -Workspaces have a unified way of making all types of calls via a [builder](https://doc.rust-lang.org/1.0.0/style/ownership/builders.html) pattern. Generally, calls are constructed by following these steps: - -1. Create a `CallBuilder` by invoking `Contract::call` -2. Pass function call arguments via `CallBuilder::args_json` or `CallBuilder::args_borsh` depending on which serialization algorithm your contract is using -3. Configure gas and deposit (if needed) via `CallBuilder::gas` and `CallBuilder::deposit` -4. Finalize the call by consuming builder via `CallBuilder::transaction` or `CallBuilder::view` depending on what kind of call you want to make - -Reference this migration of Example 1 for migrating your own calls: - -```rust title="Calls - workspaces-rs" -contract - .call(&worker, "ft_transfer") - .args_json((alice.id(), transfer_amount, Option::::None))? - .gas(300_000_000_000_000) - .deposit(ONE_YOCTO) - .transact() - .await?; - -let root_balance: U128 = contract - .call(&worker, "ft_balance_of") - .args_json((contract.id(),))? - .view() - .await? - .json()?; -``` - -:::note -Note that you have to pass arguments as any serializable type representing a sequential list. Tuples are usually the best candidate due to their heterogeneous nature (remember that you can construct a unary tuple by placing a comma before the closing bracket like this: `(el,)`). Passing in an object formatted with the `json!()` macro is also supported. -::: - -### Batch Transactions - -There is a special builder for making batch transactions that can be instantiated by calling `Contract::batch`. Consider the following snippet making a batch transaction consisting of two calls: - -```rust title="Batch Transaction - near-sdk-sim" -let res = root - .create_transaction(contract.account_id()) - .function_call( - "ft_transfer_call".to_string(), - json!({ - "receiver_id": defi_contract.account_id(), - "amount": transfer_amount.to_string(), - "msg": "10", - }) - .to_string() - .into_bytes(), - 300_000_000_000_000 / 2, - 1, - ) - .function_call( - "storage_unregister".to_string(), - json!({ - "force": true - }) - .to_string() - .into_bytes(), - 300_000_000_000_000 / 2, - 1, - ) - .submit(); -``` - -There are no caveats here, the snippet can be straightforwardly mapped into the following: - -```rust title="Batch Transaction - workspace-rs" -let res = contract - .batch(&worker) - .call( - Function::new("ft_transfer_call") - .args_json((defi_contract.id(), transfer_amount, Option::::None, "10"))? - .gas(300_000_000_000_000 / 2) - .deposit(1), - ) - .call( - Function::new("storage_unregister") - .args_json((Some(true),))? - .gas(300_000_000_000_000 / 2) - .deposit(1), - ) - .transact() - .await?; -``` - -## Inspecting Logs - -The API for inspecting logs is fairly close to what it was in NEAR Simulator, but there are still some things you should keep in mind when migrating. Let's take the same transaction we used in the [batch transactions](#batch-transactions) section and try to inspect its logs. This is how one would check that the transaction logged a specific message in a certain position with NEAR Simulator: - -```rust title="Logs - near-sdk-sim" -assert_eq!( - res.logs()[1], - format!("Closed @{} with {}", contract.account_id(), initial_balance - transfer_amount) -); -``` - -The `workspaces-rs` counterpart might seem almost identical at the first look: - -```rust title="Logs - workspaces-rs" -assert_eq!( - res.logs()[1], - format!("Closed @{} with {}", contract.id(), initial_balance.0 - transfer_amount.0) -); -``` - -However, it can actually behave differently depending on your use case, because while near-sdk-sim version only returns the logs from the transaction, the workspaces version returns all logs from both the transaction and receipt outcomes. If you want a literal counterpart, please use `res.outcome().logs`. - -Another common use case is examining receipt outcome logs like this: - -```rust title="Logs - nead-sdk-sim" -let outcome = res.get_receipt_results().remove(5).unwrap(); - -assert_eq!(outcome.logs()[0], "The account of the sender was deleted"); -assert_eq!( - outcome.logs()[2], - format!("Account @{} burned {}", root.account_id(), 10) -); -``` - -Which is straightforwardly replaced with: - -```rust title="Logs - workspaces-rs" -let outcome = &res.receipt_outcomes()[5]; -assert_eq!(outcome.logs[0], "The account of the sender was deleted"); -assert_eq!(outcome.logs[2], format!("Account @{} burned {}", contract.id(), 10)); -``` - -## Profiling Gas - -NEAR Simulator never had accurate gas estimations since it only tried to mirror nearcore, but nearcore has extra functionality on top which consumes gas (like cross-contract calls are processed separately from the same transaction and that incurs gas fees). Workspaces offers the better experience here and aligns very well with what you can do on testnet and mainnet. It provides the added benefit of allowing the developer to accurately profile gas usage before deploying to `mainnet`. - -:::warning -Since `workspaces-rs` is now using accurate gas measurements, some testing flows that were previously being tested with sdk-sim that would depend on gas reports might not work anymore. You should do your due diligence if you plan to deploy to `mainnet`. -::: - -Let's once again return to the [batch transactions](#batch-transactions) example and see how we would estimate gas burnt by a given transaction: - -```rust title="Gas (transaction) - near-sdk-sim" -println!("Burnt gas (transaction): {}", res.gas_burnt()); -``` - -Just like with [inspecting logs](#inspecting-logs), one might mistakenly think that - -```rust title="Gas (all) - workspaces-rs" -println!("Burnt gas (all): {}", res.total_gas_burnt); -``` - -is the corresponding `workspaces-rs` snippet, but `CallExecutionDetails::total_gas_burnt` includes all gas burnt by call execution, including by receipts. This is exposed as a surface level API since it is a much more commonly used concept, but if you do actually want gas burnt by transaction itself you can do it like this: - -```rust title="Gas (transaction) - workspaces-rs" -println!("Burnt gas (transaction): {}", res.outcome().gas_burnt); -``` diff --git a/docs/2.develop/upgrade.md b/docs/2.develop/upgrade.md index 821a2dec4bb..3dcccac8fb3 100644 --- a/docs/2.develop/upgrade.md +++ b/docs/2.develop/upgrade.md @@ -112,7 +112,7 @@ error: `Cannot deserialize the contract state`, in which case you can choose to: 2. Rollback to the previous contract code 3. Add a method to migrate the contract's state -
+
### The Migration Method If you have no option but to migrate the state, then you need to implement a method that: @@ -124,7 +124,7 @@ If you have no option but to migrate the state, then you need to implement a met This is how DAOs [update themselves](https://github.com/near-daos/sputnik-dao-contract/blob/main/sputnikdao2/src/upgrade.rs#L59) ::: -
+
### Example: Guest Book Migration diff --git a/docs/3.tutorials/crosswords/02-beginner/00-overview.md b/docs/3.tutorials/crosswords/02-beginner/00-overview.md index 76dbbca3897..128c867ed16 100644 --- a/docs/3.tutorials/crosswords/02-beginner/00-overview.md +++ b/docs/3.tutorials/crosswords/02-beginner/00-overview.md @@ -15,7 +15,7 @@ Let's give the smart contract the ability to store multiple crosswords and offer
Man holding a book full of crossword puzzles, in his other hand he's holding a piggy bank. Art created by r3v.near -
Art by r3v.near
+
Art by r3v.near

diff --git a/docs/3.tutorials/crosswords/02-beginner/03-actions.md b/docs/3.tutorials/crosswords/02-beginner/03-actions.md index 8d5fa857099..8d4afc0353f 100644 --- a/docs/3.tutorials/crosswords/02-beginner/03-actions.md +++ b/docs/3.tutorials/crosswords/02-beginner/03-actions.md @@ -16,7 +16,7 @@ We're going to introduce a new Action: `Transfer`. In this chapter, we'd like th
Two hands exchanging a coin emblazoned with the NEAR Protocol logo. Art created by qiqi04.near -
Art by qiqi04.near
+
Art by qiqi04.near

@@ -58,7 +58,7 @@ That's the value in yoctoNEAR. This concept is similar to other blockchains. Bit
Depiction of bills of NEAR, coins for partial NEAR, and then a magnifying glass showing a tiny yoctoNEAR next to an ant. Art created by jrbemint.near -
Art by jrbemint.near
+
Art by jrbemint.near
## Adding `Transfer` @@ -96,7 +96,7 @@ Let's cover three commonly-used functions regarding accounts: predecessor, signe
Illustration of Alice sending a transaction to a smart contract named Banana, which does a cross-contract call to the smart contract Cucumber. Art created by yasuoarts.near -
Alice sends a transaction to the contract on banana.near, which does a cross-contract call to cucumber.near.
From the perspective of a contract on cucumber.near, we see a list of the predecessor, signer, and current account.
Art by yasuoarts.near
+
Alice sends a transaction to the contract on banana.near, which does a cross-contract call to cucumber.near.
From the perspective of a contract on cucumber.near, we see a list of the predecessor, signer, and current account.
Art by yasuoarts.near


1. [predecessor account](https://docs.rs/near-sdk/latest/near_sdk/env/fn.predecessor_account_id.html) — `env::predecessor_account_id()` diff --git a/docs/3.tutorials/crosswords/03-intermediate/04-cross-contract-calls.md b/docs/3.tutorials/crosswords/03-intermediate/04-cross-contract-calls.md index 86960e3ea50..b5d6e68d255 100644 --- a/docs/3.tutorials/crosswords/03-intermediate/04-cross-contract-calls.md +++ b/docs/3.tutorials/crosswords/03-intermediate/04-cross-contract-calls.md @@ -54,7 +54,7 @@ Further down in the `submit_solution` method we'll follow our plan by **adding a
Illustration of a carpenter who has created a key. Art by carlcarlkarl.near -
Our smart contract is like this carpenter adding a key to itself.
Art by carlcarlkarl.near
+
Our smart contract is like this carpenter adding a key to itself.
Art by carlcarlkarl.near

diff --git a/docs/3.tutorials/examples/factory.md b/docs/3.tutorials/examples/factory.md index fa51815c2e3..9b326aaf469 100644 --- a/docs/3.tutorials/examples/factory.md +++ b/docs/3.tutorials/examples/factory.md @@ -46,7 +46,7 @@ The [Generic Factory](https://github.com/near-examples/factory-rust/) presents a 1. Make sure you have installed [rust](https://www.rust-lang.org/). 2. Install the [`NEAR CLI`](https://github.com/near/near-cli#setup) -
+
### Build and Deploy the Factory @@ -63,7 +63,7 @@ cat ./neardev/dev-account # e.g. dev-1659899566943-21539992274727 ``` -
+
### Deploy the Stored Contract Into a Sub-Account @@ -81,7 +81,7 @@ near view sub. get_beneficiary # expected response is: ``` -
+
### Update the Stored Contract @@ -108,7 +108,7 @@ near call update_stored_contract "$BYTES" --base64 --accountId Factories are an interesting concept, here we further explain some of their implementation aspects, as well as their limitations. -
+
### Automatically Creating Accounts @@ -124,7 +124,7 @@ This means that the factory: It is important to remember that, while `factory.testnet` can create `sub.factory.testnet`, it has no control over it after its creation. -
+
### The Update Method diff --git a/docs/4.tools/cli.md b/docs/4.tools/cli.md index 6dc83c95202..ea15c040a18 100644 --- a/docs/4.tools/cli.md +++ b/docs/4.tools/cli.md @@ -110,7 +110,7 @@ npm install -g near-cli npm install -g near-cli ``` -
+
heads up

Copy/pasting can be a bit odd using `WSL`. @@ -520,7 +520,7 @@ near delete-key example-acct.testnet Cxg2wgFYrdLTEkMu6j5D6aEZqTb3kXbmJygS48ZKbo1 - arguments: `accountId` `--masterAccount` - options: `--initialBalance` `--publicKey` `--newLedgerKey` -
+
heads up

This command will only allow the creation of [subaccounts](/concepts/basics/accounts/model#subaccounts) of the `--masterAccount`. You can, however, create a [top-level account](/concepts/basics/accounts/model#top-level-accounts) if the length of the account ID is greater than 31 characters. This is most commonly used for [implicit account](/concepts/basics/accounts/model#implicit-accounts) creation. diff --git a/docs/4.tools/explorer.md b/docs/4.tools/explorer.md index 14897990dba..3097e2aae07 100644 --- a/docs/4.tools/explorer.md +++ b/docs/4.tools/explorer.md @@ -23,7 +23,7 @@ Created by NEAR, the [Near Explorer](https://nearblocks.io) enables to check inf ![NEAR Explorer](/docs/assets/explorers/near-explorer.png) *Main page of [NEAR Explorer](https://nearblocks.io)* -
+
## Stats Gallery Created by the community, [Stats Gallery](https://stats.gallery) gamifies the experience of looking to an account, adding levels and badges based on the account's activity. One of its @@ -32,7 +32,7 @@ best features is that it allows you to see the contract's methods. ![Stats Gallery](/docs/assets/explorers/stats-gallery.png) *Account view in [Stats Gallery](https://stats.gallery)* -
+
## NearBlocks @@ -41,7 +41,7 @@ Created by the community, [NearBlocks](https://nearblocks.io/) enables to check ![NearBlocks](/docs/assets/explorers/nearblocks.png) *Main page of [NearBlocks](https://nearblocks.io/)* -
+
## Nearscope @@ -50,7 +50,7 @@ Created by the community, [NearBlocks](https://nearblocks.io/) enables to check ![Nearscope](/docs/assets/explorers/nearscope.png) *Main page of [Nearscope](https://nearscope.net/)* -
+
## DappLooker @@ -60,7 +60,7 @@ Created by the community, [NearBlocks](https://nearblocks.io/) enables to check *Main page of [DappLooker](https://dapplooker.com/)* -
+
## Pikespeak diff --git a/docs/4.tools/indexer4explorer.md b/docs/4.tools/indexer4explorer.md index ddba125baab..9f1d4eb45d1 100644 --- a/docs/4.tools/indexer4explorer.md +++ b/docs/4.tools/indexer4explorer.md @@ -39,7 +39,7 @@ where r.receiver_account_id ='v1.faucet.nonofficial.testnet' and t.transaction_hash = r.originated_from_transaction_hash ``` -
+
### Users, Status, and Attached Money Query for all users that called `contribute` in `v1.faucet.nonofficial.testnet`, how much they attached to the call, and the transaction status. @@ -54,7 +54,7 @@ where r.receiver_account_id ='v1.faucet.nonofficial.testnet' and r.receipt_id = eo.receipt_id ``` -
+
### Sent Money Query for all the transfers going out from `v1.faucet.nonofficial.testnet`. diff --git a/docs/4.tools/near-api-js/naj-account.md b/docs/4.tools/near-api-js/naj-account.md index 158b3c3209b..46f389a73a9 100644 --- a/docs/4.tools/near-api-js/naj-account.md +++ b/docs/4.tools/near-api-js/naj-account.md @@ -14,7 +14,7 @@ This will return an Account object for you to interact with. const account = await nearConnection.account("example-account.testnet"); ``` -[ Class `Account`](https://near.github.io/near-api-js/classes/near_api_js.account.Account.html) +[ Class `Account`](https://near.github.io/near-api-js/classes/near_api_js.account.Account.html) ### Create Account {#create-account} @@ -28,7 +28,7 @@ await account.createAccount( ); ``` -[ Method `Account.createAccount`](https://near.github.io/near-api-js/classes/near_api_js.account.Account.html#createAccount) +[ Method `Account.createAccount`](https://near.github.io/near-api-js/classes/near_api_js.account.Account.html#createAccount) ### Delete Account {#delete-account} @@ -39,7 +39,7 @@ const account = await nearConnection.account("example-account.testnet"); await account.deleteAccount("beneficiary-account.testnet"); ``` -[ Method `Account.deleteAccount`](https://near.github.io/near-api-js/classes/near_api_js.account.Account.html#deleteAccount) +[ Method `Account.deleteAccount`](https://near.github.io/near-api-js/classes/near_api_js.account.Account.html#deleteAccount) ### Get Account Balance {#get-account-balance} @@ -49,7 +49,7 @@ const account = await nearConnection.account("example-account.testnet"); await account.getAccountBalance(); ``` -[ Method `Account.getAccountBalance`](https://near.github.io/near-api-js/classes/near_api_js.account.Account.html#getAccountBalance) +[ Method `Account.getAccountBalance`](https://near.github.io/near-api-js/classes/near_api_js.account.Account.html#getAccountBalance) ### Get Account details {#get-account-details} @@ -61,7 +61,7 @@ const account = await nearConnection.account("example-account.testnet"); await account.getAccountDetails(); ``` -[ Method `Account.getAccountDetails`](https://near.github.io/near-api-js/classes/near_api_js.account.Account.html#getAccountDetails) +[ Method `Account.getAccountDetails`](https://near.github.io/near-api-js/classes/near_api_js.account.Account.html#getAccountDetails) ### Deploy a Contract {#deploy-a-contract} @@ -74,9 +74,9 @@ const transactionOutcome = await account.deployContract( ); ``` -[ Method `Account.deployContract`](https://near.github.io/near-api-js/classes/near_api_js.account.Account.html#deployContract) +[ Method `Account.deployContract`](https://near.github.io/near-api-js/classes/near_api_js.account.Account.html#deployContract)     -[ Interface `FinalExecutionOutcome`](https://near.github.io/near-api-js/interfaces/_near_js_types.provider_response.FinalExecutionOutcome.html) +[ Interface `FinalExecutionOutcome`](https://near.github.io/near-api-js/interfaces/_near_js_types.provider_response.FinalExecutionOutcome.html) ### Send Tokens {#send-tokens} @@ -90,9 +90,9 @@ await account.sendMoney( ); ``` -[ Method `Account.sendMoney`](https://near.github.io/near-api-js/classes/near_api_js.account.Account.html#sendMoney) +[ Method `Account.sendMoney`](https://near.github.io/near-api-js/classes/near_api_js.account.Account.html#sendMoney)     -[ Interface `FinalExecutionOutcome`](https://near.github.io/near-api-js/interfaces/_near_js_types.provider_response.FinalExecutionOutcome.html) +[ Interface `FinalExecutionOutcome`](https://near.github.io/near-api-js/interfaces/_near_js_types.provider_response.FinalExecutionOutcome.html) ### State {#state} @@ -103,9 +103,9 @@ const account = await nearConnection.account("example-account.testnet"); const accountState = await account.state(); ``` -[ Method `Account.state`](https://near.github.io/near-api-js/classes/near_api_js.account.Account.html#state) +[ Method `Account.state`](https://near.github.io/near-api-js/classes/near_api_js.account.Account.html#state)     -[ Interface `AccountView`](https://near.github.io/near-api-js/interfaces/near_api_js.providers_provider.AccountView.html) +[ Interface `AccountView`](https://near.github.io/near-api-js/interfaces/near_api_js.providers_provider.AccountView.html) ### Access Keys {#access-keys} @@ -119,7 +119,7 @@ const account = await nearConnection.account("example-account.testnet"); await account.addKey("8hSHprDq2StXwMtNd43wDTXQYsjXcD4MJTXQYsjXcc"); ``` -[ Method `Account.addKey`](https://near.github.io/near-api-js/classes/near_api_js.account.Account.html#addKey) +[ Method `Account.addKey`](https://near.github.io/near-api-js/classes/near_api_js.account.Account.html#addKey) #### Add Function Access Key {#add-function-access-key} @@ -133,7 +133,7 @@ await account.addKey( ); ``` -[ Method `Account.addKey`](https://near.github.io/near-api-js/classes/near_api_js.account.Account.html#addKey) +[ Method `Account.addKey`](https://near.github.io/near-api-js/classes/near_api_js.account.Account.html#addKey) #### Get All Access Keys {#get-all-access-keys} @@ -142,9 +142,9 @@ const account = await nearConnection.account("example-account.testnet"); await account.getAccessKeys(); ``` -[ Method `Account.getAccessKeys`](https://near.github.io/near-api-js/classes/near_api_js.account.Account.html#getAccessKeys) +[ Method `Account.getAccessKeys`](https://near.github.io/near-api-js/classes/near_api_js.account.Account.html#getAccessKeys)     -[ Interface `AccessKeyInfoView`](https://near.github.io/near-api-js/interfaces/near_api_js.providers_provider.AccessKeyInfoView.html) +[ Interface `AccessKeyInfoView`](https://near.github.io/near-api-js/interfaces/near_api_js.providers_provider.AccessKeyInfoView.html) #### Delete Access Key {#delete-access-key} @@ -153,4 +153,4 @@ const account = await nearConnection.account("example-account.testnet"); await account.deleteKey("8hSHprDq2StXwMtNd43wDTXQYsjXcD4MJTXQYsjXcc"); ``` -[ Method `Account.deleteKey`](https://near.github.io/near-api-js/classes/near_api_js.account.Account.html#deleteKey) +[ Method `Account.deleteKey`](https://near.github.io/near-api-js/classes/near_api_js.account.Account.html#deleteKey) diff --git a/docs/4.tools/near-api-js/naj-contract.md b/docs/4.tools/near-api-js/naj-contract.md index 51a62648be1..8ea1fc4f39f 100644 --- a/docs/4.tools/near-api-js/naj-contract.md +++ b/docs/4.tools/near-api-js/naj-contract.md @@ -38,7 +38,7 @@ const contract = new Contract( ); ``` -[ Class `Contract`](https://near.github.io/near-api-js/classes/_near_js_accounts.contract.Contract.html) +[ Class `Contract`](https://near.github.io/near-api-js/classes/_near_js_accounts.contract.Contract.html) @@ -57,7 +57,7 @@ const contract = new Contract( ); ``` -[ Class `Contract`](https://near.github.io/near-api-js/classes/_near_js_accounts.contract.Contract.html) +[ Class `Contract`](https://near.github.io/near-api-js/classes/_near_js_accounts.contract.Contract.html) @@ -121,7 +121,7 @@ const response = await contract.view_method_name({ arg_name: "arg_value" }); -[ Class `Contract`](https://near.github.io/near-api-js/classes/_near_js_accounts.contract.Contract.html) +[ Class `Contract`](https://near.github.io/near-api-js/classes/_near_js_accounts.contract.Contract.html) [//]: # "## Transactions {#transactions}" [//]: # "A [Transaction](/concepts/basics/transactions/overview) is a collection of Actions, and there are few types of Actions." diff --git a/docs/4.tools/near-api-js/naj-utils.md b/docs/4.tools/near-api-js/naj-utils.md index 2fe98b17965..e20f3a95177 100644 --- a/docs/4.tools/near-api-js/naj-utils.md +++ b/docs/4.tools/near-api-js/naj-utils.md @@ -13,7 +13,7 @@ const { utils } = nearAPI; const amountInYocto = utils.format.parseNearAmount("1"); ``` -[ Function `parseNearAmount`](https://near.github.io/near-api-js/functions/_near_js_utils.format.parseNearAmount.html) +[ Function `parseNearAmount`](https://near.github.io/near-api-js/functions/_near_js_utils.format.parseNearAmount.html) ### YoctoNEAR => NEAR {#yoctonear--near} @@ -24,4 +24,4 @@ const { utils } = nearAPI; const amountInNEAR = utils.format.formatNearAmount("1000000000000000000000000"); ``` -[ Function `formatNearAmount`](https://near.github.io/near-api-js/functions/_near_js_utils.format.formatNearAmount.html) +[ Function `formatNearAmount`](https://near.github.io/near-api-js/functions/_near_js_utils.format.formatNearAmount.html) diff --git a/docs/4.tools/near-api-js/naj-wallet.md b/docs/4.tools/near-api-js/naj-wallet.md index a7d16c9b3f3..7c15a33574a 100644 --- a/docs/4.tools/near-api-js/naj-wallet.md +++ b/docs/4.tools/near-api-js/naj-wallet.md @@ -66,9 +66,9 @@ const walletConnection = new WalletConnection(nearConnection); -[ Module `browserConnect`](https://near.github.io/near-api-js/modules/near_api_js.browserConnect.html) +[ Module `browserConnect`](https://near.github.io/near-api-js/modules/near_api_js.browserConnect.html)     -[ Class `WalletConnection`](https://near.github.io/near-api-js/classes/_near_js_wallet_account.walletAccount.WalletConnection.html) +[ Class `WalletConnection`](https://near.github.io/near-api-js/classes/_near_js_wallet_account.walletAccount.WalletConnection.html) ### Ask your user to Sign In {#sign-in} @@ -90,7 +90,7 @@ walletConnection.requestSignIn({ }); ``` -[ Method `WalletConnection.requestSignIn`](https://near.github.io/near-api-js/classes/_near_js_wallet_account.walletAccount.WalletConnection.html#requestSignIn) +[ Method `WalletConnection.requestSignIn`](https://near.github.io/near-api-js/classes/_near_js_wallet_account.walletAccount.WalletConnection.html#requestSignIn) :::tip Sign In is **_not required_** if you are using an alternative key store to local storage, or you are not signing transactions (meaning - you are only calling read-only _view_ methods on a contract) @@ -103,7 +103,7 @@ Sign In is **_not required_** if you are using an alternative key store to local walletConnection.signOut(); ``` -[ Method `WalletConnection.signOut`](https://near.github.io/near-api-js/classes/_near_js_wallet_account.walletAccount.WalletConnection.html#signOut) +[ Method `WalletConnection.signOut`](https://near.github.io/near-api-js/classes/_near_js_wallet_account.walletAccount.WalletConnection.html#signOut) ### Check if Signed In {#check-if-signed-in} @@ -114,7 +114,7 @@ if (walletConnection.isSignedIn()) { } ``` -[ Method `WalletConnection.isSignedId`](https://near.github.io/near-api-js/classes/_near_js_wallet_account.walletAccount.WalletConnection.html#isSignedIn) +[ Method `WalletConnection.isSignedId`](https://near.github.io/near-api-js/classes/_near_js_wallet_account.walletAccount.WalletConnection.html#isSignedIn) ### Get Wallet Account {#get-authorized-account} @@ -127,7 +127,7 @@ Get the [Account](naj-account.md) your user has signed in with in the Wallet. const walletAccountId = walletConnection.getAccountId(); ``` -[ Method `WalletConnection.getAccountId`](https://near.github.io/near-api-js/classes/_near_js_wallet_account.walletAccount.WalletConnection.html#getAccountId) +[ Method `WalletConnection.getAccountId`](https://near.github.io/near-api-js/classes/_near_js_wallet_account.walletAccount.WalletConnection.html#getAccountId) #### Get Account Object {#get-authorized-account-object} @@ -136,6 +136,6 @@ const walletAccountId = walletConnection.getAccountId(); const walletAccountObj = walletConnection.account(); ``` -[ Method `WalletConnection.account`](https://near.github.io/near-api-js/classes/_near_js_wallet_account.walletAccount.WalletConnection.html#account) +[ Method `WalletConnection.account`](https://near.github.io/near-api-js/classes/_near_js_wallet_account.walletAccount.WalletConnection.html#account)     -[ Class `ConnectedWalletAccount`](https://near.github.io/near-api-js/classes/_near_js_wallet_account.walletAccount.ConnectedWalletAccount.html) +[ Class `ConnectedWalletAccount`](https://near.github.io/near-api-js/classes/_near_js_wallet_account.walletAccount.ConnectedWalletAccount.html) diff --git a/docs/4.tools/near-api-js/quick-reference.md b/docs/4.tools/near-api-js/quick-reference.md index 1079aff3c70..5e3924928d0 100644 --- a/docs/4.tools/near-api-js/quick-reference.md +++ b/docs/4.tools/near-api-js/quick-reference.md @@ -90,7 +90,7 @@ const { keyStores } = nearAPI; const myKeyStore = new keyStores.BrowserLocalStorageKeyStore(); ``` -[ Class `BrowserLocalStorageKeyStore`](https://near.github.io/near-api-js/classes/_near_js_keystores_browser.browser_local_storage_key_store.BrowserLocalStorageKeyStore.html) +[ Class `BrowserLocalStorageKeyStore`](https://near.github.io/near-api-js/classes/_near_js_keystores_browser.browser_local_storage_key_store.BrowserLocalStorageKeyStore.html) @@ -107,7 +107,7 @@ const credentialsPath = require("path").join(homedir, CREDENTIALS_DIR); const myKeyStore = new keyStores.UnencryptedFileSystemKeyStore(credentialsPath); ``` -[ Class `UnencryptedFileSystemKeyStore`](https://near.github.io/near-api-js/classes/_near_js_keystores_node.unencrypted_file_system_keystore.UnencryptedFileSystemKeyStore.html) +[ Class `UnencryptedFileSystemKeyStore`](https://near.github.io/near-api-js/classes/_near_js_keystores_node.unencrypted_file_system_keystore.UnencryptedFileSystemKeyStore.html) @@ -134,9 +134,9 @@ myKeyStore.setKey( ); ``` -[ Class `InMemoryKeyStore`](https://near.github.io/near-api-js/classes/_near_js_keystores.in_memory_key_store.InMemoryKeyStore.html) +[ Class `InMemoryKeyStore`](https://near.github.io/near-api-js/classes/_near_js_keystores.in_memory_key_store.InMemoryKeyStore.html)     -[ Class `KeyPair`](https://near.github.io/near-api-js/classes/_near_js_crypto.key_pair.KeyPair.html) +[ Class `KeyPair`](https://near.github.io/near-api-js/classes/_near_js_crypto.key_pair.KeyPair.html) @@ -155,9 +155,9 @@ const keyPair = KeyPair.fromString(PRIVATE_KEY); await myKeyStore.setKey("testnet", "example-account.testnet", keyPair); ``` -[ Class `InMemoryKeyStore`](https://near.github.io/near-api-js/classes/_near_js_keystores.in_memory_key_store.InMemoryKeyStore.html) +[ Class `InMemoryKeyStore`](https://near.github.io/near-api-js/classes/_near_js_keystores.in_memory_key_store.InMemoryKeyStore.html)     -[ Class `KeyPair`](https://near.github.io/near-api-js/classes/_near_js_crypto.key_pair.KeyPair.html) +[ Class `KeyPair`](https://near.github.io/near-api-js/classes/_near_js_crypto.key_pair.KeyPair.html) @@ -218,4 +218,4 @@ const nearConnection = await connect(connectionConfig); -[ Module `connect`](https://near.github.io/near-api-js/modules/near_api_js.connect.html) +[ Module `connect`](https://near.github.io/near-api-js/modules/near_api_js.connect.html) diff --git a/docs/4.tools/welcome.md b/docs/4.tools/welcome.md index dd8c55b70b8..bea37b936c5 100644 --- a/docs/4.tools/welcome.md +++ b/docs/4.tools/welcome.md @@ -16,6 +16,6 @@ In this page you will find: 5. Developer tools to deploy and interact with contracts such as the [NEAR CLI](cli.md) and [NEAR JavaScript API](/tools/near-api-js/quick-reference). -
+
diff --git a/docs/5.api/rpc/access-keys.md b/docs/5.api/rpc/access-keys.md index 63a241885d7..fb26d4b7552 100644 --- a/docs/5.api/rpc/access-keys.md +++ b/docs/5.api/rpc/access-keys.md @@ -124,7 +124,7 @@ When API request fails, RPC server returns a structured error response with a li Here is the exhaustive list of the error variants that can be returned by `view_access_key` request type: - +
- + @@ -440,7 +440,7 @@ When API request fails, RPC server returns a structured error response with a li Here is the exhaustive list of the error variants that can be returned by `view_access_key_list` request type: -
@@ -196,7 +196,7 @@ Here is the exhaustive list of the error variants that can be returned by `view_
REQUEST_VALIDATION_ERROR PARSE_ERROR Passed arguments can't be parsed by JSON RPC server (missing arguments, wrong format, etc.)
+
- + @@ -661,7 +661,7 @@ When API request fails, RPC server returns a structured error response with a li Here is the exhaustive list of the error variants that can be returned by `EXPERIMENTAL_changes_in_block` method: -
@@ -502,7 +502,7 @@ Here is the exhaustive list of the error variants that can be returned by `view_
REQUEST_VALIDATION_ERROR PARSE_ERROR Passed arguments can't be parsed by JSON RPC server (missing arguments, wrong format, etc.)
+
- + @@ -854,7 +854,7 @@ When API request fails, RPC server returns a structured error response with a li Here is the exhaustive list of the error variants that can be returned by `EXPERIMENTAL_changes` method: -
@@ -695,7 +695,7 @@ Here is the exhaustive list of the error variants that can be returned by `EXPER
REQUEST_VALIDATION_ERROR PARSE_ERROR Passed arguments can't be parsed by JSON RPC server (missing arguments, wrong format, etc.)
+
- + diff --git a/docs/5.api/rpc/block-chunk.md b/docs/5.api/rpc/block-chunk.md index 7853d324dd8..4796e434007 100644 --- a/docs/5.api/rpc/block-chunk.md +++ b/docs/5.api/rpc/block-chunk.md @@ -275,7 +275,7 @@ When API request fails, RPC server returns a structured error response with a li Here is the exhaustive list of the error variants that can be returned by `block` method: -
@@ -888,7 +888,7 @@ Here is the exhaustive list of the error variants that can be returned by `EXPER
REQUEST_VALIDATION_ERROR PARSE_ERROR Passed arguments can't be parsed by JSON RPC server (missing arguments, wrong format, etc.)
+
- + @@ -524,7 +524,7 @@ When API request fails, RPC server returns a structured error response with a li Here is the exhaustive list of the error variants that can be returned by `EXPERIMENTAL_changes_in_block` method: -
@@ -309,7 +309,7 @@ Here is the exhaustive list of the error variants that can be returned by `block
REQUEST_VALIDATION_ERROR PARSE_ERROR Passed arguments can't be parsed by JSON RPC server (missing arguments, wrong format, etc.)
+
- + @@ -729,7 +729,7 @@ When API request fails, RPC server returns a structured error response with a li Here is the exhaustive list of the error variants that can be returned by `chunk` method: -
@@ -558,7 +558,7 @@ Here is the exhaustive list of the error variants that can be returned by `EXPER
REQUEST_VALIDATION_ERROR PARSE_ERROR Passed arguments can't be parsed by JSON RPC server (missing arguments, wrong format, etc.)
+
- + diff --git a/docs/5.api/rpc/contracts.md b/docs/5.api/rpc/contracts.md index f9d908529a6..9cf06c60742 100644 --- a/docs/5.api/rpc/contracts.md +++ b/docs/5.api/rpc/contracts.md @@ -115,7 +115,7 @@ When API request fails, RPC server returns a structured error response with a li Here is the exhaustive list of the error variants that can be returned by `view_account` request type: -
@@ -782,7 +782,7 @@ Here is the exhaustive list of the error variants that can be returned by `chunk
REQUEST_VALIDATION_ERROR PARSE_ERROR Passed arguments can't be parsed by JSON RPC server (missing arguments, wrong format, etc.)
+
- + @@ -336,7 +336,7 @@ When API request fails, RPC server returns a structured error response with a li Here is the exhaustive list of the error variants that can be returned by `EXPERIMENTAL_changes` method: -
@@ -177,7 +177,7 @@ Here is the exhaustive list of the error variants that can be returned by `view_
REQUEST_VALIDATION_ERROR PARSE_ERROR Passed arguments can't be parsed by JSON RPC server (missing arguments, wrong format, etc.)
+
- + @@ -500,7 +500,7 @@ When API request fails, RPC server returns a structured error response with a li Here is the exhaustive list of the error variants that can be returned by `view_code` request type: -
@@ -370,7 +370,7 @@ Here is the exhaustive list of the error variants that can be returned by `EXPER
REQUEST_VALIDATION_ERROR PARSE_ERROR Passed arguments can't be parsed by JSON RPC server (missing arguments, wrong format, etc.)
+
- + @@ -892,7 +892,7 @@ When API request fails, RPC server returns a structured error response with a li Here is the exhaustive list of the error variants that can be returned by `view_state` request type: -
@@ -572,7 +572,7 @@ Here is the exhaustive list of the error variants that can be returned by `view_
REQUEST_VALIDATION_ERROR PARSE_ERROR Passed arguments can't be parsed by JSON RPC server (missing arguments, wrong format, etc.)
+
- + @@ -1131,7 +1131,7 @@ When API request fails, RPC server returns a structured error response with a li Here is the exhaustive list of the error variants that can be returned by `EXPERIMENTAL_changes` method: -
@@ -974,7 +974,7 @@ Here is the exhaustive list of the error variants that can be returned by `view_
REQUEST_VALIDATION_ERROR PARSE_ERROR Passed arguments can't be parsed by JSON RPC server (missing arguments, wrong format, etc.)
+
- + @@ -1305,7 +1305,7 @@ When API request fails, RPC server returns a structured error response with a li Here is the exhaustive list of the error variants that can be returned by `EXPERIMENTAL_changes` method: -
@@ -1165,7 +1165,7 @@ Here is the exhaustive list of the error variants that can be returned by `EXPER
REQUEST_VALIDATION_ERROR PARSE_ERROR Passed arguments can't be parsed by JSON RPC server (missing arguments, wrong format, etc.)
+
- + @@ -1530,7 +1530,7 @@ When API request fails, RPC server returns a structured error response with a li Here is the exhaustive list of the error variants that can be returned by `call_function` request type: -
@@ -1339,7 +1339,7 @@ Here is the exhaustive list of the error variants that can be returned by `EXPER
REQUEST_VALIDATION_ERROR PARSE_ERROR Passed arguments can't be parsed by JSON RPC server (missing arguments, wrong format, etc.)
+
- + diff --git a/docs/5.api/rpc/introduction.md b/docs/5.api/rpc/introduction.md index d1b830bc5e9..c5b7b0f613b 100644 --- a/docs/5.api/rpc/introduction.md +++ b/docs/5.api/rpc/introduction.md @@ -11,13 +11,13 @@ import ContactUs from '@site/src/components/ContactUs.mdx'; The RPC API allows you to communicate directly with the NEAR network. For example, tools such as [near-api-js](/tools/near-api-js/quick-reference) are just abstractions making RPC calls. -
+
## RPC Providers There are multiple [RPC providers which you can choose from](./providers.md). These providers will work as intermediaries to help you interact with the NEAR network. -
+
## NEAR RPC - Quick Links @@ -37,6 +37,6 @@ You can access the JSON RPC 2.0 endpoints using [Postman](/api/rpc/setup#postman [JavaScript](/api/rpc/setup#javascript-setup), and [HTTPie](/api/rpc/setup#httpie-setup). ::: -
+
diff --git a/docs/5.api/rpc/maintenance-windows.md b/docs/5.api/rpc/maintenance-windows.md index 9f228572741..ba1af597404 100644 --- a/docs/5.api/rpc/maintenance-windows.md +++ b/docs/5.api/rpc/maintenance-windows.md @@ -101,7 +101,7 @@ When API request fails, RPC server returns a structured error response with a li Here is the exhaustive list of the error variants that can be returned by `maintenance_windows` method: -
@@ -1611,7 +1611,7 @@ Here is the exhaustive list of the error variants that can be returned by `call_
REQUEST_VALIDATION_ERROR PARSE_ERROR Passed arguments can't be parsed by JSON RPC server (missing arguments, wrong format, etc.)
+
diff --git a/docs/5.api/rpc/setup.md b/docs/5.api/rpc/setup.md index 3b7f049f71c..66c2ffd2cbe 100644 --- a/docs/5.api/rpc/setup.md +++ b/docs/5.api/rpc/setup.md @@ -5,7 +5,7 @@ title: Setup In order to use the RPC API you will need to setup the correct RPC endpoints. -
+
## RPC Endpoint Setup - `POST` for all methods @@ -20,7 +20,7 @@ In order to use the RPC API you will need to setup the correct RPC endpoints. ### Limits - Maximum number of requests per IP: 600 req/min -
+
## Querying Historical Data Querying historical data (older than 5 [epochs](../../1.concepts/basics/epoch.md) or ~2.5 days), you may get responses that the data is not available anymore. In that case, archival RPC nodes will come to your rescue: diff --git a/docs/5.api/rpc/transactions.md b/docs/5.api/rpc/transactions.md index 7d1144b7851..14a7fc30747 100644 --- a/docs/5.api/rpc/transactions.md +++ b/docs/5.api/rpc/transactions.md @@ -90,7 +90,7 @@ When API request fails, RPC server returns a structured error response with a li Here is the exhaustive list of the error variants that can be returned by `broadcast_tx_async` method: - +
- + @@ -264,7 +264,7 @@ When API request fails, RPC server returns a structured error response with a li Here is the exhaustive list of the error variants that can be returned by `broadcast_tx_commit` method: -
@@ -103,7 +103,7 @@ Here is the exhaustive list of the error variants that can be returned by `broad
REQUEST_VALIDATION_ERROR PARSE_ERROR Passed arguments can't be parsed by JSON RPC server (missing arguments, wrong format, etc.)
+
- + @@ -470,7 +470,7 @@ http post https://rpc.testnet.near.org jsonrpc=2.0 id=dontcare method=tx \

-
+
heads up

In the case of function call transactions, this query will not wait for **all** receipts generated by this transaction to finish before returning a result. Rather, it will only wait for its return value to finish before returning; _which could be a promise_. @@ -528,7 +528,7 @@ When API request fails, RPC server returns a structured error response with a li Here is the exhaustive list of the error variants that can be returned by `tx` method: -
@@ -298,7 +298,7 @@ Here is the exhaustive list of the error variants that can be returned by `broad
REQUEST_VALIDATION_ERROR PARSE_ERROR Passed arguments can't be parsed by JSON RPC server (missing arguments, wrong format, etc.)
+
- + @@ -905,7 +905,7 @@ When API request fails, RPC server returns a structured error response with a li Here is the exhaustive list of the error variants that can be returned by `EXPERIMENTAL_tx_status` method: -
@@ -572,7 +572,7 @@ Here is the exhaustive list of the error variants that can be returned by `tx` m
REQUEST_VALIDATION_ERROR PARSE_ERROR Passed arguments can't be parsed by JSON RPC server (missing arguments, wrong format, etc.)
+
- + diff --git a/docs/6.integrator/errors/introduction.md b/docs/6.integrator/errors/introduction.md index 2c6c11763e2..439f015c3d3 100644 --- a/docs/6.integrator/errors/introduction.md +++ b/docs/6.integrator/errors/introduction.md @@ -4,7 +4,7 @@ title: Introduction sidebar_label: Introduction --- -
+
did you know?

The [NEAR Platform overview](/concepts/welcome) clarifies much of the language in this section. diff --git a/docs/7.primitives/dao.md b/docs/7.primitives/dao.md index 96528ee5196..9f31210f3ab 100644 --- a/docs/7.primitives/dao.md +++ b/docs/7.primitives/dao.md @@ -63,7 +63,7 @@ You can also create a DAO by interacting with the `sputnik-dao` contract. -
+
### Voting policy Currently, DAOs support two different types of [voting policies](https://github.com/near-daos/sputnik-dao-contract#voting-policy): `TokenWeight`, and `RoleWeight`. diff --git a/docs/7.primitives/nft.md b/docs/7.primitives/nft.md index 7f430a8abcf..e85a3e0bda4 100644 --- a/docs/7.primitives/nft.md +++ b/docs/7.primitives/nft.md @@ -95,7 +95,7 @@ See the [metadata standard](https://nomicon.io/Standards/Tokens/NonFungibleToken Values of gas and deposit might vary depending on which NFT contract you are calling. ::: -
+
### Minting Collections Many times people want to create multiple 100 copies of an NFT (this is called a collection). In such cases, what you actually need to do is to mint 100 different NFTs with the same metadata (but different `token-id`). @@ -104,7 +104,7 @@ Many times people want to create multiple 100 copies of an NFT (this is called a Notice that [minting in Mintbase](#minting-a-nft) allows you to pass a `num_to_mint` parameter. ::: -
+
### Royalties You might have noticed that one of the parameters is a structure called royalties. Royalties enable you to create a list of users that should get paid when the token is sell in a marketplace. For example, if `anna` has `5%` of royalties, each time the NFT is sell, `anna` should get a 5% of the selling price. @@ -172,7 +172,7 @@ Natively, only NEAR tokens (Ⓝ) can be attached to a method calls. However, the Optionally, a [`memo` parameter](https://nomicon.io/Standards/Tokens/NonFungibleToken/Core#nft-interface) can be passed to provide more information to your contract. ::: -
+
### How Does it Work? Assume you want to attach an NFT (🎫) to a call on the receiver contract. The workflow is as follows: diff --git a/docs/bos/api/near.md b/docs/bos/api/near.md index 3f506c2edc0..1160bade5ad 100644 --- a/docs/bos/api/near.md +++ b/docs/bos/api/near.md @@ -50,7 +50,7 @@ return `The contract says: ${greeting}`; Notice that the optional parameter `subscribe` allows users to subscribe to a query, which automatically refreshes the data every 5 seconds. ::: -
+
#### Avoiding a Common Pitfall diff --git a/docs/bos/api/social.md b/docs/bos/api/social.md index 7568852bbfe..67a76cea906 100644 --- a/docs/bos/api/social.md +++ b/docs/bos/api/social.md @@ -231,7 +231,7 @@ NEAR Social readily provides an indexer - a service that listen to actions in So The indexer is very useful, for example, to rapidly store and retrieve information on all comments for a post. Without the indexer, we would need to check all entries in the contract to see who answered, surely running out of GAS before completion. -
+
### Indexing an Action To index an action we need to add the `index` key to the data being saved, within the `index` key we will save the `action` being indexed, alongside a `key` and a `value` that identifies this specific instance. @@ -301,7 +301,7 @@ To index a like, the standard is to save the action `like`, with `{key: object-r -
+
### Retrieving Indexed Actions diff --git a/docs/bos/api/state.md b/docs/bos/api/state.md index 30e363acef8..8a2e9998d7c 100644 --- a/docs/bos/api/state.md +++ b/docs/bos/api/state.md @@ -71,7 +71,7 @@ useEffect(() => { return (

You clicked {count} times

- diff --git a/docs/bos/api/web-methods.md b/docs/bos/api/web-methods.md index fa5419c697a..c5bc3557e69 100644 --- a/docs/bos/api/web-methods.md +++ b/docs/bos/api/web-methods.md @@ -31,7 +31,7 @@ return res.body; -
+
#### Async Version diff --git a/docs/bos/components.md b/docs/bos/components.md deleted file mode 100644 index 908fd624403..00000000000 --- a/docs/bos/components.md +++ /dev/null @@ -1,153 +0,0 @@ ---- -id: components -title: Components ---- - -import {WidgetEditor} from "@site/src/components/social-widget" - -NEAR allows you to create a decentralized frontend by writing and composing small applications known as `Components`. - -Components are stored in the NEAR blockchain, and execute locally in a custom Virtual Machine, thus ensuring the component can not access local storage or cookies. - ---- - -## Creating a Component - -To create a component you simply need to implement a return statement, returning some HTML code. - - - -```ts -let greeting = "Have a great day"; - -return ( - <> -
-

Hello

-

{greeting}

-
- -); -``` - - - ---- - -## VM context - -You can access the `context` object to get specific information about the VM instance. - -### `networkId` - -You can detect the current network (`mainnet` or `testnet`) using `context.networkId`. For example: - -```js -const childSrc = - context.networkId === "mainnet" - ? "near/src/Foobar" - : "preview.testnet/src/Foobar"; - -return ( -
-

A child dependency:

- -
-); -``` - -### `accountId` - -You can get the current signed-in user account (e.g., `user.near`) using `context.accountId`. For example: - -```js -let user_account = context.accountId; - -return ( - <> -
-

Hello

-

{user_account}

-
- -); -``` - - ---- - -## Props: Receiving Input - -Components can take arbitrary input, which will be reflected in the `props` variable. In the example below, we are passing as input `name="Anna"`. - - - -```ts -let name = props.name || "User"; -let greeting = "Have a great day"; - -return ( - <> -
-

Hello {name}

-

{greeting}

-
- -); -``` - - - ---- - -## State: Storing Information - -Components have an internal state were they can store information. - - - -```ts -State.init({greeting: "Have a great day"}); - -const onChange = ({target}) => { State.update({greeting: target.value}) }; - -return ( - <> -
-

Greeting: {state.greeting}

- - - -
- -); -``` - - - ---- - -## Composing Components - -To compose components you will use the [Predefined `Widget` component](./api/builtin-components.md#widget). For this, you only need the NEAR username of who created the component, and the component's name. - - - -```ts -const user = "gagdiez.near"; -const props = { name: "Anna" }; - -return ( - <> -
- -
Components can be composed
-
- - -
- -); -``` - - \ No newline at end of file diff --git a/docs/bos/index.md b/docs/bos/index.md deleted file mode 100644 index ec87c569bd6..00000000000 --- a/docs/bos/index.md +++ /dev/null @@ -1,39 +0,0 @@ ---- -id: welcome -title: Composable Multi-Chain Apps -sidebar_label: Home -hide_table_of_contents: true ---- - -import {FeatureList, Column, Feature} from "@site/src/components/featurelist" -import ContactUs from '@site/src/components/ContactUs.mdx'; - -Build fully decentralized applications for all chains. Publish and get discovered by thousands of users. Embrace the power of community and web 3. - - - - - - - - - - - - - - - - - - - - - - - -
- ---- - - diff --git a/docs/bos/overview.md b/docs/bos/overview.md index bd52bdfda1c..e1a8d28bbe7 100644 --- a/docs/bos/overview.md +++ b/docs/bos/overview.md @@ -30,19 +30,19 @@ Additionally, NEAR Components are chain-agnostic, making it a flexible solution ## The Pillars of NEAR Stack The NEAR stack is based on three pillars: -- [Components](#components): Composable frontends that solve specific problems. +- Components: Composable frontends that solve specific problems. - [Blockchains](#blockchains): To store the component's code, as well as their assets and data. - [Gateways](#gateways): A simple way to render components anywhere. -
+
### Components -[Components](./components.md) are small web 3 applications (think [Lido](tutorial/hello-lido.md), Uniswap, Aave) that are stored **entirely on-chain**. +Components are small web 3 applications (think [Lido](tutorial/hello-lido.md), Uniswap, Aave) that are stored **entirely on-chain**. -Developers can fork these apps and [compose them](./components.md#composing-components) to create full web applications. +Developers can fork these apps and compose them to create full web applications. -
+
### Blockchains @@ -50,7 +50,7 @@ Components can call functions on any blockchain, with current support for all EV The source code for the apps is on NEAR, due to it's ability to very cheaply store HTML/CSS/JS (a few cents). -
+
### Gateways diff --git a/docs/bos/tutorial/hello-lido.md b/docs/bos/tutorial/hello-lido.md index 17d0773974d..ace4c376e1a 100644 --- a/docs/bos/tutorial/hello-lido.md +++ b/docs/bos/tutorial/hello-lido.md @@ -212,67 +212,67 @@ const getSender = () => { return ( -
-
Stake Ether
-
Stake ETH and receive stETH while staking.
+
+
Stake Ether
+
Stake ETH and receive stETH while staking.
-
+
{state.sender && ( <> -
-
-
-
+
+
+
+
Available to stake -
+
-
+
{state.balance ?? (!state.sender ? "0" : "...")} ETH
-
-
-
+
+
+
{getSender()}
-
+
)}
-
-
-
+
+
+
Staked amount
-
+
{state.stakedBalance ?? (!state.sender ? "0" : "...")}  stETH
-
-
-
Lido APR
-
{state.lidoArp ?? "..."}%
+
+
+
Lido APR
+
{state.lidoArp ?? "..."}%
-
-
- +
+
+ - + State.update({ strEther: e.target.value })} placeholder="Amount" /> { State.update({ strEther: (state.balance > 0.05 @@ -315,16 +315,16 @@ return ( }} >
{!!state.sender ? (
@@ -74,13 +74,13 @@ const notLoggedInWarning =

Login to change the greeting

; // Render return ( <> -
-

+
+

The contract says: - {greeting} + {greeting}

-

+

Look at that! A greeting stored on the NEAR blockchain.

@@ -98,7 +98,7 @@ There are two important things to notice in the code above: 2. **context.accountId**: We check if `context.accountId` is set, which tells us if the user has logged in using their NEAR account, and thus can interact with NEAR contracts. ::: -
+
### 2. Handling User's Input Having our component's view ready, we now need to define the logic for when the user inputs a new greeting and presses the `Submit` button. This is, we need to define the `onInputChange` and `onBtnClick` methods. diff --git a/docs/bos/tutorial/indexer-tutorials/nft-indexer.md b/docs/bos/tutorial/indexer-tutorials/nft-indexer.md index a82d23e6ff8..78422522296 100644 --- a/docs/bos/tutorial/indexer-tutorials/nft-indexer.md +++ b/docs/bos/tutorial/indexer-tutorials/nft-indexer.md @@ -14,7 +14,7 @@ You can request access through [this link](http://bit.ly/near-queryapi-beta). ## Overview -This tutorial creates a working NFT indexer using [NEAR QueryAPI](../../queryapi/intro.md), and builds a [NEAR component](../../components.md) that presents the data. The indexer is watching for `nft_mint` [Events](https://nomicon.io/Standards/EventsFormat) and captures some relevant data: +This tutorial creates a working NFT indexer using [NEAR QueryAPI](../../queryapi/intro.md), and builds a [NEAR component](../../../bos/tutorial/quickstart.md) that presents the data. The indexer is watching for `nft_mint` [Events](https://nomicon.io/Standards/EventsFormat) and captures some relevant data: - `receiptId` of the [Receipt](https://near-indexers.io/docs/data-flow-and-structures/structures/receipt) where the mint has happened - `receiverId` diff --git a/docs/bos/tutorial/quickstart.md b/docs/bos/tutorial/quickstart.md index 48b3184c207..c056c133371 100644 --- a/docs/bos/tutorial/quickstart.md +++ b/docs/bos/tutorial/quickstart.md @@ -114,9 +114,9 @@ const like = (blockHeight) => Social.set( return <>
Posts from influencer.testnet
{post_data.map((post, idx) => -
+
{JSON.parse(post).text} - {likes[idx]} likes
- {context.accountId && } + {context.accountId && }
)} @@ -338,67 +338,67 @@ const getSender = () => { return ( -
-
Stake Ether
-
Stake ETH and receive stETH while staking.
+
+
Stake Ether
+
Stake ETH and receive stETH while staking.
-
+
{state.sender && ( <> -
-
-
-
+
+
+
+
Available to stake -
+
-
+
{state.balance ?? (!state.sender ? "0" : "...")} ETH
-
-
-
+
+
+
{getSender()}
-
+
)}
-
-
-
+
+
+
Staked amount
-
+
{state.stakedBalance ?? (!state.sender ? "0" : "...")}  stETH
-
-
-
Lido APR
-
{state.lidoArp ?? "..."}%
+
+
+
Lido APR
+
{state.lidoArp ?? "..."}%
-
-
- +
+
+ - + State.update({ strEther: e.target.value })} placeholder="Amount" /> { State.update({ strEther: (state.balance > 0.05 @@ -441,16 +441,16 @@ return ( }} >
{!!state.sender ? (

@@ -949,7 +949,7 @@ Here is the exhaustive list of the error variants that can be returned by `EXPER
REQUEST_VALIDATION_ERROR PARSE_ERROR Passed arguments can't be parsed by JSON RPC server (missing arguments, wrong format, etc.)