Dapp pre-launch checklist

You will find below a few considerations that you may take into account when building your Tezos dapp or before publishing it. These pointers help you prevent eventual bugs and improve your users' experience.#

  • Is your dapp using a reliable and scalable RPC node? Running your own RPC node is often the best choice, especially if you anticipate significant traffic to your dapp. Using a paid hosted node is also a great idea, such as Nautilus from Cryptonomic, or TezTools. You can find here a list of public Tezos nodes.
  • Have you specified (hard-coded) fees and storage limits for smart contract calls from your dapp? Specifying these values has two advantages. Your dapp needs to make fewer calls to an RPC node (which makes your dapp faster!), and you can fine-tune your gas and storage values which, if set correctly, will reduce the likelihood of your users getting backtracked operations when using your dapp.
  • Have you tested your dapp with the popular wallets? Testing with Kukai and Temple wallets is essential. Testing with all the wallets is recommended!
  • 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.
  • 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 allows you to understand the issues your users face when using your dapp.