Skip to content
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

nestedKey in browser.write #2138

Open
WulfP opened this issue Feb 28, 2025 · 0 comments
Open

nestedKey in browser.write #2138

WulfP opened this issue Feb 28, 2025 · 0 comments

Comments

@WulfP
Copy link

WulfP commented Feb 28, 2025

I stumbled across pino on my way to encapsulate all business logic for some projects in individual classes, which are completely platform-independent. That's why I'm looking for a logging library that runs both in the browser and under NodeJs.

After some analysis, I think I have found the best working tool here, with which many things are possible.

What really irritates me, however, is that nestedKey has no effect in browser.write(), although all the arguments for it apply there in exactly the same way.

The structure of mixing metadata such as level and time with the payload data itself, which can then be delivered as msg (if type string) or rather unpredictably (if type object) via a single argument, doesn't really seem clean to me, to be honest. Apart from the dedupe-issues discussed, the formatting and further processing is not really pleasant. In my opinion, the two data-sources should be separated clearly. nestedKey would otherwise not be necessary.

Would a solution be conceivable that controls browser.write() via a switch similar to nestedKey so that two different arguments are passed, whereby the data with which the logging function was called with is moved to the new second argument?

In my opinion, this would be a much better solution for browser.write() than encapsulating payload-data it in a separate property. But of course, this would be an option too. I also don't see any danger of breaking changes.

At the moment, however, I can live with making this division manually using the list of known properties to split up the given argument. It's just not a really elegant solution.

Related at least with #874, #762, #883 and #792.

Thanks in advance for any constructive feedback!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant