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

Display Transit EDN in Network Panel's request preview #37

Open
darwin opened this issue Sep 3, 2016 · 3 comments
Open

Display Transit EDN in Network Panel's request preview #37

darwin opened this issue Sep 3, 2016 · 3 comments

Comments

@darwin
Copy link
Member

darwin commented Sep 3, 2016

Similar to JSON display.

@gabrielmaldi
Copy link

This would be great!

@p-himik
Copy link

p-himik commented Oct 26, 2019

@darwin I just copied here a reformatted version of what you wrote on Slack to preserve it:

Just briefly looked at the devtools sources, web socket data frames and normal network request previews are handled differently.
Web socket frame can be either text or binary and devtools creates corresponding view for it (in case of text type, it creates JSON view), no detection of mime type or anything like that.
In network requests it tries to look at response headers or request headers and then interpret the mime type.

async _onFrameSelected(event) {
this._currentSelectedNode = /** @type {!Network.ResourceWebSocketFrameNode} */ (event.data);
const content = this._currentSelectedNode.dataText();
const binaryView = this._currentSelectedNode.binaryView();
if (binaryView) {
this._splitWidget.setSidebarWidget(binaryView);
return;
}
const jsonView = await SourceFrame.JSONView.createView(content);
if (jsonView) {
this._splitWidget.setSidebarWidget(jsonView);
return;
}
this._splitWidget.setSidebarWidget(new SourceFrame.ResourceSourceFrame(
Common.StaticContentProvider.fromString(this._request.url(), Common.resourceTypes.WebSocket, content)));
}

Actually if JSON view cannot be provided, it falls back to Common.resourceTypes.WebSocket type, whatever it is.
Here seems to be the logic for normal network requests:

static async sourceViewForRequest(request) {
let sourceView = request[Network.RequestResponseView._sourceViewSymbol];
if (sourceView !== undefined) {
return sourceView;
}
const contentData = await request.contentData();
if (!Network.RequestResponseView._hasTextContent(request, contentData)) {
request[Network.RequestResponseView._sourceViewSymbol] = null;
return null;
}
const highlighterType = request.resourceType().canonicalMimeType() || request.mimeType;
sourceView = SourceFrame.ResourceSourceFrame.createSearchableView(request, highlighterType);
request[Network.RequestResponseView._sourceViewSymbol] = sourceView;
return sourceView;
}

We would have to implement a new SourceFrame.ResourceSourceFrame type and detect packed transit there.

@p-himik
Copy link

p-himik commented Oct 26, 2019

To add a suggestion - maybe it would be worth it to not detect anything but rather to allow users to select what the actual mime type is. Although I'm not sure it that would be possible via the UI, but I'm perfectly fine with having to specify a config option for it. Especially if it would support any custom type (e.g. transit allows extensions - no level of detection could handle that).

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

No branches or pull requests

3 participants