Support for allOf and if statements

[akshaypatidar1999]

We have json schema containing allOf and if keywords. Currently if we generate README we get empty object for config. Can we add support for these keywords as well.

{
  "type": "object",
  "properties": {
    
    "key": {
      "type": "object",
      "properties": {
        "prop1": {
          "type": "string",
          "enum": [
            "v1",
            "v2"
          ]
        },
        "config": {
          "type": "object"
        }
      },
      "allOf": [
        {
          "if": {
            "properties": {
              "prop1": {
                "const": "v1"
              }
            },
          },
          "then": {
            "properties": {
              "config": {
                "properties": {
                  "prop2": {
                    "type": "boolean"
                  }
               }
              ,
              "additionalProperties": false}  
            }
          }
        },
        {
          "if": {
            "properties": {
              "prop1": {
                "const": "v2"
              }
            },
          },
          "then": {
            "properties": {
              "config": {
                "properties": {
                  "prop3": {
                    "type": "boolean"
                  }
                },
                "additionalProperties": false
              }  
            }
          }
        }
      ]
    }
  },
  "additionalProperties": false
}

[marcusolsson]

Hey! I'd be happy to add support for this if we can figure out what the resulting Markdown output would look like.

The way I see it, we have two different schemas for config, so they should probably have their own sections. This feels like the simplest way, since you could just generate a separate schema for each then statement. We'd need to generate unique anchors for each version.

## Properties

| Property | Type           | Required | Description |
|----------|----------------|----------|-------------|
| `key`    | [object](#key) | No       |             |

## key

### Properties

| Property | Type                | Required | Description                      | Condition |
|----------|---------------------|----------|----------------------------------|-----------------------|
| `config` | [object](#config-1) | No       |                                  | When `prop1` is `v1`. |
| `config` | [object](#config-2) | No       |                                  | When `prop2` is `v2`. |
| `prop1`  | string              | No       | Possible values are: `v1`, `v2`. |                       |

### config-1

| Property | Type | Required | Description |
|----------|------|----------|-------------|
| prop2    | bool |          |             |

### config-2

| Property | Type | Required | Description |
|----------|------|----------|-------------|
| prop3    | bool |          |             |

Another alternative would be to how multiple tables under config, but that would mean that we'd need to reference a "parent" schema. I think this may look nicer, I worry that it'll become complicated for more complex expressions.

## Properties

| Property | Type           | Required | Description |
|----------|----------------|----------|-------------|
| `key`    | [object](#key) | No       |             |

## key

### Properties

| Property | Type                | Required | Description                      |
|----------|---------------------|----------|----------------------------------|
| `config` | [object](#config)   |          |                                  |
| `prop1`  | string              | No       | Possible values are: `v1`, `v2`. |

### config

Conditions:

- `key.prop1` is `v1`

| Property | Type | Required | Description |
|----------|------|----------|-------------|
| prop2    | bool |          |             |

Conditions:

- `key.prop1` is `v2`

| Property | Type | Required | Description |
|----------|------|----------|-------------|
| prop3    | bool |          |             |

Another option is to add documentation to each property, but it'll have the same challenge as the second approach, that you'd need to reference a parent property.

## Properties

| Property | Type           | Required | Description |
|----------|----------------|----------|-------------|
| `key`    | [object](#key) | No       |             |

## key

### Properties

| Property | Type                | Required | Description                      |
|----------|---------------------|----------|----------------------------------|
| `config` | [object](#config)   |          |                                  |
| `prop1`  | string              | No       | Possible values are: `v1`, `v2`. |

### config

| Property | Type   | Required | Description | Condition           |
|----------|--------|----------|-------------|---------------------|
| prop2    | bool   |          |             | `key.prop1` is `v1` |
| prop3    | bool   |          |             | `key.prop1` is `v2` |
| prop3    | string |          |             | `key.prop1` is `v3` | <-- Example of where property changes type depending on prop1.

[akshaypatidar1999]

Yes the second output looks good. However I think it will be difficult to generate documentation for allOf, any, if etc keywords. Some complications that I can think of

• There can multiple conditions in a single if statement based of const, minimum, pattern etc
• allOf can contain schemas other if for which we need to merge some schemas
• The root schema may have some properties as well and then an allOf with some conditional properties, in this case, we have to merge the root schema with the conditional schemas.
• required can also be based on condition

Though I won't need them, the library should also support them. I will also be happy to contribute.

[marcusolsson]

I'd be happy to review a contribution for this. I think most importantly, it shouldn't affect output for users who don't use these features.

I'm happy to accept a small PR that solves your specific problem. But if you want to work on a more general solution, I think let's first create a PR with a series of tests and their corresponding outputs, like the ones already in the repo.