DEV Community

Cover image for JSON with multiline strings
Matt Johnston for Polyseam

Posted on • Edited on

JSON with multiline strings

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
}
Enter fullscreen mode Exit fullscreen mode

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
}
Enter fullscreen mode Exit fullscreen mode

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`
}
Enter fullscreen mode Exit fullscreen mode

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)

Collapse
 
bcouetil profile image
Benoit COUETIL πŸ’« • 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 πŸ˜…

Collapse
 
tracygjg profile image
Tracy Gilmore

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.

Collapse
 
johnstonmatt profile image
Matt Johnston • 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.

Collapse
 
devlist profile image
Devlist

a great idea, love to suggest a json validator: jsonhome.com which help me validate and format JSON data, even for non-standard json.

Collapse
 
mk_kotrotsos_c1d3d6bae8 profile image
M.K. Kotrotsos

Just don’t. JSON was never meant to be treated like this. Comments are for expressions, not data. What shall we do next, arrays?

Collapse
 
tracygjg profile image
Tracy Gilmore

I thought JSON supported arrays from the outset.