[idea] enrichers

[SbiCA]

hey @lukaknezic thx for this awesome lib!

We've recently adopted it in our code base and here a a few things that we've stumbled across maybe it's just our experience but nevertheless I thought it's probably worth sharing.

Idea for adding enrichers similar to https://github.com/serilog/serilog/wiki/Enrichment which would probably be a bigger change but if the lib allows to user structured logging e.g. message templates instead of strings there is a log more context that can be passed. My use case is usually either around global e.g. user id, server or temporary some sort of action, operation e.g. payment state context that's important to have.

2nd thing which it noticed is that the message templates could be configurable I really like the pretty printer but would love to change the template e.g. use different emoji or order of properties or for time critical / not critical code adjust the timestamp precision that gets printed

Cheers

[itsJoKr]

@SbiCA My two cents:

For the first one

I don't think there's as much of Enrichment you could have from a base Flutter. Anything like user info or payment info depends even device info it depends on your project and the packages that you use. So unlike .NET, I don't think we could offer any valuable enrichments out of the box. You would need to create them all.

For the second one

My suggestion for 2nd one is just to go into PrettyDeveloperPrinter, copy-paste it and change to your liking. It's a simple class (40 lines of code), and you'll get a hang of it easily.

Because when I think of customization of logs, there are thousands of users and every one of them could need something custom for their liking. So it's hard to know what exactly you want to expose.

[SbiCA]

@itsJoKr thanks for the feedback, I'll try to be more concrete since as mentioned this were just my observations and ideas how to improve the library

structured

on the enrichment idea to me this wouldn't be about the out of the box enrichment more about the possibility to use structured logging with it's benefits hence as a user of loggy I can choose to provide more context. As a logging sink / backend the context can used to search/index. In our case we're always interested in userId or eventId context for an event business but this could also be screenName or any other context sensitive information that you want to combine with the log statement.

final userId = 1;
final eventId ="some-id"
loggy.info('this happened for {userId} and event {eventId} ', userId, eventId);

// this will produce not just the string but a json/dynamic structure like 
// { messageTemplate = 'this happened for {userId} and event {eventId} ', userId =1, eventId ="some-id"}
// and can be printed by any printer
// e.g. simplest form to console '[INFO] this happened for 1 and event some-id
// but to crashlytics for instance you can add all custom fields

so essentially I think it would me to extend LogRecord with the custom props and embrace a sort of template.

enrichment

the enrichment can probably even by using the LoggyType mixin since as an app developer you can come up with a type that for instance requires a certain context. E.g. ScreenName as long as LoggyType allows to push those enrichments per LogRecord so I guess it kind of assumes strucutred logging btw. this is also in use in OTEL which I guess just didn't make it to the mobile world yet ;) https://opentelemetry.io/docs/concepts/signals/logs/#structured-logs