Replies: 3 comments
-
Update: Most of the functionality of version 3 is in place now. It still needs some work on the internals, and a bunch of testing. Here's some sample output. Feel free to post any questions or comments. Or if there's some particular type of data you'd like to be sure works, post that here, too. With comments and line breaks:
Another one with comments:
The basics:
|
Beta Was this translation helpful? Give feedback.
-
Version 3.0.0 is out for .NET and the web formatter. The JavaScript and VSCode versions are still on 2.2.x. I plan to work on them, but it will likely take a few weeks. |
Beta Was this translation helpful? Give feedback.
-
Version 3 is now available for .NET, JavaScript, the web formatter, and VSCode. |
Beta Was this translation helpful? Give feedback.
-
I've started working on version 3 of FracturedJson. I figured it would be nice to let whoever's interested know what's planned, and ask for any input before I'm too far along. This will probably be a complete re-write, and I expect some settings names will change.
Planned Features
Optional Comments
Comments aren't part of the JSON standard, but they're pretty ubiquitous at this point. This is the most requested feature. And hey, they are pretty useful. So it would be nice if FracturedJson could optionally handle them to one degree or another.
The simplest comment case is a comment on a line by itself. The logic would be simple in that case: The array/object that contains it isn't allowed to be inlined.
Multi-line block comments would be similar. The trick for those is getting the indentation right.
The real trick is identifying and preserving inline prefix and postfix comments. Consider:
Ideally, FJ would format that, including the comments in determining columns:
But depending on settings, that could also end up as:
Similarly, for postfix comments we'd like this:
Note that since
// brown
is after the comma on the first line, it's structurally closer to the array on the next line. So the code will need to be careful with that.I DO NOT plan to support comments inside inlined elements. For instance, this won't ever be output:
Option To Preserve Blank Lines
Sometimes blank lines really help readability. Having the ability to preserve them would be nice.
Faithful Number Handling
Right now, numbers with lots of significant digits aren't preserved exactly in the JavaScript/VSCode versions. See this issue for more details. The reason this happens is that for the JS version of the code, the input JSON text is fed to JavaScript's
JSON.parse
and converted into JS data. For numbers, that means they're converted into double-precision floats, which can only handle about 16 decimal digits of precision.In version 3, FracturedJson will be doing its own parsing instead of relying on
JSON.parse
, so it will be able to fall back on the exact input text if it can't handle it as a number.Deep Table Formatting
No promises on this one, but I hope to accomplish it. Right now, when an element is aligned as a table, each row's direct children are lined up. But a row's children's children aren't. For example, this is what you might get right now:
Notice that while the
Position
arrays themselves are aligned, the numbers inside them aren't.I would like version 3 to be smart enough to line those up too, when possible:
I'll have to experiment and see if I can come up with reasonable heuristics for when it should and shouldn't attempt it.
Maximum Total Line Length
Right now, the setting
MaximumInlineLength
refers only to the content part of a line: it doesn't consider prefix text, indentation, or object keys. That's pretty useful, and there are good reasons to keep that around, but let's face it, much of the time you're concerned with the total line width. That will be even more of a concern when inline comments are concerned. I figure I'll renamed the existing property, and introduce a new one.There will still be times when a line will exceed those limits. If a single string is longer than your maximum line length, there's nothing FracturedJson can do about it. And I definitely don't want to do any re-wrapping of comments.
Implementation Plan
This will be pretty much a complete rewrite. I'll be creating a custom tokanizer and parser that pay attention to details that FracturedJson needs, and can be implemented identically across multiple languages. The code will parse the input into a custom DOM structure with extra fields for formatting info.
Project Plan
I'll be working on the C# code on weekends, when I have time. I hope to work out as many of the kinks as possible in C# before doing any work on JavaScript/TypeScript. I might release the .NET library on Nuget as a "preview" build, depending on how things look.
Once the C# is looking ready, I'll convert it to TypeScript/JavaScript, and release the npm library and the web formatter. After that, I'll update the VSCode plugin.
I haven't spent much time looking around, but I'm hoping I'll be able to find a suitable tool for converting C# to TypeScript/JavaScript. Otherwise I'll port it by hand. (If anyone has experience with such a tool that might be useful, please let me know.)
Beta Was this translation helpful? Give feedback.
All reactions