Get schema values synchronously from the AST

[jdesrosiers]

In @hyperjump/json-schema, you can compile a schema once and use that compiled schema to validate against many instances much more efficiently. The compile step is asynchronous and the interpret step is not. I'd like to make returning the result from getErrors an output option for the interpret step, but I can't because getErrors is asynchronous. That's why I added the validate function here (#203) for now where the interpret step can have a different API.

I want to find a way to make the getErrors function synchronous so it can be used in @hyperjump/json-schema.

The asynchronous part is getting values from the schema. Those values should all be in the compiled schema AST. So, it should be possible to build something to get values synchronously from the AST instead of getSchema/Schema.value.

[Ahmedmhmud]

I agree with you, there is no need to getting values for the schema while we have the compiled AST already there.
We can add a small AST resolver built once per compiled schema. It will create a fast lookup index keyed by schemaLocation (and parent location for sibling keywords) so error handlers can synchronously fetch the compiled keyword value they need. So the resolver walks AST once, stores the value of the location, then handlers just do sync reads.

After that, flipping to sync logic is the easy part: We convert handlers to use the resolver, then remove await from getErrors and its call sites. This gives us a sync error path while keeping behavior the same.

If you want, I can work on it.

[srivastava-diya]

So, it should be possible to build something to get values synchronously from the AST instead of getSchema/Schema.value.

I totally agree with this and @Ahmedmhmud's suggestion above, Building a synchronous lookup utility that reads directly from the AST is the best way forward.
Here is how I imagine the implementation would look

1. During the schema compilation phase, we will build a simple map having schemaLocation as the keys.
2. This map would contain all the valid locations as keys along with the keyword associated with it as values, that would make our key-value pair.
3. When the getErrors handlers iterate over the errors, instead of doing await getSchema(...), we can just do a synchronous ASTLookup.get(schemaLocation)
4. This hopefully would help us remove all await keywords from the error handlers, making getErrors a synchronous function .

I am happy to collaborate on this one.

[jdesrosiers]

A function to look up the value from the AST would be useful, but I'm not sure building an index is necessary. We only need to do the look up for errors, which are usually a small number and getting the value from the ast shouldn't be too expensive. Some schemas are quite large which means that building the index could be more expensive than doing a few lookups. Especially if there aren't any errors, which means we'd be building an index and never using it.

It also occurs to me that we'll want to rethink how we look up sibling keywords like minContains/maxContains. If we have access to the AST, it simplifies that look up.

I'm going to assign to @Ahmedmhmud, but it would be great to see you two collaborate on the solution.

[animeshsahoo1]

I actually did similar stuff while building a JSON Schema language server where I needed to read schema values synchronously during completion and hover. I ran into the exact same issue getSchema being async made it expensive to call repeatedly for each location.
My approach was to cache the result keyed by schema URL after the first fetch, since I have tested it on big schemas there is some overhead in time and space taken, in the language server use case it was powering a lot of features so a index was necessary but here, I would agree with jason to not have a full Index.

[Ahmedmhmud]

Hi @jdesrosiers , @srivastava-diya
I found a solution for sibling keywords lookup by another function that takes the current schemaLocation, moves to the parent AST node, and finds sibling keywords there directly.

I apologize @srivastava-diya , I was intending to leave some of the refactor work but I totally forgot, I also noticed that the example in the readme file is now not right about async schema reads so maybe you can update it.