Open bvaughn opened 4 years ago
Unfortunately groupCollapsed has a major downside: group logs can never be filtered from a console, which makes them more expensive/noisy.
This appears to be a Chrome bug, based on your screenshots, and not an inherent restriction of groupCollapsed. Perhaps that's worth filing on the Chromium issue tracker?
I'll note that Firefox has the same behavior here.
I agree with @domenic that this sounds like an issue to file with the browsers, in that we don't define side effects. At best, we have some informative recommendations in the "Printer" section, but nothing that can be considered normative.
There's a second ask here: being able to collapse in the middle of log. If browsers changed how they implemented filtering, would this still be a pressing issue? If so, do you have a pseudo-API to propose?
Unfortunately groupCollapsed has a major downside: group logs can never be filtered from a console, which makes them more expensive/noisy.
This appears to be a Chrome bug, based on your screenshots, and not an inherent restriction of groupCollapsed. Perhaps that's worth filing on the Chromium issue tracker?
Although my screen captures show Chrome, this behavior is also demonstrated by Firefox. It wasn't clear to me if this was adhering to spec or a "bug". Thanks for clarifying.
in that we don't define side effects
Ah! I think I just understood what you meant in this context.
Edit
There's a second ask here: being able to collapse in the middle of log. If browsers changed how they implemented filtering, would this still be a pressing issue? If so, do you have a pseudo-API to propose?
I think it would still be nice to be able to collapse mid-log. I imagine several React warnings might take on the format of:
<main error message>
<collapsed group with "component stack">
<link to more information>
There's a second ask here: being able to collapse in the middle of log. If browsers changed how they implemented filtering, would this still be a pressing issue? If so, do you have a pseudo-API to propose?
Right, right. I think the API I'm describing would still be a lot more user friendly. For example, even if console groups were hidden with a filter- you'd probably run into another problem:
I'm not too opinionated on the API. Maybe a new directive could work? e.g.
console.log(
"Example header\n\n%g\n\nExample footer",
"Example title",
"Example expanded contents"
);
Example header
▸ Example title
Example footer
console.error
hides stack traces by default, showing only the user-logged errors string:This is great because it reduces clutter in the console and makes it easier to scan for a particular message before digging in.
It would be fantastic if the console API exposed a similar opt-in behavior to developers (particularly framework developers) enabling us to define collapsable substrings within a logged message.
As just one example- React could make immediate use of this with our "component stacks" feature. A React DEV warning may currently look something like this:
With an API like the one I'm describing, maybe it could instead look like this.
Even if an API like this was limited to only allow for one collapsable string at the end, this would still be an improvement for e.g. large "component stacks"
Doesn't
groupCollapsed
do this?groupCollapsed
provides some similar functionality:Unfortunately
groupCollapsed
has a major downside: group logs can never be filtered from a console, which makes them more expensive/noisy.This feature request is loosely related to #163.