Can we use the new getOrThrow API in the loaders now (question about v2.22.0)?

[PaulRBerg]

hey @DZakh & team, this is a question about the new getOrThrow and getOrCreate methods introduced in v2.22.0, specifically, about this new behavior:

If the loader function fails on the first run, the error will be silently ignored. It may happen, depending on the entity, which will only be available on the second run. We don't want to abort indexing here, because it's a valid case.

Does this mean that we can use getOrThrow in the loader?

At the moment, we are doing this:

const loader: Loader<LoaderReturn> = async ({ context, event }) => {
  const watcher = await Store.Watcher.get(context, event.chainId);
  return {
    watcher,
  };
};

const handler: Handler<LoaderReturn> = async ({ context, event, loaderReturn }) => {
  const { watcher } = loaderReturn;
    if (!watcher) {
      throw new Error(`Watcher not loaded from the entity store: ${chainId}`);
    }
  // <--- snip --->
};

Can we replace this pattern with:

const loader: Loader<LoaderReturn> = async ({ context, event }) => {
- const watcher = await Store.Watcher.get(context, event.chainId);
+ const watcher = await context.Watcher.getOrThrow(context, event.chainId);
  return {
    watcher,
  };
};

And then, in the handler, can we know for sure that the entity is defined? (i.e. it is NOT SomeType | undefined but it is SomeType).

[DZakh]

Yes, you can replace it. It will have the same behavior as the example with the handler.

[PaulRBerg]

Good stuff. Thanks for confirming.

You might want to update your docs here.

I see a note about v2.22 but I think that the preamble of that section is confusing because it refers to the behavior of v2.21 and earlier.

Might be worth starting with the v2.22 explainer first, or adding subsections for v2.22

[DZakh]

Noted 👍

[PaulRBerg]

And a related question: is it alright to use getOrCreate in the loaders? Not sure if the function is meant to be used only in the handlers.

[DZakh]

You're right. After the change is out, a recommended approach will be to have everything in the loader function. This is not how it was initially intended, but this is the best way to write code that will be compatible with envio V3.

From our internal V3 thread:

[PaulRBerg]

How about renaming it to preparer in V3?

This will signal to Envio users that this is a new/more powerful feature than the original loaders

[DZakh]

We want to remove loaders completely and keep only handlers, which will behave like loaders.

[DZakh]

This should make many indexers faster by default. Although there's also a new mental model to consider that your handler runs twice, but we believe that it should be familiar to many Js/React users. We'll try to document it as much as possible.

[DZakh]

https://github.com/enviodev/hyperindex/releases/tag/v2.23.0 is released.