Allow clients to provide a custom log destination

[zoejessica]

Introduces a new logDestination property on HotwireConfig. When clients set this property, and set debugLoggingEnabled to true, Hotwire will send logs to this destination instead of the default OSLog.Logger that's currently used.

Notes

• This is a non-breaking change
• If debugLoggingEnabled is false, logs go to the same disabled OSLog logger as before
• Provides a public HotwireOSLoggerWrapper for easy injection of an existing OSLog logger
• Supports file, function and line macros that other logging systems may use to format output

[svara]

Nice addition @zoejessica 👌

[zoejessica]

Thanks @svara! I know @jayohms wants to have a look so we can synchronize the apis across platforms, so I'll leave this open for now 👍.

[jayohms]

I would prefer that this is not nullable and we set this to the default implementation here. Then, any place that needs to obtain the current logger instance can do it through Hotwire.config.logger and not need to hold additional state/logic for getting the custom instance or default instance.

[zoejessica]

Nice improvement - done in 3411eaa

[jayohms]

We have introduced a var logLevel: HotwireLogLevel as part of the HotwireLogger interface on the Android side. This lets apps set the log level directly on the logger instance via Hotwire.config.logger.logLevel = HotwireLogLevel.ERROR. Should we consider the same thing for iOS?

See: hotwired/hotwire-native-android@6f362bf

[zoejessica]

Reading the commit, this is where the user can pass in a log level, and any messages that don't have that or a higher criticality are excluded from the logs, correct?

I'm a bit wary of adding it on iOS, for the same reason that we removed the debugLogEnabled flag on this platform. We're sticking fairly close to the default system OSLog implementation, so it seems right to also lean on its handling of different levels. OSLog treats different log levels automatically, for example, a production app on device does not persist any DEBUG messages. (Which I think is quite different from the Android side?) So as long as we're being sensible about the kind of data we're sending to persistable-by-default logs, I think this makes sense.

The log level you choose determines how the system handles the message. The system stores all messages in memory initially, and it writes messages with more severe log levels to disk.

Users who were set on changing this behaviour could do it trivially in a custom implementation of HotwireLogger. For instance, if you wanted to persist all HN log messages regardless of how we've happened to categorize them, you could wrap an instance of OSLog.Logger and forward all the logs to the ERROR level. Or provide your own log level as a filter.