Skip to content
This repository has been archived by the owner on May 17, 2024. It is now read-only.

Adding mutually-exclusive fields functional validation #25

Merged
merged 2 commits into from
Sep 4, 2017

Conversation

BrunoBernardino
Copy link
Contributor

@BrunoBernardino BrunoBernardino commented Aug 30, 2017

Adding mechanism to validate for mutually-exclusive fields and initial fields that are mutually exclusive

Fixes #21

Relevant Trello Card.

What this changes

  • Adds mechanism to validate against mutually-exclusive fields
  • Validates against inputFields that have children and list
  • Validates against inputFields that have children and dict
  • Validates against inputFields that have children and type
  • Validates against inputFields that have children and placeholder
  • Validates against inputFields that have children and helpText
  • Validates against inputFields that have children and default
  • Validates against inputFields that have dict and list
  • Validates against inputFields that have dynamic and dict
  • Validates against inputFields that have dynamic and choices

Log


Adding mutually-exclusive fields functional validation (f00a778)

Adding mechanism to validate for mutually-exclusive fields and initial fields that are mutually exclusive

Fixes #21


Adding more mutually-exclusive fields to the checks (fbac4a0)

Applying suggestions from code review.

Related to #25

Adding mechanism to validate for mutually-exclusive fields and initial fields that are mutually exclusive

Fixes #21
@BrunoBernardino BrunoBernardino self-assigned this Aug 30, 2017
@BrunoBernardino
Copy link
Contributor Author

@FokkeZB have I forgotten about any field combination?

@BrunoBernardino BrunoBernardino removed the request for review from FokkeZB August 30, 2017 14:25
@FokkeZB
Copy link
Contributor

FokkeZB commented Aug 31, 2017

@BrunoBernardino shouldn't children also rule out type? That's the only one that comes to mind.

@BrunoBernardino
Copy link
Contributor Author

Oh, that's a good point, but it'll just be ignored, not cause errors, right? I'm trying to prevent those that can cause errors, otherwise we should also remove placeholder and helpText since it won't display, but that seems unnecessary/overzealous, no? What do you think?

Copy link
Contributor

@ibolmo ibolmo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was really trying to think of better ways to structure this, and the closest I got was looking at: https://github.com/tdegrunt/jsonschema/blob/master/examples/all.js#L268 and https://github.com/tdegrunt/jsonschema/blob/master/examples/all.js#L315

Thinking it through, though, I think this is simpler (functional). Good test coverage, and straight forward code.

I've left some improvements, but nothing to block.

const errors = [];

_.each(inputFields, (inputField, index) => {
_.each(incompatibleFields, (fieldGroup) => {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What version of node are we running again? 6.x would allow us to use destructure:

_.each(incompatibleFields, ([first, second]) => {
    ...
});

if (definition[typeOf]) {
_.each(definition[typeOf], (actionDef) => {
if (actionDef.operation && actionDef.operation.inputFields) {
errors = errors.concat(collectErrors(actionDef.operation.inputFields, `${typeOf}.${actionDef.key}`));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

errors = [...errors, ...collectErrors(...)]


_.each(inputFields, (inputField, index) => {
_.each(incompatibleFields, (fieldGroup) => {
if (inputField.hasOwnProperty(fieldGroup[0]) && inputField.hasOwnProperty(fieldGroup[1])) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not sure if we need to worry about hasOwn but if so, let's use _.has which is just easier to read.

// https://stackoverflow.com/questions/28162509/mutually-exclusive-property-groups#28172831
// it was harder to read and understand.

const incompatibleFields = [
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is simpler indeed than the stackoverflow :).

Would it be helpful if we added comments on why the combinations are not available (comments would suffice)?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a good point, but screen estate is limited for the errors, there. Do you have any suggestions?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh I meant inside the code.

@FokkeZB
Copy link
Contributor

FokkeZB commented Aug 31, 2017

@BrunoBernardino I agree priority number 1 is preventing errors, but ideally our schema should reject any specification that is invalid because a developer clearly added the property expecting to get something, but whatever it is he doesn't get it and that may lead to frustration or T2 tickets.

Applying suggestions from code review.

Related to #25
@BrunoBernardino
Copy link
Contributor Author

Can you please check again and see if I missed something @FokkeZB ?

@BrunoBernardino
Copy link
Contributor Author

Also, while once this ships it'll generate schema errors for devs using these combinations of fields, since they weren't working as expected, I don't plan on making this release a major, just minor. Makes sense @bcooksey / @ZaneLyon ?

@ibolmo
Copy link
Contributor

ibolmo commented Sep 1, 2017 via email

@FokkeZB
Copy link
Contributor

FokkeZB commented Sep 1, 2017

LGTM @BrunoBernardino !

@FokkeZB
Copy link
Contributor

FokkeZB commented Sep 1, 2017

We may want to consider working with a separate upcoming-major branch (v3 now) to merge these breaking changes in. Then once we run into a urgent breaking change we ship that version, merge v3 into master and create a new major v4 branch. The only downside is that you need to merge master into the major branch every now and then.

@bcooksey
Copy link
Contributor

bcooksey commented Sep 1, 2017

@BrunoBernardino If you used one of these invalid combos, what happened in the editor? Did it throw errors? Or did it just look odd but still work? If apps could function, we may have to do this as a major release.

@BrunoBernardino
Copy link
Contributor Author

BrunoBernardino commented Sep 4, 2017

It didn't work well, but didn't throw errors. It seems we're agreeing on major, so that's what it'll be, then. There are no other breaking changes planned atm, so we don't need to hold this.

@BrunoBernardino BrunoBernardino merged commit 4fdab85 into master Sep 4, 2017
@BrunoBernardino BrunoBernardino deleted the feature-warn-on-mutually-exclusive-fields branch September 4, 2017 15:26
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants