fix: support nullable type arrays in visual editor

[dnio99]

Summary

• recognize JSON Schema nullable type arrays containing exactly one base type and null
• render and edit nullable objects, arrays, array items, and combinator options using their base editor
• preserve nullability and the original type-array order when fields are edited or their base type changes
• keep unions with multiple non-null types unsupported instead of silently simplifying them

Why

JSON Schema permits forms such as type: ["object", "null"], but the visual editor currently dispatches on a scalar type and cannot render these schemas correctly.

Validation

• npm test (58 passed, 2 existing todo)
• component test for nested nullable objects (3 passed)
• npm run typecheck
• npm run build
• Biome 2.4.15 check on all changed files

[shokurov]

@dnio99 thanks for your proposal.

I think it might make sense to discuss the approach you've taken in implementing nullability:

As per JSON Schema the recommended approach, as you correctly noted is type array, like ["string", "null"].

Type arrays are not supported in jsonjoy-builder, which is an obvious shortcoming.

However the type array can be used in multiple other scenarios, such as:

1. Flag in configuration (bool or object)

{
  "title": "Logging settings",
  "type": ["boolean", "object"],
  "properties": {
    "level": {
      "type": "string",
      "enum": ["info", "warn", "error"]
    },
    "file": {
      "type": "string"
    }
  }
}

2. "Single or collection" pattern

{
  "type": ["string", "array"],
  "items": {
    "type": "string"
  }
}

3. Mixed identifier type:

{
  "title": "Universal id",
  "type": ["string", "number"]
}

JSON schema standard itself is quite rich and flexible in these scenarios. It would be really beneficial to have opportunity to support them in future.

Your approach is trading flexibility for convenience. Yes, nullability is pretty much the most often used case to type arrays and convenience of having a single checkbox is great. However jsonjoy-builder, while aiming to be usable for ordinary users, still mostly adheres to the standard.

I think, this PR should not be accepted blindly without discussion on the architectural direction.

@dnio99 could you provide your real world usage scenario?

@lovasoa what's your take on this approach?

[lovasoa]

Yes, I think we should support type arrays first. Then we can discuss special casing null.

[shokurov]

@dnio99 I think we should close this PR as rejected. We will be happy to support a new PR, which would consider nullability as a special case of type array. Perhaps, this could be a visual extension of type dropdown allowing to select multiple types, even though limited to a case of "null + another type".