Align commas directly after the value?

[josdejong]

FracturedJson aligns the commas vertically with each other, like so:

{
  "Beatles Songs": [
    "Taxman"        ,
    "Hey Jude"      ,
    "Act Naturally" ,
    "Ticket To Ride"
  ]
}

Is there a way to position the commas right after the values, like so:

{
  "Beatles Songs": [
    "Taxman",
    "Hey Jude",
    "Act Naturally",
    "Ticket To Ride"
  ]
}

If not, I would love to see this as a new option!

[j-brooke]

The reason the commas are aligned is because technically it's treating the array as a single-column table. You can get rid of that behavior by disabling table formatting by setting MaxTableRowComplexity to -1. That's global, though, so it might make other parts of the document less appealing.

This is a common complaint. It is an eyesore to have all those commas hanging out like that when you've got a contain whose values are all strings. (It's presumably not an issue for numbers or booleans, and it doesn't try when the types are mixed.) I'd like to put in some way to deal with this case without completely disabling table formatting. I'm not sure what the best approach is. Maybe a new MinimumTableColumns or MinimumTableRowComplexity.

Whatever the fix is, I'd probably want it to be the new default, which would mean it should be a new major version, since some people might be counting on the current default behavior.

[josdejong]

Thanks for thinking this trough!

Would it be possible to extend the table cell formatting with a new option CommaAlignment: boolean? In table cells, each value is followed by whitespace such that each table cell has the same width. This option could determine whether the comma is added left or right from the whitespace. Not sure how complex this would be to implement though.

[vdhamer]

If the changed default (however it works) comes in release 5.0, you could sneak in a minor release first where it requires setting a parameter? And then release a major release (with a changed default) when you see how your users react.

Thanks to both of you. My project uses Jos' tool, which turns out to depend on FracturedJson.

[josdejong]

Maybe a new MinimumTableColumns or MinimumTableRowComplexity.

Just for clarity: I'm thinking in a bit different direction: keeping the table formatting, but just positioning the comma directly after the value. So, instead of this:

{
  "ObjectColumnsArrayRows": {
    "Katherine": ["blue"      , "lightblue", "black"       ],
    "Logan"    : ["yellow"    , "blue"     , "black", "red"],
    "Erik"     : ["red"       , "purple"                   ],
    "Jean"     : ["lightgreen", "yellow"   , "black"       ]
  }
}

I would prefer it to look like:

{
  "ObjectColumnsArrayRows": {
    "Katherine": ["blue",       "lightblue", "black"       ],
    "Logan"    : ["yellow",     "blue",      "black", "red"],
    "Erik"     : ["red",        "purple"                   ],
    "Jean"     : ["lightgreen", "yellow",    "black"       ]
  }
}

[j-brooke]

If the changed default (however it works) comes in release 5.0, you could sneak in a minor release first where it requires setting a parameter? And then release a major release (with a changed default) when you see how your users react.

I'll keep that in mind.

[j-brooke]

Just for clarity: I'm thinking in a bit different direction: keeping the table formatting, but just positioning the comma directly after the value. So, instead of this:
...

You're right that having the commas right next to the values would, generally, look nicer. Dealing with the commas has been one of the trickiest parts of this project, but it's been a while since I looked seriously at the code. Maybe fresh eyes will let me see a straightforward approach. It's definitely something many users seem to want.

I do think there are use cases where having the commas all lined up to the right of the whitespace makes sense. Position-based importing into a spreadsheet in one possibility. Or in text editors like VS Code, rectangular/column-based selections are a little cleaner when the commas line up. So it would be nice to give the user the option.

[j-brooke]

I've got a solution that seems to be working in most cases, but there's a question about what's correct for certain number cases. What do you guys think?

All of the following examples assume the new setting (name not final) AlignTableRowCommas = false.

Three of the four number modes are simple - they work like you'd expect.

NumberListAlignment = NumberListAlignment.Left

[
    [19,   2    ],
    [3.0,  8    ],
    [9,    null ],
    [0,    3    ],
    null,
    [10,   1    ],
    [null, 2    ],
    [4,    11.11],
    [12,   2    ]
]

NumberListAlignment = NumberListAlignment.Right

[
    [  19,     2],
    [ 3.0,     8],
    [   9,  null],
    [   0,     3],
    null,
    [  10,     1],
    [null,     2],
    [   4, 11.11],
    [  12,     2]
]

NumberListAlignment = NumberListAlignment.Normalize

[
    [  19,    2.00],
    [   3,    8.00],
    [   9, null   ],
    [   0,    3.00],
    null,
    [  10,    1.00],
    [null,    2.00],
    [   4,   11.11],
    [  12,    2.00]
]

But things look weird, in my opinion, with Decimal formatting. This is the mode that preserves the exact representation of numbers from the input, but lines them up by the decimal point (real or implied).
NumberListAlignment = NumberListAlignment.Decimal

[
    [  19,      2   ],
    [   3.0,    8   ],
    [   9,   null   ],
    [   0,      3   ],
    null,
    [  10,      1   ],
    [null,      2   ],
    [   4,     11.11],
    [  12,      2   ]
]

I'm wondering if it would be appropriate to make an exception for this case. That way it would look like this:

[
    [  19  ,    2   ],
    [   3.0,    8   ],
    [   9  , null   ],
    [   0  ,    3   ],
    null,
    [  10  ,    1   ],
    [null  ,    2   ],
    [   4  ,   11.11],
    [  12  ,    2   ]
]

It's easier to read. If you're doing Decimal formatting, you presumably want nice orderly columns.

Here are the two Decimal options with some different data.

