Retain blank lines in roundtrip

[zsd4yr]

I am looking to retain the whitespace in a roundtrip serialization/deserialization and I am wondering if there is a good way to do this.

If I serialize the following:

parameters:
- name: Foo
  type: string
  default: false
  values:
  - false
  - true

- name: Bar
  type: string
  default: ReadAndWrite
  values:
  - ReadAndWrite
  - ReadOnly
  - WriteOnly

And then deserialize back to a file, I end up with this:

parameters:
- name: Foo
  type: string
  default: false
  values:
  - false
  - true
- name: Bar
  type: string
  default: ReadAndWrite
  values:
  - ReadAndWrite
  - ReadOnly
  - WriteOnly

However, for readability, I would like to retain the whitespace. My use-case is that I am using YamlDotNet to update specific values in my yaml and then deserialize it back.

I am using dynamic serialization (I don't want to have to write classes for every single permutation of Azure DevOps YAML syntax).

I have already tried using a custom extended ChainedEventEmitter to insert an arbitrary symbol in front of the value that I then use to indicate a new-line post-deserialization (string-replace), but that is proving fragile in the best case and utterly broken in the worst.

Can I somehow include blank lines as top-level key-value pairs in the dictionary that results from serialization of dynamics?

Any other ideas?

[justinmchase]

Also, retain code comments during round trip.

[EdwardCooke]

Comments and formatting, like blank/empty lines, are lost when the document is serialized into an object, so I don't think we can do this.

[justinmchase]

Well perhaps, you should retain them during object serialization then?

[vhatsura]

@EdwardCooke, is there any way how to emit a new line between array items during serialization?

[justinmchase]

If you're looking for ideas on how to solve it, one way would be to have an alternate api which returns an object graph which represents the full document including whitespace and comments instead of the simplified deserialized object. Then from that document there could be a function which can build and return the simplified javascript object.

Another option would be to use the javascript Reflect api to add metadata onto simple objects. This would allow you to have both a simple return object and also the more complex metadata. Of course, that can be a little complicated for new users who may alter or clone objects, heedless of the metadata on them, but it would work.

There's probably more techniques but its definitely an achievable feature and well worth considering.

[EdwardCooke]

@vhatsura I've been toying with the idea of adding some events to the serializer, something like OnScalarSerialized or something like that. Haven't done anything with that idea, just something I've been thinking about to add an extension point to the serializer.

@justinmchase this is a dot net library, not javascript. As far as I am aware, there is no metadata type of thing on objects in dot net. I also am strongly against adding arbitrary data, properties, attributes or anything else to someone's object, that just seems like a bad idea. I know I personally wouldn't use a library that added anything on to my objects without my expressed knowledge and intent. One example is entity framework. It handles adding metadata type of stuff and things like navigation through the database via properties, is, if I recall correctly, creating a new object type that inherits the class being deserialized, which is utterly annoying when you serialize that object when logging objects.....I really don't want to go down that route in any way.