-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
Do not parse command complete info unless accessed #3511
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Slight change in behavior of the props of the result with this as those fields won't appear in any default serialization for things like logging:
class Props { constructor() { this.foo = 123; } } class Getter { get foo() { return 123; } } function debug(obj) { console.log('%j', { keys: Object.keys(obj), obj, }); } const p = new Props(); debug(p); const g = new Getter(); debug(g);
$ node test.js
{"keys":["foo"],"obj":{"foo":123}}
{"keys":[],"obj":{}}
I doubt it matters in most apps in practice but may be good to call it out in the changelog.
I doubt it matters in most apps in practice but may be good to call it out in the changelog.
hmm honestly it might not be worth changing if its gonna secretly break something esoteric on some deployed system. I didn't really notice much perf gain at all between the two implementations.
Thanks for your thoughts!! ❤️
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Speaking of esoteric backwards compatibility needs: since the minimum Node version is 16, private class fields are fully supported. Could start using those instead of an underscore prefix for everything, to make future backwards compatibility easier to manage (since there’s no way user code can come to rely on private fields, whether it’s through direct access or stringification).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could start using those instead of an underscore prefix for everything, to make future backwards compatibility easier to manage (since there’s no way user code can come to rely on private fields, whether it’s through direct access or stringification).
i love this idea. you're so awesome, ty!
This is probably a bit of a micro-optimization, but in my own codebases the number of times I access any of these properties is nearly zero. So, not parsing the command complete message unless there's a reason to do so (user wants to know about the command complete info) seems reasonable.