Repository navigation
console: implement console.table and console.dirxml #17128
Description
Activity
if you're doing dirxml i'd be interested in trying out table
Reacted by Benjamin Zaslavskycurrently i tried just using
\tto separate columns, resulting in the output below, if anyone has a better idea let me know. We'll also need to use something else besides util.inspect on non-primitive values.// an array of strings console.table(["apples", "oranges", "bananas"]);
// an object whose properties are strings function Person(firstName, lastName) { this.firstName = firstName; this.lastName = lastName; } var me = new Person("John", "Smith"); console.table(me);
// an array of arrays var people = [["John", "Smith"], ["Jane", "Doe"], ["Emily", "Jones"]]; console.table(people);
// an array of objects, logging only firstName function Person(firstName, lastName) { this.firstName = firstName; this.lastName = lastName; } var john = new Person("John", "Smith"); var jane = new Person("Jane", "Doe"); var emily = new Person("Emily", "Jones"); console.table([john, jane, emily], ["firstName"]);
var family = {}; family.mother = new Person("Jane", "Smith"); family.father = new Person("John", "Smith"); family.daughter = new Person("Emily", "Smith"); console.table(family);
- addedconsoleIssues and PRs related to the console subsystem.Issues and PRs related to the console subsystem.feature requestIssues requesting new Node.js features.Issues requesting new Node.js features.
on Nov 18, 2017 Awesome!
IMHO the width of the columns should be controlled though, and maybe the table be defined with border, so to replicate browser implementation at the best.
Thanks for your work! Starting on dirxml today.
If it matters for any attempts to implement
table()(and it probably doesn't, but just in case), our current minimal implementation ofconsole.group()uses two spaces for each level of indentation and not a tab character.We could have gone with a tab character instead, but didn't in order to be consistent with what the
utilmodule does for indentation....although a tab character might make a lot more sense here for simplicity. I think a simple and lightweight implementation for something like
console.table()is more desirable (at least initially) than a full-featured implementation. My thinking is:- Most people won't use this function at all, so putting a ton of code into core for it probably isn't a good investment.
- But it is part of the living standard and it's currently exposed as a no-op, so a minimal implementation makes sense.
- If people want to add a lot of bells and whistles to it, a userland module can override
console.table.
Reacted by Benjamin Zaslavsky, snek, Bruno Scheufler and Reinaldo Antonio Camargo RauchI don't think we want borders or background colors or other things like in the browser. The browser gets to make lots of assumptions about the console environment, but we don't. The more complex it is, the more maintenance problems are likely to come up.
I'm feeling pretty +1 on separating with a tab character and not worrying about column widths or things lining up. If they don't line up, then the end user will need to adjust their tab width. That's unfortunate, but not terrible, at least for a first implementation. If there's a huge outcry for more features, they can come later. (And you now have an easy function for making tsv output to boot!)
If we want things to line up, it will mean getting the length of everything in the table, tracking it, and padding values appropriately. That's do-able, but bug-prone because you have to worry about things like surrogate pairs. I'm feeling really good about "separate with a tab character and let stuff end up wherever it ends up", although I imagine others might be concerned that we'll get bug reports. Maybe just make it clear in the docs that that is all it does.
@Trott Without going full length on replicating browser implementation, I think we should at least get a separation character to get a bit clearer.
But indeed, if it's clearly specified in the docs that this is a minimal implementation, we could drop on other "features".As for userland modules, I think one already exists. Maybe some inspiration can be found there? Although its implementation does not seem full of bells and whistles either tbh...
Quick question here, for advice.
Since Node.js doesn't deal directly with the browser DOM, it doesn't implement any DOMParser. This will evidently cause some problems to implement
console.dirxml(). But is it really necessary?I mean, the easy way would be to implement
dirxmlas an alias ofconsole.dir(). But since many APIs throughout the web are still using xml, wouldn't it be better to properly parse it? Do someone think there are a sufficient amount of users willing to properly log xml to justify implementing this method as the WHATWG defines it?Or am I just going through
util.jslooking for a way to proxy xml for nothing?I think the best thing Node can do for a situation like that is to provide a symbol that lets you override what
console.dirxml()does when it is called with an object that bears that symbol, kind of likeutil.inspect.customorutil.promisify.custom?@addaleax In that case,
util.inspect.customitself might do the trick?
Like, default-> alias forconsole.dir(), with Symbol -> whatever you want?Or is it so late that I don't understand squat?
Okay, I've worked out an absolute first draft, and soon will open a PR.
I'm currently learning toward providing the possibility to pass a third argument (the first two being the object to inspect and the options object, for consistency with
console.dir).
This last argument would either be a custom inspect function or a boolean indicating the object used as first argument has a.inspect()method (but will then be marked as deprecated).
Obviously, if the third argument is omitted or equals false, the method wil act just likeconsole.dir().Does that sound okay?
11 remaining items
- added a commit that references this issue
on Dec 3, 2017 - added 2 commits that reference this issue
on Dec 12, 2017 Just noticed, the 10.0 docs list
console.table()twice, once under the "normal" section and once under the heading for functions that only work with--inspect. I'm assuming that this issue meanstableis always available, so the second entry in the docs should be removed.@thw0rted you're perfectly right. I'm pretty sure the method has been implemented the last few days/weeks, but I can't find the PR. The docs may not have been updated completely. There's another PR opened, I'll pass your notice






Hi everyone!
Following #17004 , #17033 and a discussion with @Trott , I'd like to suggest we implement the remainder of the console methods described in the WHATWG living standard.
Most of them are already implemented, the only ones left are
console.table()andconsole.dirxml().Unless everyone thinks it's a waste of time, I'd like to give it a shot. But of course, help will be deeply welcomed.
In any case, I think I'll start off with
console.dirxml()if it's ok.Comments and advices welcomed!