Open M0ns1gn0r opened 2 days ago
Yes, we should give users the option to choose how they want to handle the parent logger's sinks or filters, e.g.:
[
{
category: ["App"],
level: "info",
sinks: ["console", "backend"],
},
{
category: ["App", "Screen1"],
level: "debug",
sinks: ["console"],
parentSinks: "override", // "inherit" by default
},
]
How do you see an API like the one above?
In my mind, the more convenient API would be to apply only the sinks that were explicitly specified:
{
category: category('App'),
level: 'info',
sinks: ['console', 'backend'],
},
{
category: category('App', 'Screen1'),
level: 'debug',
sinks: ['console'], // overwrites the sinks
},
{
category: category('App', 'Screen2'),
level: 'debug',
// sinks not specified - keeps the parent sinks as is
},
I think that's OK because the number of sinks should be relatively small. It shouldn't be a problem to duplicate a subset of the parent's sinks if needed. An additional benefit is the complete transparency of what sinks are going to be applied, without the need to mentally go through all parents and combine them.
That makes sense, but there are two main considerations for me:
If overriding the parent logger's sinks becomes the default behavior, it breaks backward compatibility.
If you have a relatively large number of categories, it's cumbersome to manually copy the parent logger's sinks, and it's easy to make mistakes when adding or removing sinks.
Therefore, I think it should be a choice whether to inherit or override the parent logger's sinks, and the default should be inherit.
I have the following configuration:
When I log something with the Screen1 logger, the message is written twice to the console and sent once to the backend. What I want is to exclude specific categories from the sinks configured by default.
I think it is more logical to resort to the parent sinks only if the child sinks are not configured.