Skip to content

Clean up outdated parts and add more examples #585

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
moose-code merged 2 commits into from
Mar 5, 2025
Merged

Clean up outdated parts and add more examples #585

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
0758450
Clean up outdated parts and add more examples
DZakh Mar 5, 2025
84164d7
Fix links
DZakh Mar 5, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 0 additions & 9 deletions docs/HyperIndex/Advanced/reorgs-support.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -5,10 +5,6 @@ sidebar_label: Reorgs Support
slug: /reorgs-support
---

:::note
This feature, while functional and stable, is not optimized. If you choose to have this feature enabled, please be aware that historical indexing may slow down. We want to ensure blazing-fast indexing and are currently working on improving this.
:::

Chain reorganizations are handled automatically by HyperIndex, and are turned on by default.

To turn this feature off, you can set the ```rollback_on_reorg``` flag in your config.yaml to ```false```:
Expand All @@ -33,9 +29,4 @@ Important notes regarding rollbacks and reorgs:
- Reorg detection is guaranteed when indexing from a [HyperSync](/docs/HyperIndex/Advanced/hypersync.md) as the data source. However, indexing from a [custom RPC](/docs/HyperIndex/Advanced/rpc-sync.md) as a data source may have edge cases where reorgs can occur undetected.
- All entities defined in your schema and set/read in your handlers will be managed and rolled back in the event of a reorg. However, any additional side effects or caching used in your handlers cannot be accounted for.


:::info
Before Envio version V2.1.2, handling chain reorgs were turned on by default. Conversely, it's ```true``` by default if the reorg feature is not explicitly turned off in the config.yaml. In V2.1.3 and onwards, chain reorgs for indexers generated using the [quickstart](/docs/HyperIndex/contract-import.md) will be turned off by default with the following flag `rollback_on_reorg: false`
:::

