How to keep # comments in frontend YAML files?

Configuration
19

You’d edit the card via the ui, which would cause the json to get out of sync with the raw yaml containing comments.

20

Well…. I meant: when i edit card in UI and i hit “save” whole thing is converted to json (so far so good). BUT… why wouldn’t be possible to keep that yaml with all comments and when compiling just left out comments ? So when i re-open my yaml comments would be still there.

1 Like
21

The whole thing is stored in JSON, there’s no conversion. There’s a conversion to yaml when you switch to yaml mode.

HeyImAlexs meta tag idea is the only way to solve this as the built in json lib for python & js do not support json5. So all we’d need is someone to take the lead and add a PR.

22

But there must be some sort of “conversion”… since editing format of lovelace UI is not json…

23

…

24

Yeah, i understand that part. But, what i don’t quite get is how come that, as you say, in UI mode all is in json and not in yaml, but when i edit lovelace (say in raw editor, or if i click “show code editor”) i see all stuff in yaml (at least kind of yaml… no brackets etc…)?

25

Yes, because the system converts the JSON to yaml. I’m not sure how else to explain this to you.

26

Well, we’re getting somewhere… so, there IS some kind of conversion in UI mode also… only that it’s done each time when i click “edit” or “save” (doesn’t really matter when, i guess) and, i guess that yaml part is only in RAM, not physically on HDD. And thus the reason comments are not stored…

27

I don’t know if you’re purposely ignoring my comments but yes, I said there was a conversion. Let me link that again…

Maybe you’re not understanding what I was saying. There is no conversion from YAML to JSON. There is only a conversion from JSON to YAML. Everything you see in the UI is serialized as JSON. There are exceptions to this, like if you set the dashboard to yaml only. But when you are in the UI dashboard mode, everything you see on screen is serialized to as JSON when you click save. I guess you could argue that YAML converts to JSON if you open directly to YAML on your dashboard.

28

Now i understand… so all i do i basically “do in json”, it’s just for vewing purposes is shown as yaml (and then discarded), so we really can’t say this “a conversion”, i agree.
Sorry, as i said i’m not a programmer by trade, so some things can take time for me to get it. My age also doesn’t help either… but that aside i still wanted finally to understand it…
Thanks!

29

If you want to get really technical, it’s not even yaml you’re looking at. The conversion is JSON to JS objects and the editor displays the objects as yaml when you click the “view as yaml” button. So there’s really no conversions at all while you work. The only conversion occurs when you open the dashboard up in edit mode (JSON → JS Objects) and when you save (JS Objects → JSON).

This is ultimately why it’s important that the all the work is done with JSON in mind, not yaml.

4 Likes
30

let me link this to the solution as well as it’s a really… distilled… summary

31

@petro do you mean only when working in the UI editor? I understand from your comments that the UI stores objects in JSON / JS Objects, but when you hit save HA has to convert to YAML and persist to disk, no? E.g., /config/automations.yaml

So besides storing your comments as meta tags in JSON like @HeyImAlex suggested and bringing them back in the UI editor, you’d have to make sure the comments are properly carried over when converting from JSON to persist the YAML to disk.

If that’s the case, I wonder if it wouldn’t be easier to have an advanced setting somewhere that would simply let you toggle between the fancy editor, or just edit the raw YAML file in the UI (like if you were editing the raw /config files, without any syntax validation).

Edit: nah, thinking a little more, this would have a big drawback that you wouldn’t be able to use the UI anymore, so it’s not different than editing /config files directly. Unless you this on a per-entity selection, but now we’re going down another rabbit hole. I think I just convinced myself that there’s no trivial solution to this.

32

I am a programmer. Retired software engineer with lots of machine-language years behind me. Thankfully. Your thinking is exactly correct and I wouldn’t think it would be that difficult to skip the “delete the source” step.

That consumes resources in the final file. You would never find a comment in a binary file compiled from C++, but only a fool would ever write C++ code without comments. You write the code, then compile the binary. If you need to make changes, you change the original code and recompile. As I said in my OP. You just don’t delete the original source code. No changes needed to JSON. Treat the JSON code like you would any binary file.

1 Like
33

Just wanted to mention that this explains why some of my automations that I tried to create by pasting the yaml directly into the editor ended up with missing/incorrect code. Not a big issue since the UI is now very nice compared to when I started using HA in 2022.

34

OnEdit, if HA stores the data as JSON, and is no conversion from JSON to YAML, then:

  • Why would the UI show the user a YAML, because the UI is handling the serialization to JSON

  • Can we ask the system to show us a JSON version of the code so we can edit that instead of YAML?

  • If the UI is handling all the conversion between YAML and JSON, could the UI simply have a field that happens to contain the YAML text? As the user makes changes the UI updates this YAML text. When the user clicks save, then both the raw JSON data and the provided YAML is sent to the server.

35

It doesn’t store it as JSON, it’s just objectified. Serialization to JSON doesn’t happen until you save. When you view YAML, you’re viewing objects made to look like YAML.

Because HA was founded on YAML.

No

36

I have two forms of commenting working for me when editing automations. One within “{{}}” expressions, and one outside.

  - variables:
      remain_backup_and_grid_charging: |-
        {# this a comment #}
        {{
          (    true or "remain in grid feeding while price good and still some solar")
          and (true or "try to get to end of solar production with a full battery"   )
          and backup and charging and battery_full and solar and buy_now
        }}

This survives save/edit-in-yaml.

Also or (false and "comment") depending on the logic.

3 Likes
37

You write the code, then compile the binary. If you need to make changes, you change the original code and recompile. As I said in my OP. You just don’t delete the original source code. No changes needed to JSON. Treat the JSON code like you would any binary file.

^ This

Only conversion removes the comments. Treat it as source and all is fine. I am a 25+ years dev and edit yaml in vscode all the time with comments. No need to erase the original, just validate it!

38

I also have 25+ years of coding background, and i am reminded of the kind of programmer who would not comment their code. They somehow felt superior (or job-safe) because only they could read or maintain it. When there were cutbacks, they were usually the first to go. They also avoided Version Control software for exactly that reason.

There is NO valid reason to delete the ‘source’ yaml file when converting it to JSON. The easiest solution would be for the editor to simply work from a copy of the source.

Please make the suggestion in Feature Requests.

1 Like