Improve metadata generation

[joneff]

The code is self-explanatory, but here is anyway: values are processed and prettified in that order

1. If the value is instance of SassMap, it's prettified as an object, with the values prettified recursively according to the rules hereby;
2. If the value is instance of SassList, it's prettified as an array, with the items prettified according to the rules hereby;
3. If the value is instance if SassString, it's prettified as string, with quotes removed where possible;
4. If the value is instance of SassNumber, it's prettified as a number, if there are not units or string otherwise;
5. If the value is instance of SassBoolean, it's prettified as boolean;
6. If the value is equal to SassNull, it's prettified as null;
7. In all other cases, the value is returned as string.

The prettified value is then stored as a new prettyValue field in variables.json, which is then copied to sassdoc-data.json.

[zhpenkov]

Corrections I have made to the original idea:

1. SassList values prettified to a string. SassLists are typically presented as a string "10px 15px 0 0".
2. Restrict adding prettyValue to only map variables.

[zhpenkov]

I am using this PR to continue the efforts for the metadata improvements.
The changes I make are related to - https://github.com/telerik/kendo-themes-private/issues/240#issuecomment-2133557717

[epetrow]

Looks good overall, just one question:

I noticed that we are displaying maps differently in the docs files now -- before the values were wrapped inside <code> while now they are inside a ul. Are we sure we want to remove the code tag?

[zhpenkov]

@epetrow The reason the <code> tag is replaced with <ul> <li> elements is because:

Before adding prettyValue for the map variables, we displayed the resolvedValue of each map, which is always resolved to string and is best visualized in an inline element - <code> tag.

(1: (0 2px 3px rgba(0, 0, 0, 0.04), 0 4px 16px rgba(0, 0, 0, 0.12)), 2: (0 4px 6px rgba(0, 0, 0, 0.06), 0 4px 16px rgba(0, 0, 0, 0.12)), 3: (0 6px 8px rgba(0, 0, 0, 0.08), 0 4px 16px rgba(0, 0, 0, 0.12)) ...

After adding the prettyValue, we can iterate over each key/value pair and display that information separately for better multiline data visualization - <ul> <li>.

• 1: "0 2px 3px rgba(0, 0, 0, 0.04), 0 4px 16px rgba(0, 0, 0, 0.12)"
• 2: "0 4px 6px rgba(0, 0, 0, 0.06), 0 4px 16px rgba(0, 0, 0, 0.12)"
• 3: "0 6px 8px rgba(0, 0, 0, 0.08), 0 4px 16px rgba(0, 0, 0, 0.12)"

In terms of data tracking, there is no issue as both resolvedValue and prettyValue contain the same data. The only difference is that one is parsed with proper types, while the other is parsed as a string.

These changes to the .md doc files should be checked in the sites that directly use them to ensure everything works properly.

[epetrow]

I noticed a few inconsistencies in how the data is displayed in the docs files now. It might be expected, however now we have:

Numbers being displayed as numbers - e.g. thin: 100

If a value has a unit it is a string - xxs: "0.5rem"

Also in some places there are escape characters that are being displayed in the docs now - serif: "\"Times New Roman\",

[zhpenkov]

@epetrow
I resolved the inconsistencies between strings / numbers and removed character escape symbols from the .md doc files