Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Response Tab #127

Open
alairock opened this issue Mar 25, 2016 · 5 comments
Open

Response Tab #127

alairock opened this issue Mar 25, 2016 · 5 comments
Milestone

Comments

@alairock
Copy link

Right now there is a ton of information you can get from the requests. All of the information needed really, but I was surprised the most basic of features didn't exist. Responses! Especially as I am working with API's, being able to see the actual response would be especially helpful.

@itsgoingd
Copy link
Owner

Hey, when using dev tools you already have your request data in the Network tab. I find myself often switching between Network and Clockwork tabs, I'd like to have a "show in Network tab" contextual menu in Clockwork to make this a little bit easier, but I'll have to do some research to see if that's possible.

@weidmaster
Copy link

Yes I have to switch between tabs as well. I like how Clockwork displays request errors in red and the exception info but to see a response formatted like the request in clockwork tab itself instead of need to go to the network tab in dev tools would be delightful.

@itsgoingd
Copy link
Owner

I've realized I never explained why this is a challenging feature to add.

We could collect the full response in the Clockwork metadata, this is pretty straight-forward to implement. The main concern here is the response size, as your app might return anything from 1K of json to 100M binary blob. Most of the time you don't even care to see the response, so it's potentially a huge increase of metadata size with no benefit.

Another option would be to temporarily collect the response client-side in the browser extension. I don't like this as it would introduce feature inconsistency between the web and browser versions. Also you wouldn't be able to find responses for older requests.

I guess the best idea so far would be to introduce the response collection as optional (default off) feature with option to specify the required response type and possibly size limit.

@weidmaster
Copy link

Yes it would work better as an optional feature. It would be useful in tricky debugs with ajax data and what not. Thanks for considering the idea

@stepanorda
Copy link

@itsgoingd There are at least one use case when you have SPA with SSR and requests to API often happen in backend so you can't actually see responses in browser network tab.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants