Handle const like enum with only one option

[navytux]

By definition const: xxx is equivalent to enum: [xxx] : https://json-schema.org/draft/2020-12/json-schema-validation#name-const , so e.g. for

"abc": {
  "type": "string",
  "const": "ABC"
},
"def": {
  "type": "string",
  "enum": ["DEF"]
}

abc and def fields should be handled in the same way via select with only one item.

Fixes #1428

Q	A
Is bugfix?	✔️
New feature?	✔️
Is backward-compatible?	✔️
Tests pass?	✔️
Fixed issues	#1428
Updated README/docs?	❌
Added CHANGELOG entry?	❌

[schmunk42]

There are a lot of changes in the test itself, see https://github.com/json-editor/json-editor/pull/1446/files#diff-a58cc456b73da808d706059b06e26d464924feb9ee3f469e44fed59923a30c02

Were the tests wrong?

CC: @germanbisurgi

[navytux]

@schmunk42, thanks for feedback.

Yes, those oneOf-2 and anyOf-2 tests needed to be changed, because those tests work on schemas with const and now const is automatically handled well. So instead of generating an error for e.g. oneOf subitem with const, such subitems are now automatically instantiated with their const value preselected. Previously those two tests were expecting const cases to emit errors, and now there is no error due to const-related behaviour change.

[navytux]

( here is the schema used in oneof-2 test: https://github.com/json-editor/json-editor/blob/67f29f49/tests/pages/oneof-2.html#L23-L67 )

[navytux]

@schmunk42, @germanbisurgi, do you think you could review this patch, or is there something wrong with it?

Offhand I would say this patch is much simpler compared to e.g. $ref resolver fixes, and it should be relatively straightforward to review.

Thanks beforehand for feedback,
Kirill

[schmunk42]

@navytux Sorry for that. We'll try to find time next week.

@germanbisurgi Please have a look, especially the changed tests ... but we might have checked a bug :)

[navytux]

Thanks, @schmunk42.

[UzairNoman]

I am facing the exact same issue where I have a select input and there is only one option:

this was working fine until i update my json schema to draft-07.

[navytux]

Hello @schmunk42 and @germanbisurgi.

Would you please have a look at this patch?

Basically it adjusts the editor to do what JSON-schema specification literally requires conformant implementations to do:

treat `const` as `enum` with single value

( https://json-schema.org/draft/2020-12/json-schema-validation#name-const )

So from that point of view this patch and adjustments to the tests should be obviously correct.

This patch was posted here back in December, but I see that in January another test was added that expects that it is possible to arbitrarily edit fields with const via UI:

febb98a6 (part of #1459)

which, from the point of view that "const is equivalent to enum with single value" is also incorrect and should be reworked, since e.g. for a select on enum: [true], it is not possible to input via UI anything but true.

On my side I prefer to get at least some high-level feedback first, before delving into any code rework, if at all.

I also understand that our pre-history on #1385 might be an issue. When I started my journey into JSON-schema world I was complete newbie and did not realize that in my case the editor will get already resolved schema and so there won't be the need to handle $ref inside the editor for me. So I first tried to fix all the encountered issues, but if you ask me, $ref parsing really needs a clean rewrite and is hard to consistently fix incrementally. So I've put that on hold first, and then, after realizing that I don't need $ref support from the editor, made a clear statement that I'm no longer actively looking into that issue. I appologize if my silence on #1385 might have created bad feelings on your side and caused your silence in hereby PR in return. I'm sorry for that.

Regarding changes themselves I would say that hereby const handling is different story though - it fixes aspect of core part of JSON-schema specification and the lack of the fix is causing real issues.

So I would appreciate if const topic could get your attention, and, one way or another we could add support for const in the way that JSON-schema specification describes.

Thanks beforehand for feedback,
Kirill

[germanbisurgi]

Hi @navytux, i am currently reviewing this your PR. The implementation looks good to me. I have to take a deeper look at the tests changes. Just wanted to add feedback at the moment.

[navytux]

Thanks, @germanbisurgi.

[germanbisurgi]

This will bring a minor breaking change in that the default keyword will be ognored, for example:

"string": {
  "title": "Some string",
  "type": "string",
  "const": "test",
  "default": "not in const"
}

"not in const" will be ignored and never shown.

Otherwise it looks good to me. The master branch should be merged into this PR before we merge it.

@schmunk42 Do you think it would be a good idea to add this feature behind a option like, "const_to_enum"?

[germanbisurgi]

@navytux This is ready to merge this, but there is a small conflict. could you resolve it in your branch please?

[germanbisurgi]

So, i resolve the merge conflict and fixed some linting errors introduced by myself (no linting in GitHub editor) but it has still test not passing. @navytux could you check on this and update code?

[navytux]

@germanbisurgi thanks for feedback and updating the branch, and @schmunk42 thanks for approving this PR.

I'm currently travelling and will try to have a look to finalize this PR in several days.

Sorry for the delay, and thanks, once again,
Kirill

[germanbisurgi]

Hello @navytux, upon further exploration of the 'const' topic, we've decided to pursue an alternative approach to ensure better backward compatibility for this feature, while retaining the integrity of the existing tests. You can review the PR here: #1555. Your input on this would be greatly appreciated.

[navytux]

@germanbisurgi, thanks for doing the alternative patch. #1555 works for me.