-
-
Notifications
You must be signed in to change notification settings - Fork 7
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
[Feature] Allow logging of arbitrary object without message #14
Comments
Howdy @abeforgit — thank you for this. Yeah its definitely I was in mind of when designing the api. I didnt want an exact 1-to-1 relationship with console.log. It was more for the storytelling aspects. But yeah maybe there is scope or use for just straight objects, or any data type other than string in that message argument. I can see value in something like a api or fetcher layer, where you may want it to simply log payloads coming back — the scope of the method would be that small that the diary name itself is descriptive enough. so So ya, let me have a ponder, see if anyone else chimes in with some ideas. If not ya will look at adding. 🕺🏻 |
Sounds like there are
Wondering - it is about expanding existing API, letting to do more(or less) stuff, or adding extra API/functionality a little aside, as it is actually a different use case |
Yeah I find that with a good diary name the message can become a bit redundant. It's also a slight deviation from the original One thing I could see happening is people avoiding the issue by using @theKashey I don't think adding extra API for logging objects directly is the way to go. It's basically already supported anyway, all you have to do is provide a message (or |
Usually, it's or "textural logs" or "json logs". Never both at the same time. |
I see what you mean, but I'd disagree. So I appreciate the current capability of allowing you to mix "text logs" and "object logs" |
But the request is about logging something without any message provided. Sounds like it can be solved with a little different 🤷♂️ wording:
|
__*BREAKING CHANGE*__ Log functions no longer require a message string in the first argument, this means reporters that used to tap into `extra` for the spread arguments you will now find this in the `messages` array. ```diff - const reporter: Reporter = ({ name, level, message, extra, ...rest }) + const reporter: Reporter = ({ name, level, messages, ...rest }) .. - console.log({ message, extra }); + const message = messages.shift(); + console.log({ message, extra: messages }); ``` fixes: #14
Hi @abeforgit sorry for the delay here 😅 We no longer restrict what you want to log, be it
|
__*BREAKING CHANGE*__ Log functions no longer require a message string in the first argument, this means reporters that used to tap into `extra` for the spread arguments you will now find this in the `messages` array. ```diff - const reporter: Reporter = ({ name, level, message, extra, ...rest }) + const reporter: Reporter = ({ name, level, messages, ...rest }) .. - console.log({ message, extra }); + const message = messages.shift(); + console.log({ message, extra: messages }); ``` fixes: #14
To more closely mimic the
console.log
api, it could be nice to allow the following:This technically works, but is not allowed by the types. But more importantly, this logs the toString representation of the object, rather than passing it to the default
console.log
formatter.I can see the benefit of restricting the api such that there should always be a message, so I would understand if you don't want to go for it. After all, when you are logging anything serious, providing no context is bad practice. But for the sake of uniformity, I like to use the same library for quick debug-logging which I will remove later as for "real logging" which will remain in the production app. It's purely a design decision and is not blocking at all, just thought I'd open the discussion.
The text was updated successfully, but these errors were encountered: