More explicit logger configuration #51
Replies: 1 comment 1 reply
-
It's true, I haven't made too much fuzz about the logger, and that's partly because I felt that it wasn't really "ready". One question I did intend to ask into the community was best practices regarding logging from libraries. I have had the same idea as you, passing it to a browser, and from a user's perspective, that certainly makes a lot of sense - giving each test case control of the level of output. It does seem to have the consequence that most objects need to have some extra logger field though, or embed - so the right logger can be used. Or maybe it makes sense to have a Also I wanted to have some kind of options on filtering on the types of messages. At the moment it's just based on log level. I'm not sure what would be the best approach here, so also something I would like input for. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Currently the logger is pretty hard to discover in
https://github.com/gost-dom/browser/blob/main/logger/logger.go
In many cases it's the only tool that we have to discover what went wrong.
I was wondering if it wouldn't make sense to inject the logger to browser instance (or window instance, whatever feels more natural).
I Imagine it as something like
Or, if you prefer functional opts
Beta Was this translation helpful? Give feedback.
All reactions