Proposal-temporal: Improve browser console output for Temporal objects?

[justingrant]

One minor annoyance when writing Temporal code is the devtools console output of Temporal objects, esp. compared to other built-in objects like legacy Date.

What is Date doing to get that pretty output... and could Temporal objects do the same thing without breaking the "valueOf() throws" behavior discussed in #517 and implemented in #632?

[ljharb]

Nothing, dev tools are deciding to display it that way, and they can decide to display Temporal objects any way they like (and the spec has no authority over that).

[ptomato]

That said, in the polyfill we could add some usage of util.inspect.custom for Node.js only.

[justingrant]

Also, there's apparently a chrome-specific debug formatter mechanism that might be appropriate for the polyfill: https://docs.google.com/document/d/1FTascZXT9cxfetuPRT2eXPQKXui4nWFivUnS_335T3U/preview#heading=h.xuvxhsd2bp05

[gibson042]

A good start would be removing uglify minification from the docs rollup, which would preserve the full source with including class names. Beyond that, I think there's a tradeoff between polyfill usability and spec fidelity. Would it be out of the question to e.g. include methods like [util.inspect.custom](depth, options){ return options.stylize('Temporal.DateTime', 'special') + util.inspect(--depth >= 0 ? this.getFields() : `${this}`, {...options, depth, sorted: false}) } and/or for the constructors to run Object.defineProperty(this, "_value_", {value: this.toString()}) in the presence of a DEBUG flag added by rollup?

[ryzokuken]

I honestly believe "trying the proposal out in a playground" is a very niche use-case compared to the use-case of using the polyfill in a JavaScript application, and we shouldn't prioritize the console output over the bundle size. That said, we can provide both minified and non-minified bundles and use the non-minified version in the playground.

[justingrant]

I honestly believe "trying the proposal out in a playground" is a very niche use-case compared to the use-case of using the polyfill in a JavaScript application, and we shouldn't prioritize the console output over the bundle size.

Yep agreed. I think @gibson042 is talking about the case where the app developer is using a bundler (not downloading the polyfill debug or release bundle directly), so the developer would leverage the app bundler to exclude debug-only Temporal code from release builds of the app, just like users do with debug logging in other libraries like React. Richard, is this correct?

BTW, having more readable console output isn't just for the playground. AFAIK, it's also used in browser devtools or an IDE while debugging the app, e.g. when inspecting variables in the console or Watch pane while stopped at a breakpoint. Unlike playground, this is a very common use-case for app developers.

[ryzokuken]

it's also used in browser devtools or an IDE while debugging the app, e.g. when inspecting variables in the console or Watch pane while stopped at a breakpoint.

I don't think it should be a major priority to be honest, since a majority of power users who need Temporal in production would use it once it's in the browser...

[ptomato]

After today's research call I do think this should be addressed with higher priority. We saw how copying and pasting a Temporal code snippet into the browser console resulted in a mystifying Object { } response.

[justingrant]

I agree. Typing .toString() over and over again in the browser console is getting pretty tiring.

[ljharb]

In node, you can define a util.inspect.custom Symbol method to display a custom inspection result; Symbol.toStringTag should help as well; perhaps browsers have an inspection hook as well?

[ptomato]

Chrome does (see Justin's link a few comments up) although you have to enable an obscure setting for it to work in the first place. Firefox does not, and also does not use Symbol.toStringTag in its formatter for objects.

We could use the trick Richard mentioned above and define own data properties, something like _t_: 'Temporal.Date', _s_: '2020-06-25' to at least get something more than Object { } in the Firefox devtools.