[Feature] Allow logging of arbitrary object without message

[abeforgit]

To more closely mimic the console.log api, it could be nice to allow the following:

const logger = diary("myScope");
const myCoolObject = { foo: "bar" };
logger.log(myCoolObject);

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.

[maraisr]

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 diary('things').log({ payload: 'things' }) seems good enough for there.

So ya, let me have a ponder, see if anyone else chimes in with some ideas. If not ya will look at adding. 🕺🏻

[theKashey]

Sounds like there are

• story telling use case, which (probably) give diary a name
• structure logs use case, which is more applicable for, well, "logs"

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

[abeforgit]

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 console api which might trip up users (only once, really, but still) Ultimately it's about control I think. Do you want to "force" users to use best practices? or do you allow them to use it however they want?

One thing I could see happening is people avoiding the issue by using console directly when the lib doesn't behave how they expect. Or passing "" as the message, which would be a bit silly.

@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 "" if you really have nothing to say). I think extra methods would only increase confusion without adding value.

[theKashey]

Usually, it's or "textural logs" or "json logs". Never both at the same time.

[abeforgit]

I see what you mean, but I'd disagree. Simple usecase for example is logging method calls. I use a decorator to make this easy to add to interesting methods. It prints: Calling ${methodName} with args: and then the args as objects. It's very useful to print them as objects since this is the browser and the browser console has some really powerful built-in logging formatters (especially for things like DOM nodes).

So I appreciate the current capability of allowing you to mix "text logs" and "object logs"

[theKashey]

But the request is about logging something without any message provided. Sounds like it can be solved with a little different 🤷‍♂️ wording:

• strict mode, enforcing you to follow some "model"
• flexible mode, where you can do whatever you want 👈👈👈 the one you are looking for

[maraisr]

Hi @abeforgit sorry for the delay here 😅

We no longer restrict what you want to log, be it info('bob'), info(), or info({ foo: 'bar' }). We will respect this.

message[0] will still format, if it's a string.