Show HN: JSON Browse – Fetch, filter and manipulate your JSON inside the browser | Hacker News Reader

Show HN: JSON Browse – Fetch, filter and manipulate your JSON inside the browser

jsonbrowse.com

138 pointsjorde26 comments

Looks like the HN effect is happening already -- the "Demo" link to Github shows this:

  {
    "message": "API rate limit exceeded for 52.53.190.53. (But here's the good news: Authenticated requests get a higher rate limit. Check out the documentation for more details.)",
    "documentation_url": "https://developer.github.com/v3/#rate-limiting"
  }

I'm colour-blind, and Firefox the text in the console is completely unreadable to me. The Firefox console background is grey (I think), while the text is blue or purple (I think) and I can't make it out against the background.

Just wondering but are you aware that you can change the color scheme of the development tools? Changing the scheme also updates the colors of the console. There's at least 3 themes available as options, not sure if this helps, hoping it does.

Chrome devtools? I feel the collapsed tree visualization of parsed JSON is already sufficient.

I'll just access the API I need within the authentication context of my app. Anything I would want to do with the JSON data is directly available in the devtools console. It has the added benefit of copying/pasting rough code I write in the console into my IDE to continue the work.

That gets you decently far, especially with small JSON responses. You can't filter with any tree display though, which is what I normally reach to jq for. Being able to filter an array of objects down to only one property in each object is invaluable to me.

For example, in a JSON payload that has an array of 15 objects, I would like to see all IDs of those objects. The output would be something like [1230, 134, 65, 99]. I like looking at that vs scrolling and collapsing a bunch of objects.

write a quick lodash method call to filter your collection.

given the consistent nature of data collections I almost never have a need to examine the full dataset via some front end debugging tool. trust the data to be consistent or not?

Definitely do whatever you think is easier in your workflow. Not everyone uses lodash, but I know a lot of people that prefer to do mapping / filtering of JSON in an actual programming language. That doesn't make one way better or worse than another. 2 ways of accomplishing the same thing.

Not sure what the point about consistency has to do with anything? What if it's an array of consistent, but large objects?

I find I need to examine a full page of JSON quite frequently. I.e. there's some bug, and I need to check for any occurrences of null for a specific property.

Pretty cool, but there should be a warning not to enter in API credentials (through the URI) on this page, as the request is proxied to jsonbrowse.com

That's fair. CORS is a bitch.

YEs, CORS is the reason for this and the code for this proxy is open source and very simple[0]. I didn't want to add disclaimers to clutter the UI nor did I wanted to build a browser extension as it would suffer from same trust issues (you still need to trust the extension developer).

For full transparency, the proxy is hosted on Zeit's `now` service and I don't even have access to logs so accidental leaks should be pretty safe.

[0] https://github.com/jorilallo/jsonbrowse-proxy

By the looks of it, I could just throw at it some response that is massive and it would still attempt to grab it?

If this is really being just run as a proxy setup, the jsonbrowse-proxy might not need the isomorphic-fetch lib, in which case you can just use the embedded node-fetch instead, which has max response size and timeout options available.

I wrote a similar tool awhile ago, though it runs on the command line.

https://github.com/dpedu2/sless

It's intended for reading structure logs - a file containing json objects separated by newlines.

This is really impressive. Another good JSON tool that I would recommend is jq which has been on HN a few times: https://stedolan.github.io/jq/

I think the most useful feature here is JSON -> JS conversion. Relatively often I find myself copying and pasting some JSON into a JS file then manually deleting / regexing away the unnecessary quote marks around key names.

Other than being idiomatic, is there any advantage to quoting or not quoting key names in JS?

Quoted keys allows more variety in the keys (e.g. "Content-Type") but is more annoying to use if all your JS code is written in camelCase (headers["Content-Type"] vs headers.contentType).

Minor reasons but a) it looks untidy (to me), and b) for example if I want to change:

    foo = {
        "bar": true,
        "baz": false
    }

to:

    foo.bar = true;
    foo.baz = false;

then I have extra quotes to delete. Those half seconds add up over a year!

I guess you could argue the opposite though, that this looks messy:

    let headers = {
        Expires: 0,
        'Content-Type': 'application/json'
    }

Which leads me to believe it's a matter of personal preference, and you should just pick one and stick to it :) And look, there's even an eslint rule for it: http://eslint.org/docs/rules/quote-props

strange, I always put quote marks, as I see them as totally necessary. Not in the browser, obviously, but in my mind. It helps me recording those are strings, not variables. I made too many mistakes in the likes of

    var foo = "bar";
    var baz = {
        foo: "qux"
    };

This bites especially often if you are steadily switching between JavaScript and a server-side language where that code actually does what you expect (e.g. Python).

I assume you mean you mistakenly expect baz to equal:

    {
        bar: "qux"
    }

Don't you use syntax highlighting? I can't imagine this ever being an issue...

Looks like a nice toy to play with for vim users. I already want to write a macro for it

Updated my jsonlint.com bookmark to jsonbrowse.com. Thanks for the nifty tool!

same. i use jsonlint all the time to pretty-print json, but this is faster/easier and a filter language too!

Nice tool

Suggestion : Filtering seems to work only on object keys at the outermost level (e.g full_name in demo). It would be nice to be able to filter inner keys as well (e.g html_url in demo)

why would I use this over something like postman or RESTClient?

JSON Browse is like a glorified JSON prettifier with some `jq` style filtering features and not really a REST client even though it features remote fetching for convenience.

Reply on news.ycombinator.com