feat(input_schema): Resource properties

[MFori]

Update of input schema based on apify/apify-docs#1261:
New properties in schema: resourceProperty and resourceArrayProperty
To distinguish between resource properties with resourceType and string/array properties custom validation is done in validateField (because of clash on same type)

Input ui to support this schmena is ready here: https://github.com/apify/apify-core/pull/18093

[drobnikj]

Looks good, just have two idea on how we can simplify.

[drobnikj]

Nit: It looks the title, description, nullable, sectionCaption, sectionDescription appear in all definition. Could we move these to special definitions?

{
...
    "definitions": {
        "baseProperty": {
            "type": "object",
            "properties": {
                "title": {"type": "string"},
                "description": {
                    "type": "string"
                },
                "nullable": { "type": "boolean"}
            },
            "required": ["title", "description"]
        },
        "resourceProperty": {
            "allOf": [
                {"$ref": "#/definitions/baseProperty"},
                {
                    "properties": {
                        ...the rest of props on top of baseProperty
                    }
                }
            ],
            "required": ["type", "title", "description", "resourceType"]
        },
        ...
    }
...
}

[gippy]

I like the "allOf" base property Kuba has. Otherwise preapproving

[MFori]

The solution with baseProperty and allOf has some issues:

• additionalProperties doesn't work for this, but yeah we can use unevaluatedProperties in this case
• we are accessing field property.properties in our custom validation and this property wouldn't have this property and additional transformation will be needed to check if the property have some field or not and then merge properties from the allOf items.
• the baseProperty is still validated and will be need to filter it out in our custom validation
• lot of tests fails also on other issues then the points above and needs to be resolved

So it's possible but do we really need it in this case with the increased complexity of validation?
@gippy @drobnikj

According to: why not in condition? I prefer condition without not and switch else branches, it will make it more readable.
If I switch the else branches lot of our tests fails I am on it and trying to figure out what's going on there

[gippy]

The solution with baseProperty and allOf has some issues:

• additionalProperties doesn't work for this, but yeah we can use unevaluatedProperties in this case
• we are accessing field property.properties in our custom validation and this property wouldn't have this property and additional transformation will be needed to check if the property have this field or not and then merge properties from the allOf items.
• the baseProperty is still validated and will be need to filter it out in our custom validation
• lot of tests fails also on other issues then the points above and needs to be resolved

So it's possible but do we really need it in this case with the increased complexity of validation? @gippy @drobnikj

According to: why not in condition? I prefer condition without not and switch else branches, it will make it more readable. If I switch the else branches lot of our tests fails I am on it and trying to figure out what's going on there

I liked the idea because it reduces repetition of the schema, but if it's at the cost of increased complexity of the schema, then I do not mind the current solution where the properties are repeated.

[MFori]

Nit: why not in condition? I prefer condition without not and switch else branches, it will make it more readable.

@drobnikj I was able to remove this condition at all by updating our custom validation and moving some tests from input_schema_definition.test.ts to input_schema.test.ts because the second one uses our validation but the first one doesn't.