Optional schema validation

[kittaakos]

What it does

Made the preference schema validation optional.

• It costs time at startup, and it only logs warnings.
• Can be disabled with the shouldValidateSchema preference config.

This PR contains a commit with an example. I can drop the example commit from the PR.

How to test

Start the app, and you will see these in the log:

2022-05-21T16:37:49.331Z root INFO Preference schema validation is disabled.
2022-05-21T16:37:49.331Z root INFO Preference schema validation is disabled.
2022-05-21T16:37:49.331Z root INFO Preference schema validation is disabled.
2022-05-21T16:37:49.332Z root INFO Preference schema validation is disabled.
2022-05-21T16:37:49.332Z root INFO [b102b270-04b0-4af7-93f7-d8b1f0e2c9ef][vscode.css-language-features]: Loaded contributions.
2022-05-21T16:37:49.332Z root INFO [b102b270-04b0-4af7-93f7-d8b1f0e2c9ef][vscode.debug-auto-launch]: Loaded contributions.
2022-05-21T16:37:49.333Z root INFO [b102b270-04b0-4af7-93f7-d8b1f0e2c9ef][vscode.debug-server-ready]: Loaded contributions.
2022-05-21T16:37:49.333Z root INFO Preference schema validation is disabled.
2022-05-21T16:37:49.334Z root INFO [b102b270-04b0-4af7-93f7-d8b1f0e2c9ef][vscode.docker]: Loaded contributions.
2022-05-21T16:37:49.334Z root INFO Preference schema validation is disabled.

Please review. Thank you! 🌻

Review checklist

• As an author, I have thoroughly tested my changes and carefully followed the review guidelines

Reminder for reviewers

• As a reviewer, I agree to behave in accordance with the review guidelines

[msujew]

@kittaakos I'm alright with having an option to disable schema validation, but having it behind an overridable method seems overengineered for me. What do you think about a frontend config option instead?

[kittaakos]

I'm alright with having an option to disable schema validation

Thank you!

What do you think about a frontend config option instead?

Sure. Do you mean FrontendApplicationConfig?

[msujew]

Do you mean FrontendApplicationConfig?

Yes exactly. It allows downstream users to easier disable those validations, since the json can be easily modified during the build process. Having something like this locked behind code basically only allows manual manipulation, which is then app-wide.

[colin-grant-work]

The time savings here are substantial. In my comparison runs, 3.8ms was spent in doSetSchema without validation, 124.4ms with validation. I support @msujew's suggestion that the toggling be moved to FrontendApplicationConfig unless we can imagine a use-case where some condition might be applied rather than a blanket true or false?

[kittaakos]

Thank you for the feedback. I updated the PR. Please review.

[kittaakos]

Please review.

[msujew]

The changes look good to me! Don't forget to revert your test commit before merging 👍

[kittaakos]

Don't forget to revert your test commit before merging 👍

Do you want me to drop the examples customization?

[msujew]

@kittaakos Yes, more specifically 43456de, after all we want to have validations for our example app (for us to able to test that the validation works as expected)

[kittaakos]

Could you please merge if all looks good? Thank you!

[colin-grant-work]

@kittaakos, it looks like you still have committer's rights, so you're welcome to do merges yourself, once a PR is approved.

[kittaakos]

it looks like you still have committer's rights

No, I do not have it 😊 The Eclipse page is misleading. But anyway, thanks for checking it and chiming in for the PR.