console: implement console.table and console.dirxml

[Tiriel]

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() and console.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!

[devsnek]

if you're doing dirxml i'd be interested in trying out table

[devsnek]

currently i tried just using \t to 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);

---

[Tiriel]

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.

[Trott]

If it matters for any attempts to implement table() (and it probably doesn't, but just in case), our current minimal implementation of console.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 util module does for indentation.

[Trott]

...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.

[Trott]

I 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.

[Tiriel]

@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...

[Tiriel]

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 dirxml as an alias of console.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.js looking for a way to proxy xml for nothing?

[addaleax]

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 like util.inspect.custom or util.promisify.custom?

[Tiriel]

@addaleax In that case, util.inspect.custom itself might do the trick?
Like, default-> alias for console.dir(), with Symbol -> whatever you want?

Or is it so late that I don't understand squat?

[Tiriel]

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 like console.dir().

Does that sound okay?

[Tiriel]

First draft: #17146

[apapirovski]

These were added in #18137 and #17152

[thw0rted]

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 means table is always available, so the second entry in the docs should be removed.

[Tiriel]

@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