Best Practices for View Deployment

Guidelines for effectively deploying Views on Analog Watch.

A View operates on the Analog Watch like a customizable API, allowing users to query specific data from a listed smart contract via a GraphQL endpoint. Before you build a View, it’s important to be familiar with some essential tips about Views.

The best way to start deploying Views effectively is to follow the guidelines outlined on the “Best Practices for Listing Smart Contracts” page.

In addition to these guidelines, here are other best practices you need to follow when deploying Views on the Analog Watch:

1. Outline the aims and scope of your View.

Before creating a View, it’s crucial to clearly understand what you want to accomplish. This could involve filtering, aggregating, or performing calculations on the indexed data. Additionally, you need to define the scope of your View by deciding whether the View would operate on a single contract on a single chain, multiple contracts on a single chain, or multiple contracts across multiple chains.

Defining a clear purpose and scope for your View enables you to identify the relevant functions within the smart contract(s) that will assist you in reaching your goal.

2. Ensure the View Definition is defined properly.

The View Definition specifies all the data required to index and query a listed View on the Analog Watch. It serves as an entry point to your View and is deployed to the Analog Watch, as well as hashed to generate a hash ID. This ID can then be referenced to retrieve the View on the Analog Watch.

Here are some tips to consider when defining a View Definition:

• Always ensure that the appropriate smart contract is listed. Check to ensure that the listed smart contract is the right one by verifying its address and contract ABI.
• Ensure that the contract’s relevant function(s) you want to use for your View are published. Refer to this page to learn more about adding function(s) to a listed smart contract.
• Ensure you’ve entered the input function arguments if required for your View. You can test the query by clicking the “Test Query” command in the Console section to determine if your function(s) have errors. If any function(s) has a mistake, you’ll be prompted to review and correct the errors.

Avoid ambiguity in field names and measures.

Expose aggregatable numeric fields in a View with names distinct from measures to avoid confusion. You could hide these fields in the View Definition and create explicit measures. For example, if you want to display the “AVERAGE of ETH/USDT token across two DEXs,” then you cannot use a name such as “Mean Price” as a column name if any of the contracts on either DEX has this name as its column.

Using weird names, such as “Average of the token prices” for a measure, isn’t a good solution either. The best practice would be to import the field into the View Definition with some naming convention, then hide it and expose it as a measure.

Check to ensure you’ve removed useless columns.

Even if you're unsure which fields will be needed in your View Definition, aim to expose only the essential ones. For example, you could leave out high-cardinality fields, such as timestamps, that may only be required for technical reasons.

Reducing the number of exposed columns reduces the amount of data that Analog Watch indexes and handles, which is essential in enhancing the View’s performance.