alternative, non-breaking: `skipDataResolution` and `getRawSchema`

[acao]

this would be the non-breaking alternative to #41, exposing a new method that bypasses data resolution - this would be very handy for autocompletion/hover/etc in IDE tools, where we often don't even have a value yet, but still need to retrieve the targetSchema for a pointer

here is a real world use case:

the package.json schema json for exports fields includes a description field and other metadata that isn't accessible with getSchema, even if a value is provided! here we patched the library to get the desired effect, but it would be bad OSS library practice to ship with a patched version of your library of course

[sagold]

Hi Rikki,

thank you for your feedback and contribution. I am pretty sure we can solve you request, highly likely with this merge request.

I would propose to close PR #41 because it breaks the function's interface. The expectable return type should be a json-schema of the requested location (json-pointer) or an error. Returning a schema for a location in-between would make this function very hard to consume.

Introducing a configuration option in step is okayish and having a separate helper getRawSchema sounds like a very good approach to me. As an alternative to this, I am currently investigating the returned error as it could be extended to hold the partial json-pointer path and its schema (oneOf). This would give a consumer the ability to further process the error for the same results. How would you feel about this?

I am currently investigating some inconsistencies in returning errors from getSchema. To unblock yourself, you could pass your #41 getSchema function to the draft-config.

[sagold]

@acao regarding codemirror json-schema completion and tooltips, maybe there are some helpful insights comparing our solutions https://github.com/sagold/json-editor/tree/main/packages/rje-code-widgets/src/lib/jsonwidget

The styling is off, but it seems to solve the same problem in a different way: https://sagold.github.io/json-editor/?path=/story/packages-rje-code-widgets-jsonwidget--primary

[acao]

hey @sagold, awesome stuff! i see that yeah, areas where we made similar and very different choices. coupling with react is a good idea for usability, but in our case, we decided not to make ours react dependent, because we are using this mode with angular, vue and react in various projects, and the users of graphql need a js library independent mode as well

[sagold]

@acao on the following branch getSchema and JsonError-data has changed to support your request: https://github.com/sagold/json-schema-library/blob/feature/get-schema-error-information/test/unit/getSchema.test.ts#L416

• Each JsonError now includes the location, schema and value of the error (or last resolved location for getSchema) consistently
• getSchema supports an option withSchemaWarning: true that also returns an error if a valid property without a schema was found at that location

Basic example to always receive the innermost schema that could be resolved:

let lastResolvedSchema = draft.getSchema({ pointer: pointerToResolve, withSchemaWarning: true });
if (isJsonError(lastResolvedSchema)) {
  console.log("schema location", lastResolvedSchema.data.pointer);
  lastResolvedSchema = lastResolvedSchema.data.schema;
}

This approach adds support to continue working with error-data in all cases, which I would feel more comfortable with. Feel free to give feedback on this.

Update For one-of-errors oneOf-schema is exposed additionally on the error data (@see testcase)

if (lastResolvedSchema.code === "one-of-error") {
  console.log(lastResolvedSchema.data.oneOf);
}

[acao]

awesome @sagold , this is exactly what we were hoping for!

[sagold]

@acao Thank you for your feedback. The changes have been published with json-schema-library@v9.0.0. Please raise an issue if you encounter any problems with getSchema or the upgrade.