Re: [whatwg/fetch] String representations for Fetch API objects (Issue #1575)

> What about a custom [Symbol.*] which provides a function tailored to emit a better console representation? I understand stringification is already a point of API compatibility, so surely an opt-in upgrade for implementers would be best if this is fixed by spec.

Whether to pursue the "internal Console Standard hook" route vs something like a new web-exposed [well-known Symbol name](https://tc39.es/ecma262/#sec-well-known-symbols) route depends on how important it is to have the pretty-printable values exposed to script. For most of these objects (perhaps except `Headers`?) Anne seemed to be leaning more towards the idea of a Console Standard hook so I guess we should figure that out. I don't know what would be best for these Fetch objects, or if Anne has strong opinions either way. That seems like the first thing to resolve though.

A Console-only hook would be pretty easy, but the implementation is vague and might be hard for vendors to prioritize, and you don't get any interesting values exposed to script. A web platform-exposed hook would give you more information, and could allow you to print things without requiring modifications to the implementation-specific Console logging, but it is a larger addition to the platform, especially with Symbols and all.

Thoughts @annevk ?

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/1575#issuecomment-1401317019
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/fetch/issues/1575/1401317019@github.com>