Rule not working in case of an array

General
1

I was doing a small POC over here and figured out that rule condition is not working if the rule is pointing to a variable outside the scope of the array. Is this by design or am I doing some mistake? Is there any way around such scenarios?

[original thread by shivgarg5676]

2

Hi @shivgarg5676. Thanks for providing a code example. Yes this is a limitation coming from our architecture where we only consider sub-schemas for certain elements like arrays. This has the upside that you don’t need to specify absolute paths in the detail schema, but has the downside that you can’t point outside of it.

For now you’ll need to use a custom renderer to resolve outside the array object.

3

[shivgarg5676]

Yea agreed. it would have been really difficult to specify the scope in case of arrays otherwise, as it contains multiple elements. But I have seen folks doing implementations like #/properties/b/$$/properties/c $$/properties/c where $$ represents the current element or subschema. By introducing a different deliminator for subschema we can get best of the both worlds. Your thoughts?

4

In theory we’re open to offer a way to point outside the current subschema. However I don’t really understand your suggestion though. How would the scope in this rule then look like? Maybe you can fork your codesandbox to showcase the idea.

Do you have an example where somebody used this $$ extension?

5

[shivgarg5676]

I was mistaken when I wrote #/properties/b/$$/properties/c as there could be no relation of b & c they both can be part of different arrays. Sorry about that.

But a possible implementation could be something like this.

Here $$ represents subschema. There can be other solutions as well as having an explicit flag.
this implement has a benefit that it can reference outside but
But it also has a drawback that it can not resolve cross-referenced nested arrays.
for that something like this #/properties/b/1/properties/c will be required.

Nevermind sorry, I got confused.

6

We could take a look at this again when we revisit the overhaul of ref-resolving to try to solve this limitation in a satisfactory way. For now I would stick with a custom renderer which is able to resolve outside the subschema.