Validation with sibling / full object data

[oranoran]

When evaluating whether a field should be shown in the admin panel, the condition function receives two arguments: the full object, and siblings of the current field. This is extremely useful and easy to use.

However the validate function, which is equally useful, doesn't receive these. This inconsistency is probably due to the fact that this function is not part of the admin configuration. But regardless of the reason, this is a problem, for example in the following use case:

• Say field B may be populated only if field A has a certain value. This can be easily supported in the admin console with condition, because the condition function on field B receives the value of field A.
• But in fact, it's hard to force the same limitation when the API is used rather than the admin console, because that's not covered by condition.
• And even in the admin console, in a variant of the same scenario, where field D must be populated whenever field C has a certain value - that can't be easily enforced, because the validate function on field D doesn't receive the value of field C.

It might be possible to do the validation with server-side pre-update and pre-create hooks, but this feels a bit of an overkill. Why not just pass the same parameters to validate as those being passed to condition? On the server side, the depth of the passed objects maybe be determined with another parameter, or maybe even just pass the siblings for simplicity - it's still much better than the current situation.

I saw there is a broader discussion of related topics in #236, but I think having a discussion that is too broad could mean that this will never get addressed... While a simpler and more limited solution, specifically for validation, could possibly be implemented rather quickly.

Thoughts?

[jmikrut]

Hey @oranoran — this suggestion makes a ton of sense and would be fairly quickly doable in code. I think there are only a few things to determine here:

1. To provide the validation functions with both siblingData and data, there will be a small client-side performance impact due to needing to reduce form state into siblingData / data each time a validation runs. I doubt it would be noticeable, especially because we debounce validations on fields where that is applicable, but still. Something to measure and keep an eye on. However, on the server side, there would be no performance impact which is great!

2. One of the bad parts here is that the validate function right now only takes one value, but it would need to take additional arguments: (value, siblingData, data) => boolean. This could get complex in the future if we need to add any additional arguments. We probably need to decide if we want to switch validation functions to accept a single object with args—like hooks and access control, or keep the argument parade going. Option 1 would be more future proofed but would be a breaking change obviously.

@DanRibbens @denolfe @oranoran what do we think?

[denolfe]

For 2, I think it'd be better to have validate accept a single object as that will offer more flexibility in the future. This will have the added benefit of being similar to condition and other functions like it.

[oranoran]

For 2, I would suggest to accept 2 parameters - the value, and everything else as a "relatedData" or "opts" object. That would be both compatible and powerful enough.

[jmikrut]

Good stuff. Personally I think what @oranoran is saying is the way to go because then we don't need to introduce a breaking change, and the pattern is still intelligible enough. First argument is the value which is what is needed in most validation use cases, while the second is an optional options argument with more info.

We'll get this slated in and get it built out. Great feature request!

[jmikrut]

Hi @oranoran — this is now deployed within 0.15.4 and documentation can be found here!

[DanRibbens]

Just a heads up—we had a bug in yesterdays release that is now fixed in 0.15.5.