From 6c91d140c7feefec92380c9385d59a0dc9202a93 Mon Sep 17 00:00:00 2001 From: snoppy Date: Tue, 7 May 2024 21:24:51 +0800 Subject: [PATCH] chore:fix typos --- docs/dapp_prelaunch.md | 2 +- docs/signing.md | 2 +- waku-helpers.sh | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/dapp_prelaunch.md b/docs/dapp_prelaunch.md index f4c0a892f5..10c0067e5c 100644 --- a/docs/dapp_prelaunch.md +++ b/docs/dapp_prelaunch.md @@ -11,7 +11,7 @@ author: Claude Barde - Did you enable `Local Pack` in your dapp? Local Pack reduces the search time in bigmaps by 50%, and you can easily add it to your dapp by providing a new instance of the `MichelCodecPacker` class to the `setPackerProvider` method of the `TezosToolkit`. - Are you creating a single instance of the `BeaconWallet` that you can reuse throughout the different components of your dapp? The JavaScript frameworks generally offer a solution to easily share data between components (the Context API in React, Provide/Inject in Vue, or a Svelte store). The instance of the `BeaconWallet` must be saved there in order to use the same one in every component. Creating multiple instances of the `BeaconWallet` may create errors when forging new transactions. - Is your dapp making HTTP requests on update only when necessary? The JavaScript frameworks provide different solutions to rerender the DOM when internal data is updated (React `useEffect`, Vue `beforeUpdate` and Svelte `afterUpdate`). These data may be based on call responses to Tezos nodes or indexers, which is why it is crucial to optimize them. Unnecessary HTTP requests increase the traffic to Tezos nodes and indexer servers and slow down your dapp. -- Does your application wait for a confirmation of an operation, and does it check if the operation was successfull or failed when receiving the transaction receipt? This piece of information is crucial to your users in order to know if the transaction went through or not. +- Does your application wait for a confirmation of an operation, and does it check if the operation was successful or failed when receiving the transaction receipt? This piece of information is crucial to your users in order to know if the transaction went through or not. - Do you display user-friendly error messages, for example, when a transaction fails? A lack of visual feedback when transactions don't go through as expected can be confusing for users. Users must be informed about skipped, backtracked, and failed transactions. - Are you handling big numbers? Because numbers in Michelson are arbitrary-precision, they can become quite long, and JavaScript switches to the scientific notation to represent them, which can be confusing for users. You can use the `bignumber.js` library to handle potentially long numbers coming from the blockchain. - Do you have error reporting enabled on your dapp? An error reporting tool like [BugSnag](https://www.bugsnag.com/platforms/javascript) allows you to understand the issues your users face when using your dapp. diff --git a/docs/signing.md b/docs/signing.md index 54903020f2..022ee1021a 100644 --- a/docs/signing.md +++ b/docs/signing.md @@ -143,7 +143,7 @@ const isVerified = verifySignature( ## Signing Michelson data -Taquito also offers the possibility to sign Michelson code. This feature can be useful, for example, if you need to send a lambda to a contract to be executed but want to restrict the number of users who can submit a lambda by verifiying the signer's address. The signing of Michelson code requires the use of the `michel-codec` package: +Taquito also offers the possibility to sign Michelson code. This feature can be useful, for example, if you need to send a lambda to a contract to be executed but want to restrict the number of users who can submit a lambda by verifying the signer's address. The signing of Michelson code requires the use of the `michel-codec` package: ```js live noInline // import { TezosToolkit } from '@taquito/taquito'; diff --git a/waku-helpers.sh b/waku-helpers.sh index 7b6cbe6f30..62661ed51c 100644 --- a/waku-helpers.sh +++ b/waku-helpers.sh @@ -9,7 +9,7 @@ # * Clone and build nwaku: https://is.gd/NXeAnv # * Add a .env file with a variable NWAKU_DIR set to your nwaku directory -_err() { # write a (loud) message to stderr, if running interacively +_err() { # write a (loud) message to stderr, if running interactively [[ -o interactive ]] && tput setaf 1 echo "$@" 1>&2 }