[dasc] Support add / remove child objects

[auniverseaway]

As an author, I would like the ability to work with my singleton child objects in a way that is consistent with the add / remove array feature.

Criteria of acceptance

1. Ability to add an object
2. Ability to remove an object
3. Leans on validation framework for errors

Additional context

I'm seeing a theme here that for now, we will let authors shoot themselves in the foot and we will lean on the validation framework to tell them what should be done. This will get us out of having to build additional UIs around telling an author, "I'm sorry, this is a required field." We let them remove, and we lean on the foundational validation UI to handle when something is not valid. They can then, again, use existing UI affordances to add a required field back.

[kozmaadrian]

If I understand correctly, this refers to the actions I initially implemented, allowing the author to activate objects within the JSON structure.

If that’s the case, I would suggest taking a pragmatic approach: in my opinion, this feature can either be postponed or not implemented at all.

In the recent refactoring, I completely removed this functionality because I concluded that the JSON output should remain as close as possible to what the schema defines. The only exception would be arrays, since we cannot determine in advance how many items are required.

Providing an option to activate or deactivate object structures could lead to unexpected usage patterns and result in different JSON structures being generated from the same schema.

If this is truly a requirement, I would recommend implementing it later, once we see clear evidence that it delivers real value.

Until then, we could simply render the complete hierarchy, regardless of whether a schema item is marked as required.

---

One caveat: schemas that use $ref may introduce circular references. In such cases, my latest approach was to add a safeguard that limits rendering depth when circular hierarchies are detected.

In general, we should discourage customers from creating overly complex schemas with deeply nested or circular structures. There should always be a better design approach that avoids such “monster” structures.

[kozmaadrian]

I believe we can proceed with closing this ticket.