This plugin could display constant values more prominently

[gnidan]

Generated friendly names (used by SchemaItem) are really handy and quite flexible, but I notice that they miss the opportunity to display a const value inline, requiring readers to drill down into the full SchemaItem details content to see the constant value.

This seems like the sort of thing that does not warrant an extra click, so I recently swizzled this behavior into my own schema docs. I figured I would suggest this change here in case you agree that it's a useful default for all users of your plugin.

See screenshot (ironically I now ask you to click)

[jy95]

Hello,

Indeed, GenerateFriendlyName took me a while to design and I'm quite pleased with the result.
It doesn't mean improvements couldn't be done ;)

The constant case could be anything.
You likely remember our discussion in the design of ValueComponent in #224 ? const could be :

• A string
• A number
• A boolean
• An array
• An object
• ...

I don't think that for objects {"prop1": "lol", "prop2": [false] } or complex array of multiple types like [1,"bob", false] putting it in summary would help understanding. So some kind of clear rules / choices should be made, for example :

1. Should I include the type across the const value (like string = "bug") or not ( "bug") ?

Less is usualy better - seeing "alias" with the quotes raises attention that it is a constant string (same for other types)

2. Should I rather make const more visible by example having a constant text in some kind of color like the required I have in summary ?

For example, for the two cases I explained that having them in summary could be less understandable

3. What about complex cases ?

For the sake of demonstration, let's start from the tuples example ( https://jy95.github.io/docusaurus-json-schema-plugin/docs/demo-viewer/array/tuples ) where we add some const and put it under some nested levels

For the being time, I do like the idea I developed in n°2 as regardless of the value itself, it would trigger attention.

[gnidan]

1. Should I include the type across the const value (like string = "bug") or not ( "bug") ?

I think you're right that less is better - with the quotes, the string part is unnecessary. (And if it's type: ["string", "number"] with a const: "...", well, does the enumerated type matter anyway? :)

2. Should I rather make const more visible by example having a constant text in some kind of color like the required I have in summary ?

I tried this and it seemed a bit cluttered, but I do think it would be nice if it said "constant" somewhere in that summary line. Maybe without the type being listed, the word "constant" would fit more nicely.

For the being time, I do like the idea I developed in n°2 as regardless of the value itself

For my use case, I definitely want the value to be apparent without clicking - my schemas use a discriminators pattern (you may have seen how I override AllOfSchema for allOf: [{ if, then }, ...] as a special case), so I want to make sure that when someone sees a discriminated subschema, they know the discriminator value immediately.

[jy95]

@gnidan Could you give a look to #242 and see how it goes ?

You have an example of the new "constant" summary on required page. For the rest, use the playground . (I added the case of a single item value of enum as well)

[gnidan]

Looks perfect! If you release this, I can get rid of my customization for it entirely :)

Thank you!

[jy95]

@gnidan Code merged into main right now - release should be out in a couple of minutes while I am going to sleep ^^

[gnidan]

Nice. I wish robots would do my work while I sleep :D