Feature request: being able to update a already logged value

[sroucheray]

Goal: See an over time fast updating value without flooding the logs.

When a computed value is often updated, as when using requestAnimationFrame, one often want to see the evolution of that value over time. Using console.log might work but if you log other values at the same time, those are hidden in the log flow which make analyzing them very difficult.

Chromium devtools now have implemented live expressions, a feature not related to the console API but which facilitate this kind of workflow. Unfortunately it falls short by not providing a way to emit live expression values from any part of the code. One can only log live expressions from global values.

It would be nice to have a console.live method that would populate, not the log panel, but a live expression UI.

This method could open new ways of consuming logs like displaying a graph of the updated value over time.

As discussed bellow, a new method on the console API is not very practicable. So I propose to add a new formatting specifier for this use case.

%u (for update) could be used to indicate a value changing over time.

Example:

console.log('%u', x); // Would notify the agent that the value x is going to be logged several times
console.log('%uLabel', x); // Same but binding a `Label` to the updated value
console.log('%u%f', x); // With float
console.log('%u%i', x); // or integer modifier the value could be interpreted in a more a advanced UI like a timeline

A user agent then could interpret the log specifically and display the value in a dedicated UI (e.g. like in the live expression of the Chrome DevTools). An agent not implementing the %u specifier would just ignore it.

[captainbrosset]

For information, this was also discussed in this thread on Twitter: https://twitter.com/sroucheray/status/1432281432689364993

I kind of like this idea, but I'm a bit on the fence.

On one hand, the console API does one thing only: gather logs from code. It's up to the consumer of these logs to show them in interesting ways. Whether or not the consumer has the ability to show live expressions shouldn't really be something that the console API cares about.

On the other hand, the console API already goes further today than just producing logs, since it supports the group functionality.

One option, which doesn't require API changes, and which was pointed out to me by @OrKoN: Chromium DevTools could add a checkbox (or something) when users go and add a log point in the Sources panel to choose whether they want the log to be in the normal console output, or in the live expressions area. This would address the need to emit live expressions from any part of the code, and wouldn't require code changes.

[terinjokes]

On the other hand, the console API already goes further today than just producing logs, since it supports the group functionality.

It defines an API to push a label onto a stack and pop off the stack. It's up the the agent to do anything with that information (maybe it groups like the Chrome DevTools, maybe it appends a label in structured logs).

Chromium DevTools could add a checkbox (or something) when users go and add a log point in the Sources panel to choose whether they want the log to be in the normal console output, or in the live expressions area.

I actually thought this already existed, and had to double check. It would be my recommendation as well.

[sroucheray]

Thanks for the comments.

I totally understand the need to limit new public APIs, but if you don't mind I still extend the discussion to check if this case is worth it or not.

I was looking at console.dirxml (and console.dir), as stated in MDN it seems that calling this method defines the way the agent needs to display the logged value (Correct me if I'm wrong).

The console.dirxml() method displays an interactive tree of the descendant elements of the specified XML/HTML element. If it is not possible to display as an element the JavaScript Object view is shown instead. The output is presented as a hierarchical listing of expandable nodes that let you see the contents of child nodes.

Is it different than what would do a console.live call? The agent would log the value to a live expression area (or to a graphic view...) if it has implemented it or could simply fallback to logging the value as would do console.log otherwise.

Other thought. To keep the existing method signatures untouched. Would it make sense to augment the formatting specifier to include some sort of special value that would say "this value will be updated later and it would be preferable to show it in a UI that persist across calls and to update it in place." ?

Finally about the Chrome Devtools checkbox idea. I think it's totally worth it and it would add a new valuable tool to web developers (as a side note I didn't find a proper way to make a feature request on the chromium bug site). But I think it's a parallel idea and it doesn't mean that adding this feature to the console API is irrelevant, otherwise we wouldn't need console.log as the DevTools implemented an Add a logpoint... contextual menu.

[terinjokes]

dir and dirxml predate this specification, you can find old threads where I pushed back on including them.

[sroucheray]

dir and dirxml predate this specification, you can find old threads where I pushed back on including them.

Right, I see it here https://github.com/whatwg/console/issues/27#issuecomment-170985946

I think a new method is not the best strategy for a feature request. I am going to rephrase and suggest a new formatting specifier.