It’s not a good design for readability. The only saving grace of YAML is it creates readable code. The torture of counting spaces and misaligning code is partly made up, by the fact you can read it.
There seems little point in saving Lovelace GUI in mangled YAML might just as well leave it in Json and add an import / export option on each card. Hand coded YAML could then be imported back into the GUI for prototyping and editing. This is just the worst of both worlds.
Not sure if your reply is to me but I only use the GUI to see what something looks like quickly - I make all changes in YAML and cut/paste from there - so best of both possibilities
I’m not working on the internals, but I’m fairly sure what everyone here refers to as “by design” should actually be called “result of a technical limitation”.
You said you are a programmer. Hence you’ll understand the following:
YAML is nothing more than a visual representation of JSON in a format that’s more readable to humans. With the addition, that YAML by itself supports comments and maintains its order. However: JSON does not preserve order, and it does not support comments. What happens when doing all that YAML stuff in the UI is, that it takes your YAML and converts it into JSON (because that’s the native format that is being used internally). For obvious reasons it is simply not possible to get back to your organized YAML once the conversion to JSON has been executed. And that’s not because the devs want it to be like that. It’s just how YAML-parsers work.
Thank you for comprehensive responce.
Yes, the limitations sound indeed more justifying than the design.
But then the fact of using json should be questioned at least the way how it is done right now.
Json is data format. yaml is a language. you cannot simply cast yaml to json and devs should know that and about consequences.