This is an area that we’re interested in improving, and are proposing a new feature, based on the console.context() method, to enable helpful contextual logging in DevTools.
Logging can be a very helpful way to debug problems, and we know that many web developers like the simplicity of logging, over the more involved process of breakpoint debugging. However, having to sort through hundreds of console log messages can quickly become difficult. It’s hard to identify which log comes from which part of the application, and it’s hard to filter logs.
We’re proposing a way to log to the browser console in a contextual way, and we’d love your feedback about the proposal. To read the full proposal, see our explainer: DevTools contextual logging with console.context(), and provide feedback about it by opening a new issue on the repo.
Enhancing console.context()
The context()
method of the console
namespace is a method that already exists in Chromium-based browsers. This method accepts a context name and returns an object that implements the same interface as the console namespace:
const myLogger = console.context("name-of-my-context"); myLogger.log("This is a log message from my context"); myLogger.warn("This is a warning message from my context");
This allows you to create different loggers for the different parts of your application. Each log that’s emitted by one of these loggers belongs to a context, and you can later filter by context in the Console tool in Edge.
We think that console.context()
is a great solution to the challenges of having to deal with many log messages, but we want to go further and address its limitations:
- We want to help standardize the method so that other browsers can also implement it. See the specification discussion on the WHATWG repository.
- We want to make contexts more visually recognizable.
- And, we want to make it easier to filter messages by contexts.
Making contexts visually different
The first improvement we’re proposing is to make each context truly unique and quickly recognizable by giving it a color.
Currently, contextual loggers produce messages that look just like regular logs:
We want to improve this as follows:
const myColoredLogger = console.context("storage", { color: "lemonchiffon" }); myColoredLogger.log("This is a log from my contextual logger");
The above code would display the log message in the Console tool, preceded by a badge that shows the context name and color, so that it’s easy to quickly recognize where the log comes from:
We’d love to hear your feedback on this proposal as we’re considering multiple alternatives such as:
- Using
%c
formatting in the context name, instead of introducing a second parameter for the color. For example:const myColoredLogger = console.context("%cstorage", “background:red;color:white”);
- Not requiring developers to define colors and letting DevTools do it. This would make it easier to use the
context()
method and DevTools would generate accessible background and text color combos for you. - Using the color as the outline of the badge rather than its fill color, which would avoid text contrast accessibility issues, but might be harder to quickly visually differentiate.
Making it easy to filter contextual logs
The second improvement we’re proposing is to make it much easier to filter the messages that originate from a given context only. Currently, to filter the logs from a console context, you must enter context: <name of the context>
in the filter of the Console tool. We think we can improve this.
We’re proposing to list the contexts that were created by an app in the Console tool’s sidebar:
In the above example, the app created two contexts: App and Storage. Clicking on any of these context names in the sidebar would show only the messages that belong to that context. In addition, it would be possible to expand a context and review the number of errors, warning, info, and debug logs in that context, and display only those messages.
Let us know what you think
Does the console.context()
method seem useful? Do the proposed improvements match your use cases? Are there any other or different changes you would like to make?
If you have any questions, comments, or suggestions, please let us know by opening a new issue on the MSEdgeExplainers repo.