---
7 changes: 5 additions & 2 deletions docs/HyperIndex/Guides/configuration-file.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -116,8 +116,11 @@ events:
- event: "Transfer(address indexed from, address indexed to, uint256 value)"
field_selection:
transaction_fields:
- "to"
- "from"
- "hash"
- "transactionIndex"
- "gasUsed"
block_fields:
- "parentHash"
```

## Environment Variables Interpolation
Expand Down
88 changes: 79 additions & 9 deletions docs/HyperIndex/Guides/event-handlers.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -29,7 +29,7 @@ Each event that you want to process requires that a handler be registered. These
Handler functions are called via:

<Tabs>
<TabItem value="typescript" label="Typescript">
<TabItem value="typescript" label="TypeScript">

```typescript
import { <CONTRACT_NAME> } from "generated";
Expand All @@ -40,7 +40,7 @@ import { <CONTRACT_NAME> } from "generated";
```

</TabItem>
<TabItem value="javascript" label="Javascript">
<TabItem value="javascript" label="JavaScript">

```javascript
const { <CONTRACT_NAME> } = require("generated");
Expand All @@ -51,7 +51,7 @@ const { <CONTRACT_NAME> } = require("generated");
```

</TabItem>
<TabItem value="rescript" label="Rescript">
<TabItem value="rescript" label="ReScript">

```rescript
Handlers.<CONTRACT_NAME>.<EVENT_NAME>.handler(async ({ event, context }) => {
Expand Down Expand Up @@ -124,6 +124,8 @@ It is recommended to add `# yaml-language-server: $schema=./node_modules/envio/e

### Context

#### Get entity

In your handler functions, you can access entities in the database via the asynchronous `get` function as shown below:

```javascript
Expand All @@ -134,6 +136,8 @@ The context also contains some logging functions that include the context automa

> Dev note: 📢 For indexers built using `ReScript`, use a lowercase for the first letter of `entityName` when accessing it via context (i.e., `context.user` instead of `context.User`).

#### Modify entity

In addition to the `get` function, which is a read-only action, two write actions are provided in the context:

- `set`
Expand All @@ -153,10 +157,76 @@ context.<ENTITY_NAME>.deleteUnsafe(<ENTITY_OBJECT>.id);

The `set` method is used to either create an entity or to update an existing entity with the values defined in the `entityObject`. The `deleteUnsafe` method is an experimental feature that allows you to remove an entity with a particular ID from the database and indexer memory. This is an **unsafe** function since there may be unexpected repercussions when a deleted entity is linked to another entity. It is your responsibility to delete/fix these references manually.

#### Update entity field

We don't have an `update` function in the context, but you can update an entity field by using the `set` function as shown below:


<Tabs>
<TabItem value="javascript" label="JavaScript">

```javascript
const poolManager = await context.PoolManager.get(
`${event.chainId}_${event.srcAddress}`
);
if (poolManager) {
context.PoolManager.set({
...poolManager,
txCount: poolManager.txCount + 1n,
totalValueLockedETH: poolManager.totalValueLockedETH
.minus(currentPoolTvlETH)
.plus(pool.totalValueLockedETH),
})
}
```

</TabItem>
<TabItem value="typescript" label="TypeScript">

```typescript
const poolManager = await context.PoolManager.get(
`${event.chainId}_${event.srcAddress}`
);
if (poolManager) {
context.PoolManager.set({
...poolManager,
txCount: poolManager.txCount + 1n,
totalValueLockedETH: poolManager.totalValueLockedETH
.minus(currentPoolTvlETH)
.plus(pool.totalValueLockedETH),
})
}
```

</TabItem>
<TabItem value="rescript" label="ReScript">

```rescript
let poolManager = await context.PoolManager.get(
`${event.chainId}_${event.srcAddress}`
);
poolManager->Option.forEach(poolManager => {
context.PoolManager.set({
...poolManager,
txCount: poolManager.txCount + 1n,
totalValueLockedETH: poolManager.totalValueLockedETH
.minus(currentPoolTvlETH)
.plus(pool.totalValueLockedETH),
})
})
```

</TabItem>
</Tabs>

:::note
For performance concerns related to `get` function calls in your handlers, refer to the [Benchmarking](/docs/HyperIndex/benchmarking) and [Loaders](/docs/HyperIndex/loaders) guides. These resources provide insights and solutions for optimizing performance.
:::

### Example of Registering a Handler Function for the `NewGreeting` Event

<Tabs>
<TabItem value="javascript" label="Javascript">
<TabItem value="javascript" label="JavaScript">

```javascript
let { Greeter } = require("generated");
Expand All @@ -183,7 +253,7 @@ Greeter.NewGreeting.handler(async ({ event, context }) => {
```

</TabItem>
<TabItem value="typescript" label="Typescript">
<TabItem value="typescript" label="TypeScript">

```typescript
import { Greeter, User } from "generated";
Expand Down Expand Up @@ -213,7 +283,7 @@ Greeter.NewGreeting.handler(async ({ event, context }) => {
```

</TabItem>
<TabItem value="rescript" label="Rescript">
<TabItem value="rescript" label="ReScript">

```rescript
open Types
Expand Down Expand Up @@ -264,7 +334,7 @@ It is a more advanced topic and can be covered in its section.
We expose the `config.yaml` data in the handler via `getConfigByChainId`. The below code snippets show how to access the `config.yaml` data in the handler and the available data:

<Tabs>
<TabItem value="javascript" label="Javascript">
<TabItem value="javascript" label="JavaScript">

```javascript
let { getConfigByChainId } = require("../generated/src/ConfigYAML.bs.js");
Expand All @@ -275,7 +345,7 @@ Greeter.NewGreeting.handler(async ({ event, context }) => {
```

</TabItem>
<TabItem value="typescript" label="Typescript">
<TabItem value="typescript" label="TypeScript">

```typescript
import { getConfigByChainId } from "../generated/src/ConfigYAML.gen";
Expand All @@ -286,7 +356,7 @@ Greeter.NewGreeting.handler(async ({ event, context }) => {
```

</TabItem>
<TabItem value="rescript" label="Rescript">
<TabItem value="rescript" label="ReScript">

```rescript
open Types
Expand Down
4 changes: 2 additions & 2 deletions docs/HyperIndex/supported-networks/any-evm-with-rpc.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -37,9 +37,9 @@ networks:
Can’t find what you’re looking for or need support? Reach out to us on [Discord](https://discord.com/invite/Q9qt8gZ2fX); we’re always happy to help!

:::info
the backbone of hyperindex’s blazing-fast indexing speed lies in using hypersync as a more performant and cost-effective data source to rpc for data retrieval. while rpcs are functional, and can be used in hyperindex as a data source, they are far from efficient when it comes to querying large amounts of data (a time-consuming and resource-intensive endeavour).
The backbone of HyperIndex’s blazing-fast indexing speed lies in using HyperSync as a more performant and cost-effective data source to RPC for data retrieval. While RPCs are functional, and can be used in HyperIndex as a data source, they are far from efficient when it comes to querying large amounts of data (a time-consuming and resource-intensive endeavour).

hypersync is significantly faster and more cost-effective than traditional rpc methods, allowing the retrieval of multiple blocks at once, and enabling sync speeds up to 1000x faster than rpc.
HyperSync is significantly faster and more cost-effective than traditional RPC methods, allowing the retrieval of multiple blocks at once, and enabling sync speeds up to 1000x faster than RPC.
:::

---
4 changes: 2 additions & 2 deletions docs/HyperIndex/supported-networks/index.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -10,9 +10,9 @@ HyperIndex natively supports indexing any EVM blockchain out of the box. As a de
HyperIndex also supports data indexing on [Fuel](/docs/HyperIndex/fuel/fuel.md).

:::info
the backbone of hyperindex’s blazing-fast indexing speed lies in using hypersync as a more performant and cost-effective data source to rpc for data retrieval. while rpcs are functional, and can be used in hyperindex as a data source, they are far from efficient when it comes to querying large amounts of data (a time-consuming and resource-intensive endeavour).
The backbone of HyperIndex’s blazing-fast indexing speed lies in using HyperSync as a more performant and cost-effective data source to RPC for data retrieval. While RPCs are functional, and can be used in HyperIndex as a data source, they are far from efficient when it comes to querying large amounts of data (a time-consuming and resource-intensive endeavour).

hypersync is significantly faster and more cost-effective than traditional rpc methods, allowing the retrieval of multiple blocks at once, and enabling sync speeds up to 1000x faster than rpc.
HyperSync is significantly faster and more cost-effective than traditional RPC methods, allowing the retrieval of multiple blocks at once, and enabling sync speeds up to 1000x faster than RPC.
:::

If a [network is supported](/docs/HyperSync/hypersync-supported-networks) on HyperSync, then HyperSync is used by default as the data source. This means developers don't additionally need to worry about RPCs, rate-limiting, etc. This is especially valuable for multi-chain apps.
Expand Down