Merge pull request #447 from onflow/nialexsan/v3-best-practices

Nialexsan/v3 best practices

docs/build/advanced-concepts/account-linking/index.md

@@ -19,7 +19,7 @@ Since access to the `AuthAccount` object enables state change, the idea of accou
 
 ## AuthAccount Capabilities
 
-Before proceeding the reader will need a clear understanding of [Cadence capabilities](https://developers.flow.com/cadence/language/capabilities.md) to follow this section. Advanced features such as AuthAccount Capabilities are powerful but if used incorrectly can put your app or users at risk.
+Before proceeding the reader will need a clear understanding of [Cadence capabilities](https://cadence-lang.org/docs/language/capabilities) to follow this section. Advanced features such as AuthAccount Capabilities are powerful but if used incorrectly can put your app or users at risk.
 
 Cadence allows the creation of capabilities to delegate access to account storage, meaning any account that has a valid capability to another account object in the storage can access it. This is a powerful feature on its own. The access to the object can be limited when creating a capability so only intended functions or fields can be accessed.
 
@@ -106,17 +106,17 @@ Apps need assurances that their own resources are safe from malicious actors, so
 
 Learn more about it in the [Hybrid Custody documentation](./parent-accounts.md).
 
-### Guides[](https://developers.flow.com/concepts/account-linking#guides)
+### Guides
 
-- [Building Walletless Applications Using Child Accounts](https://developers.flow.com/concepts/account-linking/child-accounts) covers how apps can leverage Account Linking to create a seamless user experience and enable future self-custody.
-- [Working With Parent Accounts](https://developers.flow.com/concepts/account-linking/parent-accounts) covers features enabled by the core `HybridCustody` contract to access child account assets from parent accounts. This is useful for apps like marketplaces or wallets that are working with accounts that have potential child accounts.
+- [Building Walletless Applications Using Child Accounts](./child-accounts.md) covers how apps can leverage Account Linking to create a seamless user experience and enable future self-custody.
+- [Working With Parent Accounts](./parent-accounts.md) covers features enabled by the core `HybridCustody` contract to access child account assets from parent accounts. This is useful for apps like marketplaces or wallets that are working with accounts that have potential child accounts.
 
-### Resources[](https://developers.flow.com/concepts/account-linking#resources)
+### Resources
 
 - [Forum Post](https://forum.onflow.org/t/hybrid-custody/4016) where core concepts were introduced and discussed.
 - [GitHub repository](https://github.com/onflow/hybrid-custody) where `HybridCustody` core contract is maintained. Check out the repository for more advanced script or transaction examples.
 - [Example](https://github.com/jribbink/magic-link-hc-sample/) Account Linking project with [Magic](https://magic.link/).
 - [Starter template](https://github.com/Niftory/niftory-samples/tree/main/walletless-onboarding) for [Niftory](https://niftory.com/) Account Linking API.
-- [Scaffold](https://github.com/onflow/hybrid-custody-scaffold) to start a new Account Linking project. Check out Flow CLI [Scaffolds](https://developers.flow.com/tooling/flow-cli/super-commands#using-scaffolds) to get started.
+- [Scaffold](https://github.com/onflow/hybrid-custody-scaffold) to start a new Account Linking project. Check out Flow CLI [Scaffolds](../../../tools/flow-cli/super-commands.md#using-scaffolds) to get started.
 - [Wallet API](https://github.com/flow-hydraulics/flow-wallet-api/) is a microservice that enables apps to custody accounts. This is useful if you don't want to use a third-party service to manage user accounts.
 - [Walletless Arcade](https://github.com/onflow/walletless-arcade-example) example demonstrates Account Linking with a local key management solution.

docs/build/advanced-concepts/account-linking/parent-accounts.md

@@ -35,8 +35,7 @@ access between the app - the entity which created likely custodies the account -
 
 How does this delegation occur? Typically when we think of shared account access in crypto, we think keys. However,
 Cadence enables [accounts to link Capabilities to themselves](https://github.com/onflow/cadence/issues/2151) and issue
-those Capabilities to other parties (more on [capability-based access
-here](https://developers.flow.com/cadence/language/capabilities.md)).
+those Capabilities to other parties (more on [capability-based access here](https://cadence-lang.org/docs/language/capabilities)).
 
 We've leveraged this feature in a (proposed) standard so that apps can implement a hybrid custody model whereby the
 app creates an account it controls, then later delegates access on that account to the user once they've authenticated

docs/build/advanced-concepts/randomness.md

@@ -43,7 +43,7 @@ For usage of randomness where result abortion is not an issue, it is recommended
 
 ```cadence
 // Language reference:
-// https://developers.flow.com/cadence/language/built-in-functions#revertiblerandom
+// https://cadence-lang.org/docs/language/built-in-functions#revertiblerandom
 // Run the snippet here: https://academy.ecdao.org/en/snippets/cadence-random
 access(all) fun main(): UInt64 {
 	// Simple assignment using revertibleRandom - keep reading docs for safe usage!	

docs/build/basics/accounts.md

@@ -170,7 +170,7 @@ Find [more about the command in the CLI docs](../../tools/flow-cli/accounts/get-
 
 Accounts can be obtained from the access node APIs, currently, there are two gRPC and REST APIs. You can find more information about them here:
 
-**gRPC API** [building-on-flow/nodes/access-api#accounts](../../references/run-and-secure/nodes/access-api.mdx#accounts)
+**gRPC API** [building-on-flow/nodes/access-api#accounts](../../references/run-and-secure/nodes/access-api.md#accounts)
 
 **REST API** [http-api#tag/Accounts](/http-api#tag/Accounts)
 

docs/build/basics/blocks.md

@@ -63,7 +63,7 @@ Find [more about the command in the CLI docs](../../tools/flow-cli/get-flow-data
 
 Blocks can be obtained from the access node APIs, currently, there are two gRPC and REST APIs. You can find more information about them here:
 
-[**gRPC Block API**](../../references/run-and-secure/nodes/access-api.mdx#blocks)
+[**gRPC Block API**](../../references/run-and-secure/nodes/access-api.md#blocks)
 
 [**REST Block API**](/http-api#tag/Blocks)
 

docs/build/basics/collections.md

@@ -20,7 +20,7 @@ Find [more about the command in the CLI docs](../../tools/flow-cli/get-flow-data
 
 Collections can be obtained from the access node APIs, currently, there are two gRPC and REST APIs. You can find more information about them here:
 
-[**gRPC Collection API**](../../references/run-and-secure/nodes/access-api.mdx#collections)
+[**gRPC Collection API**](../../references/run-and-secure/nodes/access-api.md#collections)
 
 [**REST Collection API**](/http-api#tag/Collections)
 

docs/build/basics/fees.md

@@ -294,7 +294,7 @@ pub fun add(_ a: Int, _ b: Int): Int {
 
 **Avoid excessive load and save operations**
 
-Avoid costly loading and storage operations and [borrow references](https://cadence-lang.org/docs/design-patterns#avoid-excessive-load-and-save-storage-operations-prefer-in-place-mutations) where possible, for example:
+Avoid costly loading and storage operations and [borrow references](../best-practices/design-patterns.md#avoid-excessive-load-and-save-storage-operations-prefer-in-place-mutations) where possible, for example:
 
 ```cadence
 transaction {

docs/build/basics/scripts.md

@@ -46,7 +46,7 @@ Scripts can be run against previous blocks, allowing you to query historic data
 
 Scripts are executed by being submitted to the Access Node APIs. Currently, there’s support for two APIs:
 
-[**gRPC Script API**](../../references/run-and-secure/nodes/access-api.mdx#scripts)
+[**gRPC Script API**](../../references/run-and-secure/nodes/access-api.md#scripts)
 
 [**REST Script API**](/http-api#tag/Scripts)
 

docs/build/basics/transactions.md

@@ -40,7 +40,7 @@ transaction(greeting: String) {
 
 **Arguments**
 
-Transactions may declare parameters it needs during execution, these must be provided as input arguments when sending a transaction. You can think of them as function arguments. Currently, we provide [arguments in the JSON-Cadence Data Interchange Format](https://cadence-lang.org/docs/json-cadence-spec#docusaurus_skipToContent_fallback). Which is a human-readable JSON format. The sample script from above accepts a single `String` argument.
+Transactions may declare parameters it needs during execution, these must be provided as input arguments when sending a transaction. You can think of them as function arguments. Currently, we provide [arguments in the JSON-Cadence Data Interchange Format](../cadence-reference/json-cadence-spec.md). Which is a human-readable JSON format. The sample script from above accepts a single `String` argument.
 
 **Reference Block**
 
@@ -376,7 +376,7 @@ A user can define their own transactions or it can use already defined transacti
 
 Transactions can be submitted and obtained from the access node APIs, currently, there are two gRPC and REST APIs. You can find more information about them here:
 
-[**gRPC Transaction API**](../../references/run-and-secure/nodes/access-api.mdx#transactions)
+[**gRPC Transaction API**](../../references/run-and-secure/nodes/access-api.md#transactions)
 
 [**REST Transaction API**](/http-api#tag/Transactions)
 

docs/build/best-practices/_category_.yml

@@ -0,0 +1 @@
+label: Basic Practices