1198558 - Inline Validation Errors for Broken JSON

Status: NEW

(DevTools :: JSON Viewer, enhancement, P3)

Description

[Blake Winton (:bwinton) (:☕️)]

I heard about the new JSON viewer on twitter, and while it looks amazing, I couldn't help but wonder what it did with broken JSON.  While the behaviour of showing the error, and the source in the "raw" tab is totally fine, I think it would be much easier to debug our JSON if you showed the source that surrounds the error on the error page, to give more context, or even better, show as much of the JSON as you can, and then end with a big red "…" or "X", followed by the error.  :)

Comment 1

[Jeff Griffiths (:canuckistani) (:⚡︎)]

Honza - what do you think?

Comment 2

[Jan Honza Odvarko [:Honza] (always need-info? me)]

I have been thinking about the same the other day and here is a little demo:
http://janodvarko.cz/json/viewer/

* It allows to validate JSON and use the same UI as standard spell checkers are using today to highlight a syntax error.
* The demo is based on Orion editor (CodeMirror would be better)
* Since it's based on an editor it also allows JSON editing.
* When using browser/devtools/sourceeditor/ component (from our tree) we can also implement features like "folding JSON source" (like functions in JS source) almost for free.

Note that validation of big JSON files can be slow.

Honza

Comment 3

[Blake Winton (:bwinton) (:☕️)]

Nice!  There are a couple of things I would add/change, but this is basically what I was thinking about.  :)

Comment 4

[Jan Honza Odvarko [:Honza] (always need-info? me)]

(In reply to Blake Winton (:bwinton) [Away until Aug 23rd at least.] from comment #3)
> Nice!  There are a couple of things I would add/change, but this is
> basically what I was thinking about.  :)
What things? I am happy to have your feedback! :-)
Honza

Comment 5

[Blake Winton (:bwinton) (:☕️)]

Wrapping long lines would help show where the errors are (if they're off the end of the screen).

Inserting a newline seems to clear the error, which is kinda confusing sometimes.  You can sort of see this with the example:
{"a":1,"b":
:"really long string goes here!'}
(Notice how small the red underline is.)

Similarly, some sort of error text (on the bottom, or when hovering over the erroneous input) would be really useful for those of us who sometimes forget that single-quoted strings aren't allowed in JSON.  ;)

Comment 6

[Jeff Griffiths (:canuckistani) (:⚡︎)]

I'm not sure if we need to show the entire json string here, I think as a developer what I'd want is a pretty-printed fragment of the document with the error message integrated so that it clearly indicates the line and column that triggered the error. 

I think this jsonlint online tool has implemented this in an interesting way:

https://www.evernote.com/l/AAEEx1veZNxN9Je4Kg_PhMvTkz2ijciTK0s

Comment 7

[Jan Honza Odvarko [:Honza] (always need-info? me)]

(In reply to Jeff Griffiths (:canuckistani) from comment #6)
> I'm not sure if we need to show the entire json string here, I think as a
> developer what I'd want is a pretty-printed fragment of the document with
> the error message integrated so that it clearly indicates the line and
> column that triggered the error. 
> 
> I think this jsonlint online tool has implemented this in an interesting way:
> 
> https://www.evernote.com/l/AAEEx1veZNxN9Je4Kg_PhMvTkz2ijciTK0s
Looks good to me

Or, here is a screenshot from pro.jsonlint.com
http://snag.gy/xL9GL.jpg
There is a popup window displaying the error message and
pointing to the related place in the source JSON.

Honza


Honza

Comment 8

[Jeff Griffiths (:canuckistani) (:⚡︎)]

(In reply to Jan Honza Odvarko [:Honza] from comment #7)
> (In reply to Jeff Griffiths (:canuckistani) from comment #6)
> > I'm not sure if we need to show the entire json string here, I think as a
> > developer what I'd want is a pretty-printed fragment of the document with
> > the error message integrated so that it clearly indicates the line and
> > column that triggered the error. 
> > 
> > I think this jsonlint online tool has implemented this in an interesting way:
> > 
> > https://www.evernote.com/l/AAEEx1veZNxN9Je4Kg_PhMvTkz2ijciTK0s
> Looks good to me
> 
> Or, here is a screenshot from pro.jsonlint.com
> http://snag.gy/xL9GL.jpg
> There is a popup window displaying the error message and
> pointing to the related place in the source JSON.

Yeah! - that looks great as well. I think we have a shared understanding on what the intent is, I'll leave it up to you to figure out the implementation. 

To be clear - this is a nice followup to bug 1132203, but shouldn't block.

Comment 9

[Jan Honza Odvarko [:Honza] (always need-info? me)]

I've created an online prototype that shows UI/UX

(btw. JSON Viewer is pure web app, so it can simply run online, which also makes the development easier and faster)

http://janodvarko.cz/temp/jsonviewer/app/

The UX works as follows:
1) Load the page above, you should see JSON Viewer. The JSON doc contains two errors (the JSON is hard-coded in this demo).
2) You should see an error-popup pointing to the place where the error occurred. Related piece of the source is selected (but sometimes the JSON parser doesn't produce meaningful line/col info).
3) The JSON source is editable, so fix the error and press Validate button in the toolbar.
4) Oh, there is another error, fix it too and validate again.
5) The JSON should be valid now, so you can see an expandable tree showing the structure. You can go to the Raw Data tab to see (fixed) source again.

I am only worried about big JSON docs. We might want to measure size and offer alternative UI/UX in case of performance issues.

Feedback?

Honza

Comment 10

[Jeff Griffiths (:canuckistani) (:⚡︎)]

I'm not sure about this approach, in terms of utility to a developer:

Editing the document in-place and re-validating is fine, but the developer's workflow is instead much more likely to be:

 - load JSON doc, view error
 - fix backend code that produced bad json
 - refresh

I think I'd rather see a list of errors found in the doc, and for each error a fragment of the code with a visual indication of the line / column of the error, and the error message produced by the parser. Hitting Cmd+R or a refresh button should load an uncached version of the document.

Once there are no errors in the document, it should load not in this 'error' mode but instead using the normal tree.

Comment 11

[Jan Honza Odvarko [:Honza] (always need-info? me)]

I am currently not working on this. Unassigned myself,
so somebody else can pick this up.
Honza