Support MongoDB $jsonSchema

[bwgjoseph]

Is it possible to support it?

See mongodb-jsonschema

A sample

{ $jsonSchema: <JSON Schema object> }

{
  $jsonSchema: {
     required: [ "name", "major", "gpa", "address" ],
     properties: {
        name: {
           bsonType: "string",
           description: "must be a string and is required"
        },
        address: {
           bsonType: "object",
           required: [ "zipcode" ],
           properties: {
               "street": { bsonType: "string" },
               "zipcode": { bsonType: "string" }
           }
        }
     }
  }
}

If it does, I imagine I would use the same way I did before to display it

import JSONSchemaViewer from "@theme/JSONSchemaViewer"
import schema from "@site/static/schema/mongo.json"

<JSONSchemaViewer schema={schema} />

Thanks

[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 ;)

[bwgjoseph]

Thanks for the hint.

I suppose that if you are going to re-write into draft07, then probably don't have to use $ref anymore and directly return the object as is.

So I will just call

<JSONSchemaViewer schema={convertToDraft7(schema)} />

Tried to do a quick hack to get it working but wasn't able to, will try it again next time.

[bwgjoseph]

Also, I think it's a good idea to include FAQ section

[jy95]

@bwgjoseph Indeed, the final choice is yours like how you want to fetch your schema ;) .
You can directly return rewritedMongoDb in convertToDraft7 function so you don't have to care about $ref :

<JSONSchemaViewer schema={convertToDraft7(schema)} />

To be accurate, if I suggested to write that function into src/_convertToDraft7.tsx, it is to avoid Docusaurus trying to interpreting that as a route (see docs )

By default, any Markdown or JavaScript file starting with _ will be ignored and no routes will be created for that file (see the exclude option).

FYI : I fine-tuned the plugin (currently v1.2.1) so arrays are better handled. From what I saw in your previous issue, it might be handy ^^

[bwgjoseph]

You're too awesome.

Thanks for all the work done, appreciate it!

I will play around with it when I can!

[jy95]

Also, I think it's a good idea to include FAQ section

I added some extra documentation on the website : https://jy95.github.io/docusaurus-json-schema-plugin/
Let's said I was in the emoji mood ^^