](./api.md#query)
-Scripts allow you to write arbitrary non-mutating Cadence code on the Flow blockchain and return data. You can learn more about [Cadence here](../../cadence/language/index.md) and [scripts here](./scripts.mdx), but we are now only interested in executing the script code and getting back the data.
+Scripts allow you to write arbitrary non-mutating Cadence code on the Flow blockchain and return data. You can learn more about [Cadence here](../../../cadence/language/index.md) and [scripts here](./scripts.mdx), but we are now only interested in executing the script code and getting back the data.
We can execute a script using the latest state of the Flow blockchain or we can choose to execute the script at a specific time in history defined by a block height or block ID.
@@ -279,7 +279,7 @@ Transaction data is composed and signed with help of the SDK. The signed payload
## Transactions
A transaction is nothing more than a signed set of data that includes script code which are instructions on how to mutate the network state and properties that define and limit it's execution. All these properties are explained bellow.
-π **Script** field is the portion of the transaction that describes the state mutation logic. On Flow, transaction logic is written in [Cadence](../../cadence/intro.md). Here is an example transaction script:
+π **Script** field is the portion of the transaction that describes the state mutation logic. On Flow, transaction logic is written in [Cadence](../../../cadence/intro.md). Here is an example transaction script:
```
transaction(greeting: String) {
execute {
@@ -290,7 +290,7 @@ transaction(greeting: String) {
π **Arguments**. A transaction can accept zero or more arguments that are passed into the Cadence script. The arguments on the transaction must match the number and order declared in the Cadence script. Sample script from above accepts a single `String` argument.
-π **[Proposal key](../../concepts/start-here/transaction-signing.md#proposal-key)** must be provided to act as a sequence number and prevent replay and other potential attacks.
+π **[Proposal key](../../../concepts/start-here/transaction-signing.md#proposal-key)** must be provided to act as a sequence number and prevent replay and other potential attacks.
Each account key maintains a separate transaction sequence counter; the key that lends its sequence number to a transaction is called the proposal key.
@@ -301,9 +301,9 @@ A proposal key contains three fields:
A transaction is only valid if its declared sequence number matches the current on-chain sequence number for that key. The sequence number increments by one after the transaction is executed.
-π **[Payer](../../concepts/start-here/transaction-signing.md#signer-roles)** is the account that pays the fees for the transaction. A transaction must specify exactly one payer. The payer is only responsible for paying the network and gas fees; the transaction is not authorized to access resources or code stored in the payer account.
+π **[Payer](../../../concepts/start-here/transaction-signing.md#signer-roles)** is the account that pays the fees for the transaction. A transaction must specify exactly one payer. The payer is only responsible for paying the network and gas fees; the transaction is not authorized to access resources or code stored in the payer account.
-π **[Authorizers](../../concepts/start-here/transaction-signing.md#signer-roles)** are accounts that authorize a transaction to read and mutate their resources. A transaction can specify zero or more authorizers, depending on how many accounts the transaction needs to access.
+π **[Authorizers](../../../concepts/start-here/transaction-signing.md#signer-roles)** are accounts that authorize a transaction to read and mutate their resources. A transaction can specify zero or more authorizers, depending on how many accounts the transaction needs to access.
The number of authorizers on the transaction must match the number of AuthAccount parameters declared in the prepare statement of the Cadence script.
@@ -315,7 +315,7 @@ transaction {
```
π **Gas limit** is the limit on the amount of computation a transaction requires, and it will abort if it exceeds its gas limit.
-Cadence uses metering to measure the number of operations per transaction. You can read more about it in the [Cadence documentation](../../cadence/intro.md).
+Cadence uses metering to measure the number of operations per transaction. You can read more about it in the [Cadence documentation](../../../cadence/intro.md).
The gas limit depends on the complexity of the transaction script. Until dedicated gas estimation tooling exists, it's best to use the emulator to test complex transactions and determine a safe limit.
@@ -349,7 +349,7 @@ await fcl.mutate({
Flow supports great flexibility when it comes to transaction signing, we can define multiple authorizers (multi-sig transactions) and have different payer account than proposer. We will explore advanced signing scenarios bellow.
-### [Single party, single signature](../../concepts/start-here/transaction-signing.md#single-party-single-signature)
+### [Single party, single signature](../../../concepts/start-here/transaction-signing.md#single-party-single-signature)
- Proposer, payer and authorizer are the same account (`0x01`).
- Only the envelope must be signed.
@@ -418,7 +418,7 @@ mutate({
})
```
-### [Single party, multiple signatures](../../concepts/start-here/transaction-signing.md#single-party-multiple-signatures)
+### [Single party, multiple signatures](../../../concepts/start-here/transaction-signing.md#single-party-multiple-signatures)
- Proposer, payer and authorizer are the same account (`0x01`).
- Only the envelope must be signed.
@@ -475,7 +475,7 @@ mutate({
})
```
-### [Multiple parties](../../concepts/start-here/transaction-signing.md#multiple-parties)
+### [Multiple parties](../../../concepts/start-here/transaction-signing.md#multiple-parties)
- Proposer and authorizer are the same account (`0x01`).
- Payer is a separate account (`0x02`).
@@ -535,7 +535,7 @@ mutate({
})
```
-### [Multiple parties, two authorizers](../../concepts/start-here/transaction-signing.md#multiple-parties)
+### [Multiple parties, two authorizers](../../../concepts/start-here/transaction-signing.md#multiple-parties)
- Proposer and authorizer are the same account (`0x01`).
- Payer is a separate account (`0x02`).
@@ -596,7 +596,7 @@ mutate({
})
```
-### [Multiple parties, multiple signatures](../../concepts/start-here/transaction-signing.md#multiple-parties)
+### [Multiple parties, multiple signatures](../../../concepts/start-here/transaction-signing.md#multiple-parties)
- Proposer and authorizer are the same account (`0x01`).
- Payer is a separate account (`0x02`).
diff --git a/docs/tooling/fcl-js/transactions.mdx b/docs/tools/clients/fcl-js/transactions.mdx
similarity index 100%
rename from docs/tooling/fcl-js/transactions.mdx
rename to docs/tools/clients/fcl-js/transactions.mdx
diff --git a/docs/tooling/fcl-js/user-signatures.mdx b/docs/tools/clients/fcl-js/user-signatures.mdx
similarity index 100%
rename from docs/tooling/fcl-js/user-signatures.mdx
rename to docs/tools/clients/fcl-js/user-signatures.mdx
diff --git a/docs/tooling/fcl-js/wallet-connect.mdx b/docs/tools/clients/fcl-js/wallet-connect.mdx
similarity index 100%
rename from docs/tooling/fcl-js/wallet-connect.mdx
rename to docs/tools/clients/fcl-js/wallet-connect.mdx
diff --git a/docs/tooling/flow-go-sdk/error-codes.mdx b/docs/tools/clients/flow-go-sdk/error-codes.mdx
similarity index 100%
rename from docs/tooling/flow-go-sdk/error-codes.mdx
rename to docs/tools/clients/flow-go-sdk/error-codes.mdx
diff --git a/docs/tooling/flow-go-sdk/index.mdx b/docs/tools/clients/flow-go-sdk/index.mdx
similarity index 94%
rename from docs/tooling/flow-go-sdk/index.mdx
rename to docs/tools/clients/flow-go-sdk/index.mdx
index 336ee54337..ee2b7d9500 100644
--- a/docs/tooling/flow-go-sdk/index.mdx
+++ b/docs/tools/clients/flow-go-sdk/index.mdx
@@ -303,8 +303,8 @@ Retrieve events by a given type in a specified block height range or through a l
A.{contract address}.{contract name}.{event name}
```
-Please read more about [events in the documentation](../../concepts/core-contracts/03-flow-token.md). The exception to this standard are
-core events, and you should read more about them in [this document](../../cadence/language/core-events.md).
+Please read more about [events in the documentation](../../../concepts/core-contracts/03-flow-token.md). The exception to this standard are
+core events, and you should read more about them in [this document](../../../cadence/language/core-events.md).
π **Block height range** expresses the height of the start and end block in the chain.
@@ -409,7 +409,7 @@ Transactions: [cf1184e3de4bd9a7232ca3d0b9dd2cfbf96c97888298b81a05c086451fa52ec1]
[](https://pkg.go.dev/github.com/onflow/flow-go-sdk/client#Client.ExecuteScriptAtLatestBlock)
-Scripts allow you to write arbitrary non-mutating Cadence code on the Flow blockchain and return data. You can learn more about [Cadence and scripts here](../../cadence/language/index.md), but we are now only interested in executing the script code and getting back the data.
+Scripts allow you to write arbitrary non-mutating Cadence code on the Flow blockchain and return data. You can learn more about [Cadence and scripts here](../../../cadence/language/index.md), but we are now only interested in executing the script code and getting back the data.
We can execute a script using the latest state of the Flow blockchain or we can choose to execute the script at a specific time in history defined by a block height or block ID.
@@ -510,7 +510,7 @@ Executing a transaction requires couple of steps:
A transaction is nothing more than a signed set of data that includes script code which are instructions on how to mutate the network state and properties that define and limit it's execution. All these properties are explained bellow.
-π **Script** field is the portion of the transaction that describes the state mutation logic. On Flow, transaction logic is written in [Cadence](../../cadence/intro.md). Here is an example transaction script:
+π **Script** field is the portion of the transaction that describes the state mutation logic. On Flow, transaction logic is written in [Cadence](../../../cadence/intro.md). Here is an example transaction script:
```
transaction(greeting: String) {
@@ -522,7 +522,7 @@ transaction(greeting: String) {
π **Arguments**. A transaction can accept zero or more arguments that are passed into the Cadence script. The arguments on the transaction must match the number and order declared in the Cadence script. Sample script from above accepts a single `String` argument.
-π **[Proposal key](../../concepts/start-here/transaction-signing.md#proposal-key)** must be provided to act as a sequence number and prevent reply and other potential attacks.
+π **[Proposal key](../../../concepts/start-here/transaction-signing.md#proposal-key)** must be provided to act as a sequence number and prevent reply and other potential attacks.
Each account key maintains a separate transaction sequence counter; the key that lends its sequence number to a transaction is called the proposal key.
@@ -534,9 +534,9 @@ A proposal key contains three fields:
A transaction is only valid if its declared sequence number matches the current on-chain sequence number for that key. The sequence number increments by one after the transaction is executed.
-π **[Payer](../../concepts/start-here/transaction-signing.md#signer-roles)** is the account that pays the fees for the transaction. A transaction must specify exactly one payer. The payer is only responsible for paying the network and gas fees; the transaction is not authorized to access resources or code stored in the payer account.
+π **[Payer](../../../concepts/start-here/transaction-signing.md#signer-roles)** is the account that pays the fees for the transaction. A transaction must specify exactly one payer. The payer is only responsible for paying the network and gas fees; the transaction is not authorized to access resources or code stored in the payer account.
-π **[Authorizers](../../concepts/start-here/transaction-signing.md#signer-roles)** are accounts that authorize a transaction to read and mutate their resources. A transaction can specify zero or more authorizers, depending on how many accounts the transaction needs to access.
+π **[Authorizers](../../../concepts/start-here/transaction-signing.md#signer-roles)** are accounts that authorize a transaction to read and mutate their resources. A transaction can specify zero or more authorizers, depending on how many accounts the transaction needs to access.
The number of authorizers on the transaction must match the number of AuthAccount parameters declared in the prepare statement of the Cadence script.
@@ -549,7 +549,7 @@ transaction {
```
π **Gas limit** is the limit on the amount of computation a transaction requires, and it will abort if it exceeds its gas limit.
-Cadence uses metering to measure the number of operations per transaction. You can read more about it in the [Cadence documentation](../../cadence/intro.md).
+Cadence uses metering to measure the number of operations per transaction. You can read more about it in the [Cadence documentation](../../../cadence/intro.md).
The gas limit depends on the complexity of the transaction script. Until dedicated gas estimation tooling exists, it's best to use the emulator to test complex transactions and determine a safe limit.
@@ -649,9 +649,9 @@ After you have successfully [built a transaction](#build-the-transaction) the ne
[](https://pkg.go.dev/github.com/onflow/flow-go-sdk#Transaction.SignEnvelope)
Flow introduces new concepts that allow for more flexibility when creating and signing transactions.
-Before trying the examples below, we recommend that you read through the [transaction signature documentation](../../concepts/start-here/accounts-and-keys.md).
+Before trying the examples below, we recommend that you read through the [transaction signature documentation](../../../concepts/start-here/accounts-and-keys.md).
-After you have successfully [built a transaction](#build-the-transaction) the next step in the process is to sign it. Flow transactions have envelope and payload signatures, and you should learn about each in the [signature documentation](../../concepts/start-here/accounts-and-keys.md#anatomy-of-a-transaction).
+After you have successfully [built a transaction](#build-the-transaction) the next step in the process is to sign it. Flow transactions have envelope and payload signatures, and you should learn about each in the [signature documentation](../../../concepts/start-here/accounts-and-keys.md#anatomy-of-a-transaction).
Quick example of building a transaction:
@@ -695,7 +695,7 @@ if err != nil {
Flow supports great flexibility when it comes to transaction signing, we can define multiple authorizers (multi-sig transactions) and have different payer account than proposer. We will explore advanced signing scenarios bellow.
-### [Single party, single signature](../../concepts/start-here/transaction-signing.md#single-party-single-signature)
+### [Single party, single signature](../../../concepts/start-here/transaction-signing.md#single-party-single-signature)
- Proposer, payer and authorizer are the same account (`0x01`).
- Only the envelope must be signed.
@@ -732,7 +732,7 @@ tx := flow.NewTransaction().
err := tx.SignEnvelope(account1.Address, key1.Index, key1Signer)
```
-### [Single party, multiple signatures](../../concepts/start-here/transaction-signing.md#single-party-multiple-signatures)
+### [Single party, multiple signatures](../../../concepts/start-here/transaction-signing.md#single-party-multiple-signatures)
- Proposer, payer and authorizer are the same account (`0x01`).
- Only the envelope must be signed.
@@ -775,7 +775,7 @@ err := tx.SignEnvelope(account1.Address, key1.Index, key1Signer)
err = tx.SignEnvelope(account1.Address, key2.Index, key2Signer)
```
-### [Multiple parties](../../concepts/start-here/transaction-signing.md#multiple-parties)
+### [Multiple parties](../../../concepts/start-here/transaction-signing.md#multiple-parties)
- Proposer and authorizer are the same account (`0x01`).
- Payer is a separate account (`0x02`).
@@ -822,7 +822,7 @@ err := tx.SignPayload(account1.Address, key1.Index, key1Signer)
err = tx.SignEnvelope(account2.Address, key3.Index, key3Signer)
```
-### [Multiple parties, two authorizers](../../concepts/start-here/transaction-signing.md#multiple-parties)
+### [Multiple parties, two authorizers](../../../concepts/start-here/transaction-signing.md#multiple-parties)
- Proposer and authorizer are the same account (`0x01`).
- Payer is a separate account (`0x02`).
@@ -874,7 +874,7 @@ err := tx.SignPayload(account1.Address, key1.Index, key1Signer)
err = tx.SignEnvelope(account2.Address, key3.Index, key3Signer)
```
-### [Multiple parties, multiple signatures](../../concepts/start-here/transaction-signing.md#multiple-parties)
+### [Multiple parties, multiple signatures](../../../concepts/start-here/transaction-signing.md#multiple-parties)
- Proposer and authorizer are the same account (`0x01`).
- Payer is a separate account (`0x02`).
@@ -961,7 +961,7 @@ func demo(tx *flow.Transaction) {
On Flow, account creation happens inside a transaction. Because the network allows for a many-to-many relationship between public keys and accounts, it's not possible to derive a new account address from a public key offline.
-The Flow VM uses a deterministic address generation algorithm to assign account addresses on chain. You can find more details about address generation in the [accounts & keys documentation](../../concepts/start-here/accounts-and-keys.md).
+The Flow VM uses a deterministic address generation algorithm to assign account addresses on chain. You can find more details about address generation in the [accounts & keys documentation](../../../concepts/start-here/accounts-and-keys.md).
#### Public Key
@@ -971,7 +971,7 @@ Flow uses ECDSA key pairs to control access to user accounts. Each key pair can
Flow represents ECDSA public keys in raw form without additional metadata. Each key is a single byte slice containing a concatenation of its X and Y components in big-endian byte form.
-A Flow account can contain zero (not possible to control) or more public keys, referred to as account keys. Read more about [accounts in the documentation](../../concepts/start-here/accounts-and-keys.md#accounts).
+A Flow account can contain zero (not possible to control) or more public keys, referred to as account keys. Read more about [accounts in the documentation](../../../concepts/start-here/accounts-and-keys.md#accounts).
An account key contains the following data:
@@ -1051,7 +1051,7 @@ for _, event := range result.Events {
### Generate Keys
-[](../../concepts/start-here/accounts-and-keys.md#supported-signature--hash-algorithms)
+[](../../../concepts/start-here/accounts-and-keys.md#supported-signature--hash-algorithms)
Flow uses [ECDSA](https://en.wikipedia.org/wiki/Elliptic_Curve_Digital_Signature_Algorithm) signatures to control access to user accounts. Each key pair can be used in combination with the `SHA2-256` or `SHA3-256` hashing algorithms.
@@ -1072,7 +1072,7 @@ encPrivateKey := privateKey.Encode()
publicKey := privateKey.PublicKey()
```
-The example above uses an ECDSA key pair on the P-256 (secp256r1) elliptic curve. Flow also supports the secp256k1 curve used by Bitcoin and Ethereum. Read more about [supported algorithms here](../../concepts/start-here/accounts-and-keys.md#supported-signature--hash-algorithms).
+The example above uses an ECDSA key pair on the P-256 (secp256r1) elliptic curve. Flow also supports the secp256k1 curve used by Bitcoin and Ethereum. Read more about [supported algorithms here](../../../concepts/start-here/accounts-and-keys.md#supported-signature--hash-algorithms).
### Transfering Flow
diff --git a/docs/tooling/flow-go-sdk/migration-v0.25.0.md b/docs/tools/clients/flow-go-sdk/migration-v0.25.0.md
similarity index 100%
rename from docs/tooling/flow-go-sdk/migration-v0.25.0.md
rename to docs/tools/clients/flow-go-sdk/migration-v0.25.0.md
diff --git a/docs/tools/clients/index.md b/docs/tools/clients/index.md
new file mode 100644
index 0000000000..7fbbed7bcd
--- /dev/null
+++ b/docs/tools/clients/index.md
@@ -0,0 +1,48 @@
+# Clients
+
+## Go SDK
+
+The [Flow Go SDK](./flow-go-sdk/index.mdx) provides a set of packages for Go developers to build applications that interact with the Flow network.
+
+## Python SDK
+
+The [Flow Python SDK](https://github.com/janezpodhostnik/flow-py-sdk) provides a set of packages for Python developers to build applications that interact with the Flow network.
+
+## Ruby
+
+[FlowClient](https://github.com/glucode/flow_client) is a Ruby gRPC client for Flow (onflow.org)
+
+## Kotlin
+
+The [Flow JVM SDK](https://github.com/onflow/flow-jvm-sdk) is a library for JVM languages (e.g. Java, Kotlin) that provides utilities to interact with the Flow blockchain.
+
+## Unity
+
+The [Flow SDK for Unity](./unity-sdk/index.md) allows Unity developers to integrate their games and applications with the Flow blockchain.
+
+## JavaScript (FCL)
+
+The [Flow Client Library (FCL)](./fcl-js/index.md) JS is a package used to interact with user wallets and the Flow blockchain
+
+## Swift
+[flow-swift] is a tool to build iOS application in Flow mobile realm π
+
+## .Net
+
+[flow.net](https://github.com/tyronbrand/flow.net) is a tool for building .Net applications on Flow
+
+## Rust
+
+[Rust SDK](https://github.com/fee1-dead/flow.rs) for the Flow blockchain network
+
+## PHP
+
+[PHP SDK](https://github.com/mayvenstudios/flow-php-sdk) for the Flow blockchain
+
+## Elixir
+
+[OnFlow](https://github.com/nkezhaya/on_flow) is an Elixir client for interacting with the Flow blockchain. Documentation here: https://hexdocs.pm/on_flow.
+
+## HTTP API
+
+[Flow OpenAPI](/http-api) specification
\ No newline at end of file
diff --git a/docs/tooling/unity-sdk/api-reference.md b/docs/tools/clients/unity-sdk/api-reference.md
similarity index 100%
rename from docs/tooling/unity-sdk/api-reference.md
rename to docs/tools/clients/unity-sdk/api-reference.md
diff --git a/docs/tooling/unity-sdk/changelog.md b/docs/tools/clients/unity-sdk/changelog.md
similarity index 100%
rename from docs/tooling/unity-sdk/changelog.md
rename to docs/tools/clients/unity-sdk/changelog.md
diff --git a/docs/tooling/unity-sdk/guides/convert.md b/docs/tools/clients/unity-sdk/guides/convert.md
similarity index 100%
rename from docs/tooling/unity-sdk/guides/convert.md
rename to docs/tools/clients/unity-sdk/guides/convert.md
diff --git a/docs/tooling/unity-sdk/guides/dev-wallet.md b/docs/tools/clients/unity-sdk/guides/dev-wallet.md
similarity index 97%
rename from docs/tooling/unity-sdk/guides/dev-wallet.md
rename to docs/tools/clients/unity-sdk/guides/dev-wallet.md
index d972e0e0cb..720de8d5a3 100644
--- a/docs/tooling/unity-sdk/guides/dev-wallet.md
+++ b/docs/tools/clients/unity-sdk/guides/dev-wallet.md
@@ -15,7 +15,7 @@ The initial v1.0.0 release of the Flow SDK for Unity does not provide a producti
A wallet is a piece of software or hardware that stores the private key associated with a Flow account. The term *custodian* is used to refer to the party that stores the private key. Hardware Wallets (eg Ledger), typically USB devices, allow users to be their own custodian, whereas hosted software wallets (eg Dapper Wallet) act as the custodian on behalf of the user.
-For more information about Wallets and Flow accounts, see [user-accounts-and-wallets](../../../tutorials/user-accounts-and-wallets.md).
+For more information about Wallets and Flow accounts, see [user-accounts-and-wallets](../../../../tutorials/user-accounts-and-wallets.md).
## What is a Wallet Provider?
@@ -97,7 +97,7 @@ public Task
+ )}
+ >
{icon}
{titleLabel}
diff --git a/src/theme/DocCard/index.tsx b/src/theme/DocCard/index.tsx
new file mode 100644
index 0000000000..683cc688c4
--- /dev/null
+++ b/src/theme/DocCard/index.tsx
@@ -0,0 +1,120 @@
+// swizzled component from a standard DocCard
+import React, { type ReactNode } from 'react';
+import clsx from 'clsx';
+import Link from '@docusaurus/Link';
+import {
+ findFirstCategoryLink,
+ useDocById,
+} from '@docusaurus/theme-common/internal';
+import isInternalUrl from '@docusaurus/isInternalUrl';
+import { translate } from '@docusaurus/Translate';
+import type { Props } from '@theme/DocCard';
+
+import styles from './styles.module.css';
+import type {
+ PropSidebarItemCategory,
+ PropSidebarItemLink,
+} from '@docusaurus/plugin-content-docs';
+
+function CardContainer({
+ href,
+ children,
+}: {
+ href: string;
+ children: ReactNode;
+}): JSX.Element {
+ return (
+
+ {children}
+
+ );
+}
+
+function CardLayout({
+ href,
+ icon,
+ title,
+ description,
+}: {
+ href: string;
+ icon: ReactNode;
+ title: string;
+ description?: string;
+}): JSX.Element {
+ return (
+
+
+ );
+}
+
+function CardCategory({
+ item,
+}: {
+ item: PropSidebarItemCategory;
+}): JSX.Element | null {
+ const href = findFirstCategoryLink(item);
+
+ // Unexpected: categories that don't have a link have been filtered upfront
+ if (!href) {
+ return null;
+ }
+
+ return (
+
+ {icon} {title} +
+ {description && ( ++ {description} +
+ )} +