{
    "SimpleArray": [
         9.8, 12.6, 17,   22.3, 26.9, 31,   32.4, 31.7, 28.7, 22.5, 16,   12,
        22.0, -4.1,  9.8, 12.6, 17,   22.3, 26.9, 31,   32.4, 31.7, 28.7, 22.5,
        16,   12
    ],
    "ArrayColumnsObjectRows": [
        { "type": "turret",    "hp": 400,   "loc": {"x": 47,   "y":  -4.9} },
        { "type": "assassin",  "hp":  80.0, "loc": {"x": 12,   "y":   6  } },
        { "type": "berserker", "hp": 150,   "loc": {"x":  0,   "y":   0  } },
        { "type": "pittrap",                "loc": {"x": 10.5, "y": -14  } }
    ]
}

{
    "SimpleArray": [
         9.8, 12.6, 17  , 22.3, 26.9, 31  , 32.4, 31.7, 28.7, 22.5, 16  , 12  ,
        22.0, -4.1,  9.8, 12.6, 17  , 22.3, 26.9, 31  , 32.4, 31.7, 28.7, 22.5,
        16  , 12
    ],
    "ArrayColumnsObjectRows": [
        { "type": "turret",    "hp": 400  , "loc": {"x": 47  , "y":  -4.9} },
        { "type": "assassin",  "hp":  80.0, "loc": {"x": 12  , "y":   6  } },
        { "type": "berserker", "hp": 150  , "loc": {"x":  0  , "y":   0  } },
        { "type": "pittrap",                "loc": {"x": 10.5, "y": -14  } }
    ]
}

Do you think one of those is clearly always the right choice? Or should the setting be more complicated than a simple boolean?

[j-brooke]

So maybe TableCommaPlacement with values Left, Right, and LeftExceptNumbers? (Or would BeforePadding, AfterPadding, and BeforePaddingExceptNumbers be easier to grasp?) That would allow for both of the Decimal cases we've just been talking about.

[josdejong]

Yeah something like that, this sounds good. I have a slight preference for BeforePadding | AfterPadding | BeforePaddingExceptNumbers but Left | Right | LeftExceptNumbers would be fine with me too.

[vdhamer]

My 2 EuroCents worth (remember that I am merely indirectly using FracturedJson via Jos’ work). This is more what comes to mind that a direct reaction to the above dialog. -> Feel free to ignore.

I tend to see JSON human readability just like programming language readability. Sometimes function(param1, param2, param3) fits nicely and logically on one line, sometimes I go for one line per parameter. There is indeed no universal rule: it indeed depends om practical things (line length) and semantics (first name, last name of a person on one line because that is how natural languages and forms tend to do this). It is all a compromise between readability and saving screen space.

For strings, I would avoid comma alignment altogether. If there is configurability, it should be local rather than global. Because different branches of the JSON tree can describe dissimilar things. Car type versus car’s owner.

For numbers, I get that alignment would be nice. Just like left/right/center/decimal alignment in spreadsheets. There it can be global if needed. Because you can just assume that that there are either not too many tables, or if there are, that they have similar requirements. A subset of what spreadsheets provide in terms of formatting would be nice. Just because that’s what non-programmers tend to (as)use. But then again, right now my JSON schemas tend to be complex trees instead of lots of records that look the same. For boring huge matrices, you could argue that a custom format (e.g. images) is better at saving space than JSON/XML with internal semantic labeling.

Again, this probably makes some sense, but may not help in the actual discussion. Yes, maybe I should reread the entire thread ;-)

[vdhamer]

Remarks after checking some of the examples:

• Do you really want simple (1-D) numeric arrays of numbers to have padding? The alignment helps vertical comparison, but harms horizontal comparison because they suggest some kind of horizontal grouping). After all it is a single list of values, and upstairs/downstairs neighbors are just an artifact of having to wrap long lines of text.
• Do you really want this to smartly try to format more complex/hybrid cases like records containing a few strings, and a small array of numbers? You could simple go for a solution that only “compacts” simple and common cases onto one line. And uses the less compact (canonical) format for anything more complicated. Because whatever you do, it will never solve all possible cases/wishes. So I was aiming for: baseline formatting is the canonical format with lots of text lines. And “smart” formatting catches a few obvious patterns when they can fit onto a line of “standard” width. I realize that I didn’t define what obvious patterns were - just arguing that reformatting an object that happens to contain a mini-matrix which could fit onto one line might be a corner case without a clear solution: the line is mixed type, and alignment only has meaning if you have an array of such lines.

[j-brooke]

If there is configurability, it should be local rather than global. Because different branches of the JSON tree can describe dissimilar things.

As a matter of design philosophy, FracturedJson aims to be pretty close to one-size-fits-all. There are a ton of options for the people who want them, but I think most people want it to "just work" pretty well without having to learn about all the settings. With any tool, there's always a balance to find between ease of use and versatility.

[j-brooke]

Implemented in version 4.1.0. The npm and Nuget packages are now available. I'll adjust the VSCode extension and web formatter soon.

It's controlled by the setting TableCommaPlacement. Possible values are: BeforePadding | AfterPadding | BeforePaddingExceptNumbers. The default is AfterPadding, for compatibility with version 4.0.0.

I also created a new factory method, FracturedJsonOptions.Recommended() for people who want the new/best settings when new features come out but don't want to worry about settings.

Thanks for your help, @josdejong and @vdhamer. I think you've helped guide FJ in a good direction.

[josdejong]

That is awesome 😎 . I love it, It feels like a small thing but it reads much more natural! Thanks.

I've updated the library in my web application https://jsoneditoronline.org using TableCommaPlacement now (see docs on formatting).