| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Introduces a simple template literal tag that ensures that
each constituent part of the template literal passes through
`util.inspect()` using the default options.
```js
const inspectTag = require('util').inspectTag;
const m = {a: 1};
console.log(`${m}`);
// Prints: '[object Object]'
console.log(inspectTag`${m}`);
// Prints: '{ a : 1 }'
```
|
|
||
| // Without the tag: | ||
| console.log(`${obj}`); | ||
| // Prints: '[object Object]' |
There was a problem hiding this comment.
Can we place these before the line of code it's referring to? To me that seems to be the traditional place for such comments. Also the indentation makes it look out of place.
Sorry, something went wrong.
|
Seems like something good for userland. If core needs it, it could be internal, or in test/common.js. |
Sorry, something went wrong.
|
I've just wanted something like this recently for Error. |
Sorry, something went wrong.
|
|
||
| assert.strictEqual(`${obj}`, '[object Object]'); | ||
| assert.strictEqual(inspectTag`${obj}`, '{ a: 1 }'); | ||
| assert.strictEqual(inspectTag`${obj}-${obj}`, '{ a: 1 }-{ a: 1 }'); |
There was a problem hiding this comment.
Worth add a test when the end is a string(n === keys.length), and a test when there are no variables in the template.
Sorry, something went wrong.
There was a problem hiding this comment.
Is not an empty string always in the end of a template literal?
Sorry, something went wrong.
There was a problem hiding this comment.
Ah, yes.
Sorry, something went wrong.
There was a problem hiding this comment.
Really like this idea, but I'll defer to other collaborators for comments on code
Sorry, something went wrong.
|
|
||
| // With the tag: | ||
| console.log(inspectTag`${obj}`); | ||
| // Prints: '{ a : 1 }' |
There was a problem hiding this comment.
Another nit: '{ a: 1 }'
Sorry, something went wrong.
There was a problem hiding this comment.
Mind that util.inspect({a: 1}) returns '{ a : 1 }'
Sorry, something went wrong.
There was a problem hiding this comment.
> util.inspect({a: 1})
'{ a: 1 }'It's also this case in the test that comes with it.
Sorry, something went wrong.
There was a problem hiding this comment.
Oops, sorry, don't know where this comes from :/ Could be lack of coffee
Sorry, something went wrong.
| added: REPLACEME | ||
| --> | ||
|
|
||
| A template literal tag that ensures each replacement in a template string is |
There was a problem hiding this comment.
Nit: A template literal tag function
Sorry, something went wrong.
|
Why wouldn't you just use console.log('message', a, b) instead? I agree with @cjihrig. Why wouldn't we just do this in userland? -1 from me. |
Sorry, something went wrong.
|
Will close given the feedback. |
Sorry, something went wrong.
|
This seems like an obvious omission to me...? |
Sorry, something went wrong.
|
@alex-weej is there anything you can't do with console.log('message %s; object: %o; number: %i', 'test', { a: true }, 5) that you would be able to do otherwise (or using util.format(), if it's just about getting back a formatted string)? |
Sorry, something went wrong.
|
Really just about ergonomics. Logging is fine, but when you want to 'defer the logging' so to speak by stuffing some stuff in an Error, allowing some other piece of code to choose to log or not log later, you lose a lot of ergonomics. throw new Error("The thing was broken: " + util.inspect(foo) + ", " + util.inspect(bar) + ", " + util.inspect(baz));vs. throw new Error(util.inspect`The thing was broken: ${foo}, ${bar}, ${baz}`);What I see a lot of is people being lazy and just relying on some of them being strings, which inevitably leads to confusion when those strings contain unprintables, are empty, or the wrong runtime type entirely! throw new Error("The thing was broken: " + someString);> test("banana\x00\x01\x02rama")
Uncaught Error: The thing was broken: bananarama
at test (repl:1:35)
^ Lossy > test("")
Uncaught Error: The thing was broken:
at test (repl:1:35)
^ Confusing, you see this in a production log and it's not that obvious that someone was attempting to log an empty string. > test(undefined)
Uncaught Error: The thing was broken: undefined
at test (repl:1:35)
> test("undefined")
Uncaught Error: The thing was broken: undefined
at test (repl:1:35)
These two are ambiguous. I've definitely debugged situations where the string "undefined" is floating around. Urgh! > test({foo: 42})
Uncaught Error: The thing was broken: [object Object]
at test (repl:1:35)
Any JS developer who hasn't seen something like this a zillion times is lying haha. Hence, whatever we can do to make it easier to create unambiguous serializations for diagnostics would be a win in my book. Perhaps a way to form a string using the exact same paradigm as the console.log family would be nice? |
Sorry, something went wrong.
|
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
Introduces a simple template literal tag that ensures that each constituent part of the template literal passes through util.inspect() using the default options.
This is inspired by recent changes in tests that have tried to convert console.log('message', a, b) to something like:
`message ${a} ${b}`Checklist
Affected core subsystem(s)
util