pq / logs

A lightweight logging framework for Flutter

logs

A lightweight Dart logging framework

---

Background and motivation can be found in the associated flutter tracking issue: flutter#21504.

Some relevant implementation considerations can be found in the discussion around proposed changes to flutter foundation (flutter#21505 and flutter#22041).

logs's Issues

create a logger that can log http calls

We can use the dart:io static field HttpOverrides.global (https://api.dartlang.org/be/158675/dart-io/HttpOverrides/global.html) to register an HttpClient subclass that logs for all http calls (start, end, error, ...). That would give people visibility into the network traffic for their app.

consider a logData call (and support for markers)

From #3 (review):

I wonder if we should have both a log() call and a logData() call. Are we ok with only being able to log objects (jsonable objects), or do we want the ability to log string messages as well?

Regarding markers:

For a data pipeline for tools, just logging objects works. But people may want to log marker events as well:

log.log('cache', 'evicting $number cache entries');
log.logData('cache', entries.first);
...
log.logData('cache', entries.last);

make logging play nice w/ web logging

Playing nice w/ web logging is important for folks w/ shared code.

/cc @matthewtsmith @johnpryan

I'd like to be able to log an error and optionally a stacktrace

Something speculatively like logError(channel, message, error, {stackTrace}), but likely w/ support for a function callback to actually populate the last three params.

This would coorespond to the message, error, and stackTrace params from https://api.dartlang.org/be/158704/dart-developer/log.html.

open question about logging data objects

The current plan is to support this by converting them to json, then logging them through the String message param in the dart:developer API.

I'm not sure this will support all use cases (but haven't thought this through in detail). There are some advantages to allowing an object to be logged, ala the inspect(Object data) call (https://api.dartlang.org/be/158637/dart-developer/inspect.html). The reference to it is sent over the service protocol, and the original object still exists in the VM side of the wire to interact with.

log when reloads and restarts happen

[meta] ensure programmatic API has parity w/ service protocol comms

Kind of a meta-issue but it's likely that some folks will prefer programmatic logging configuration (see for example, #22) so we should make sure that anything that can be done via service calls can also be done programmatically. (In particular this serves the common pattern of a dedicated main_dev.dart to configure logging and debugging options.)

support logging in release

Chatting w/ @matthewtsmith and @johnpryan (from apptree), it became apparent that for their use cases, allowing for logging of release builds is important.

Status of this package ?

Hey there!
I've found this package from https://flutter.github.io/devtools/logging.html for logging http calls.
I am wondering about the status of this package. Is it still the recommended way to log http calls ?

LogManager.initServiceExtensions should be allow multiple calls

Calling LogManager.initServiceExtensions more than once should only cause one registration - client code won't know if it's already been called, and may call it itself.

(re)consider initialization

Currently logging channels need to have been registered before they can be enabled. This ends up being complicated for clients.

An easy fix would be to track enablement irrespective of registration.

Not sure there are any downsides...

/cc @devoncarew

support remote logging

Related to #21, @matthewtsmith and @johnpryan described a desire to log remotely.

Use case: would like to redirect logging output to firebase to capture debugging data from devices in the wild.

https://github.com/SwiftyBeaver/SwiftyBeaver came up as a reference point.

I think for us to support this we just need something as simple as a listener interface a la package:logging where you can do something like:

Logger.root.level = Level.ALL;
Logger.root.onRecord.listen((record) {
  // redirect here...
});

/cc @devoncarew

explore ideas from message templates

https://messagetemplates.org/

A language-neutral specification for 1) capturing, and 2) rendering, structured log events in a format that’s both human-friendly and machine-readable.

address all TODOs in `http` logging

Currently there are a number of places we'll potentially spam stdout w/ "TODO" messages.

AIs:

• identify calls we want to log
• implement them
• remove all remaining _todo() calls

if we want to rely on json encodeability for data objects, we should have an optional convert param for LogMessageCallback

If we want to rely on json encodeability for data objects, we should have an optional convert param for LogMessageCallback (the same as what dart:convert's encodeJson takes) - jsonEncode(Object object, { Object toEncodable(Object nonEncodable) }).

consider auto-registering vm service protocol registration

It would be great to avoid needing to explicitly initialize VM service hooks.

That is, it would be nice to do away w/ the need to call:

logManager.initServiceExtensions();

Thoughts:

1. we could do this proactively in the manager (con: carry the cost of an extra service extension even if it's not used; pro: would work in profile / release and not require any code changes or client footwork)
2. clients could do this (e.g., IntelliJ could use EvalOnDartLibrary to call something like initServiceExtensions()) -- con: only works for apps being debugged

improve log API

Follow-up from #16 (comment), minimally we should add:

• a toEncodable callback (#10)
• logError and
• support for data objects

@devoncarew: would 2 calls be sufficient?:

void log(MessageCallback messageCallback, {Object data, toEncodable(object)});

void logError(MessageCallback messageCallback, {Object error, toEncodable(object), StackTrace stackTrace});

Or do you think there's benefit in making a distinction between log and logData?

logging a string changes it's value slightly

Right now, the api converts all logged objects into their jsonable equivalent. So, log('foo_channel', () => 'My message') will convert that string param into its jsonable equivalent (which is "My message").

We then essentially get "My message" in the client instead of My message.

v 1.0 doc punchlist

docs for 1.0:

• README
• API docs
  • levels in general
  • how to log an error in particular #12 (comment)