Open ameissnersofi opened 7 years ago
Hi,
When you check response headers you'll notice either missing content type header or invalid its value (not a json type). So in this case the app is showing formatting as directed by server or default one.
If you are the one operating server just change content type to application/json
or contact server admin about the issue.
Note that any other client will behave in similar way as the app. Servers are obligated to send proper content type headers.
I'm closing this as WAI.
No - that's not the case. Content-Type is set to application/json on the response headers. Again, the Raw pane immediately returns the json so the server is doing just fine. The JSON view pane will eventually load and display the JSON, but it takes longer than 3 minutes.
The JSON pane has some nice feature that I use on a daily basis, so it would be nice if it went back to parsing / loading / displaying promptly.
I'm sorry. I didn't understand correctly.
It has to be a huge JSON response then. RAW tab just displays response text so there's just as little work. But JSON parser is a big deal comparing to raw. Because the work is done in the web worker, it waits until whole JSON structure is parsed and decorated with HTML markup. When there's a lot of data it may takes some time. But I never encountered time over a few seconds.
Is there a chance to give me a sample of the JSON output so I can run test on my local machine?
For this one in particular it is rather large. But, in previous versions of ARC I've made this exact http call and the JSON parser has been very quick to parse and display. It's only been recently that this has been significantly slower than usual.
quicker-response-export.txt slow-response-export.txt
I've attached two response exports for you. One of them causes ARC to take upwards of 3 minutes to parse (600-650 small objects in a single array) while the "quick-response-export" file is part of a paginated response, and thus only contains 100 elements in the array.
The quicker one takes maybe a couple of seconds to display, while again, the larger response takes much longer.
Thanks for re-opening!
Thank you for the sample. I'll test it as soon as I finish another issue :)
This is result of my test:
slow-response-export.json
run | time (ms) |
---|---|
1 | 204.59000000000015 |
2 | 98.07499999999982 |
3 | 96.1349999999984 |
4 | 99.04500000000007 |
5 | 110.92000000000007 |
6 | 101.31500000000051 |
7 | 98.34499999999753 |
8 | 100.46000000000276 |
9 | 103.14000000000306 |
10 | 107.66000000000349 |
quicker-response-export.json
run | time (ms) |
---|---|
1 | 358.5100000000002 |
2 | 264.244999999999 |
3 | 246.79000000000087 |
4 | 237.84999999999127 |
5 | 231.60499999999593 |
6 | 228.38999999999942 |
7 | 230.14499999998952 |
8 | 240.52999999999884 |
9 | 237.11000000000058 |
10 | 239.24499999999534 |
So I started wondering if adding a HTML content to the viewer could be a problem here. The JSON viewer uses innerHTML
which seems to be the fastest way to insert HTML content. I've created this test case to check which method is the fastest: https://jsperf.com/innerhtml-and-createelement2
(personally I was counting on document fragment).
This means that the app is using fastest possible way to insert parsed HTML data (meaning the JSON surrounded with HTML markup).
Giving the times I can't confirm or reproduce the issue. I do however still try to find a more efficient way to parse and highlight the JSON structure. Maybe this will help.
I might be misunderstanding, but I don't think there's any HTML markup in either of the samples I sent. It's just a pure JSON response from the server.
It's also odd that you can't reproduce the issue. All my co-workers have the same issue as I do. We know it's not network related because running curl
s or using Postman returns the JSON immediately. Again, so does the RAW viewing pane in ARC - it responds immediately - it's just the JSON view pane.
I'm not really sure where else to go from here. :( I don't know why of the two samples I sent you, the larger dataset performed in a third of the time than the smaller dataset. That just baffles me.
I appreciate your looking into this.
Sure, I'm not dismissing the issue. I just couldn't reproduce the problem right now. I'll try on other OSs and maybe there I'll be able to reproduce this. I'll let you know as soon as I find anything.
After making an API call - I receive a 200 and can view the json in the Raw panel. The JSON panel fails to load the result and just spins for longer than is normal
Expected outcome
The JSON pane should work as it has before
Actual outcome
Spinning material design wheel of death for several minutes
Versions
App: 8.19.60.296-stable Chrome: 54.0.2840.98 Platform: Mac OS X (10_12_1)
Steps to reproduce