Pino: method to get a child loggers bindings

[abuzarhamza]

Hi

I am using pino logger . Sometimes we need to get the attr we have to create an audit record.
Here my scenario

let pino = require('pino');

let p = pino({}).child({class: 'hello'});
p.info('hello');
console.log(p)

Is there any function to get the values of class we set for the child logger?

[mcollina]

I think we should refactor https://github.com/pinojs/pino/blob/master/lib/tools.js#L198-L216 so that every logger has a new function chindings() to retrieve these. Would you like to send us a PR?

[abuzarhamza]

@mcollina : one small question I do not find any documentation about chindings function and its usage. I can see it attached to pino object

[davidmarkclements]

@abuzarhamza matteo is proposing a chindings function be added, whereas the Symbol(pino.chindings) property is private (as are all symbol properties) so does not require documentation.

If you do want to create a PR around this, please make sure benchmarks aren't negatively impacted (and post results)

[yellowbrickc]

Hi @davidmarkclements @mcollina

I have some free time and would like to spend it by helping out in open source projects. Before I create an unfinished PR I have some questions:

• Do I get it right, you propose a simple refactoring making the function chindings() public? In tools.js there is already a method called asChindings https://github.com/pinojs/pino/blob/master/lib/tools.js#L137-L165
  I think this could be confusing.
• Should this property be available in pino.js as a property?
• what about proto.js (there is a funny comment, I'm not sure it is still used)

If you have something better for me to do just tell :)

[davidmarkclements]

@yellowbrickc cool!

• we’re talking about exposing a chindings method on every logger instance - the code that Matteo references is specific to the prettifier but could be repurposed and placed on all logger instances. asChindings isn’t exposed, and returns a string instead of an object. I could be renamed to getChindingsAsString but I think it’s fine as is.
• it should be exposed on every logger instance - the pattern would be to place it in tools.js and export, include in proto.js to expose as a public method
• it’s absolutely used.. are you referring to the comment about use of class syntax being satirical?

[yellowbrickc]

Yes :)

[davidmarkclements]

So that’s explained here https://github.com/pinojs/pino/pull/433#discussion_r194711807 (gh is opening the comment, open up the resolved discussion)

In terms of the satirical part, bit of an obscure inside joke - the three core contributors (to varying degrees) feel that es6 classes were a bad move, and that avoiding classes (in JavaScript) leads to better design patterns in general. We prefer a functional plus prototypical approach, which recognizes how the language actually works. However for debugging and profiling purposes I wanted the logger instances to appear as “Pino” - this requires a constructor property. I could have used a function as the constructor but used an empty class, so a class syntax was used in pursuit of avoiding class syntax. This is a good example of why not to make obscure references in comments.

[yellowbrickc]

Thanks for the explanation, now it is obvious that the proto.js is still used ;) And yes, I'm aware of the different opinions regarding classes and node... (I think classes belong to OOP languages and node is none.)

Ok, I want to solve this tomorrow or on Monday.
I will also extend the tests but I'm not sure where here https://github.com/yellowbrickc/pino/blob/master/docs/api.md#logger should the documentation be extended.

[mcollina]

I’d recommend to send a PR early.

I would document this after child().

[yellowbrickc]

This issue can be closed now.