JSON with multiline strings

#json #javascript #typescript #parsers

One of the most impactful features to be added to ECMAScript in the last few years is template literals. Creating multiline strings before the template literal syntax was done with \n escape codes.

const exampleObject = {
  exampleText: 'this text appears on line 0\nthis text appears on line 1'
}

console.log(exampleObject.exampleText)
// this text appears on line 0
// this text appears on line 1

This was not only a pain to write, but also a pain to read - especially when a string contains many line breaks. But with modern JS we can do the following instead:

const exampleObject = {
  exampleText: `this text appears on line 0
this text appears on line 1`
}

console.log(exampleObject.exampleText)
// this text appears on line 0
// this text appears on line 1

Note that the output of either method is the same. We can declare a JS Object that contains a string property using template strings with backticks, or we can do it with the \n escape code.

However, this flexibility is not available in JSON. We are able to write these multiline strings in JS, but in JSON the same content would cause a parsing error because JSON doesn't know how to handle strings wrapped with backticks.

But this isn't the first time there was a missing feature in JSON! It is also unable to handle a document if it contains a comment:

{
  "org": "polyseam" // this comment would cause JSON.parse to fail
}

The above document is invalid JSON, despite it being perfectly valid JavaScript. Eventually, someone decided comments are so useful that a new specification and parser were created to allow us to put them in documents.

That spec is called JSONC. Note how the comment is now correctly parsed as such:

{
  "org": "polyseam" // this comment is properly ignored
}

Now we know multiline strings are a missing feature of JSON that is quite valuable, and we know that we can create new specifications and parsers when it is worth while... I propose we create just one last variant of JSON:

{
  "org": "polyseam",
  "exampleText": `this text appears on line 0
this text appears on line 1`
}

By extending JSON in this way we have so much more flexibility in the way we read and write documents with JSON, which has impacts from the browser, to the server, to Kubernetes manifests, and beyond. We also provide a feature that 'just works' the way a JavaScript developer might imagine it should.

Do you think that JSONCT is a good idea? Does it already exist? Do you have a better name for it?

We'd love to hear from you!

github.com/polyseam/jsonct

Top comments (6)

Benoit COUETIL 💫 • May 19 '23 • Edited

JSON is a language meant to ignore new lines, as XML was before it, but lighter.

Comments are special, because you can remove them and still have the same json, that can be reduced to one line.

With your suggestion, you are going too far from the original DSL. If new lines become important, why these unnecessary brackets all over the place, shouldn't we remove them ? And BAM! you end up reinventing YAML 😅

Tracy Gilmore • May 22 '23

Despite JSON being largely inspired by the object notation of JavaScript (as they say the clue is in the name) it has become a format common to a wide variety of technology stacks. The template literal syntax might not be specific to JS but I do not think it is anywhere as familiar to other languages as string, array and object delimiters. In any case you would have to get Doug Crockfords seal of approval.

Matt Johnston • May 22 '23 • Edited

The idea isn't to replace JSON with Doug's blessing, but rather provide an alternate syntax with an alternate file extension.

my-config-file.jsonct

There is precedent for this because
my-config-file-with-comments.jsonc already exists.

As authors of a JSON document we can choose whether it should be parsed as .json, .jsonc, or .jsonct in the applications that consume the document.