Hey Jack,
Thanks for your thoughtful response! I hope the team will review this feature request, as I believe it would make things a lot more DRY. I tend to rely heavily on variables and configurations to define things, simply because typing is faster than clicking and dragging. That’s essentially the motivation behind this suggestion.
What I meant by "three ways to construct the form" is that there are three distinct code blocks used to define the form: JSON Schema, UI Schema, and Default Form Data. I believe these could be merged into a single schema/config to keep things more centralized and better aligned.
Regarding "finding the exact same properties for fields as in the UI," my point was that any field property available in the default UI—such as "disabled," "width," or other attributes—should seamlessly integrate into the JSON Schema Form's list of options. This way, they match up directly, rather than requiring additional specifications like "ui:emptyvalue," which feels inconsistent.
Another example is "aligning labels to the left," which, as far as I could tell, isn’t easily replicated. I was referring to positioning labels to the left of the input box, making them inline rather than stacked on top of each other.
Unfortunately, I can’t share a screenshot, as I’m not using this method at the moment due to these incompatibilities.
In conclusion, building this feature from the ground up would ensure better consistency with the UI-native way of constructing forms. While it’s likely a significant undertaking, it would help users define their forms in a more structured and programmatic way.