Replies: 1 comment
-
Thanks for the suggestion. I've considered something like this before, but it opens up a whole lot of extra complications. Philosophically, FractureJson is meant to be a general-purpose tool. It's meant to work pretty well without caring much about the shape of the data it's processing. Obviously that isn't entirely true: you'll pick settings that work for your data if the defaults don't look good. But much of its value is that it works out of the box. The VSCode plugin, for instance, would be a pain if you needed to adjust a bunch of settings before hitting the format button. The other problem is that once you start down this path of per-node configurability, it's hard to know where to stop. At first you key the options off of a simple node name. Then it's a dotted path. Then a dotted path with wildcards. And you have to think about case sensitivity and escaping characters. Then more complex processing based on conditionals involving, say, the number of elements in an array. I'm afraid that this would mutate FracturedJson into something different than it was meant to be. All that said, if you have a specific need and aren't concerned with a big complete enhancement, it would be pretty easy to fork the code. (If you don't need the full-width character support, you can just grab a single source file for the C# or Typescript library versions.) The |
Beta Was this translation helpful? Give feedback.
-
@dshaffren @alvintownsend @rcurtis @j-brooke
FracturedJson is amazing! I just discovered it and I'm already excited about it!
A feature that would be useful for me would be the possibility of adding special configurations for specific keys.
For example, consider the following json object:
So, how about we could have options like:
keysWhichValuesShouldStayInASingleLine=['a', 'c']
This would overwrite the other options and would produce the following result:
This is only a general overview. Ideally, we would be able to apply the whole range of options to even a single key and ignore the rest. I mean, given that each key is itself a json object, in theory we could decompose a highly complex json in parts and treat them differently from each other. That would be powerful, imho.
Back to Earth, I would say that the option of keeping a single key values in one line would be enough for my current needs.
What do you think? Is this idea useful? Viable?
Beta Was this translation helpful? Give feedback.
All reactions