Support MongoDB $jsonSchema about docusaurus-json-schema-plugin

[jy95]

Hello @bwgjoseph ,

Short answer :

Low priority for me atm.
A proper way to extend the best effort viewer with extensions of JSON Schema needs some reflexion first.
I would like to avoid rushing things that would leak to issues , breaking changes, ...

Why the low priority ?

• According to ajv, Draft-07 is the most widely used version and by consequence, draft-04 is deprecated & many packages don't even care about it anymore like the library I use for the Typescript types
• Viewer main targets are Draft-07 / Draft 2019-09 / Draft 2020-12, as expressed in the readme
• There are some backwards-incompatible changes between draft-04 & other versions, such as on exclusiveMaximum / exclusiveMinimum definitions
• Discussion about that specs on MongoDB forums : https://www.mongodb.com/community/forums/t/validation-using-latest-json-schema-version/2082
• ...

Long answer :

Open closed principle should be applied here.
MongoDB extended Draft 4 of JSON specs with 3 major differences :

1. $jsonSchema is their root element
2. exclusiveMaximum / exclusiveMinimum breaking changes definitions
3. Their bsonType (similar to type but with more )

For point n°1

You can use the jsonPointer option inside resolverOptions , such as :

import Schema from "@site/static/schemas/examples/refs/refOnRoot.json";
import JSONSchemaViewer from "@theme/JSONSchemaViewer";

const resolverOptions = {"jsonPointer": "#/definitions/user"}

<JSONSchemaViewer schema={ Schema } resolverOptions={resolverOptions} />

My example in documentation is a good illustration it already works.
If you wonder why this option already exists, well, I had that issue with some of my Draft 7 files I have in one of my other projects 🤐

For point n°2

In my own codebase, bunch of

// @ts-ignore
as boolean | number | undefined

to just cover that version. It seems to be an overhead just to support a single version ...

For point n°3

The hardest as many question aroses :

• Should I enable users to provide their own components to render their custom types ?
• Should I provide a default rendering if users don't provide a fallback one ?
• ...

So I will convert that issue into a discussion to see if other have this need that might help me reconsider my position.
Part of your request (the need for customization) is a track from which I would like other feedbacks: at least, on the internalization side of the labels I am ready ^^

PS : 1.2.0 is out. enhancements should be quite visible : feel free to share your feedback ;)