Allow clients to provide a custom logger instance #159
Conversation
jhutarek
left a comment
jhutarek
left a comment
There was a problem hiding this comment.
Thanks! I'd consider a couple of tweaks. 🙏
core/src/main/kotlin/dev/hotwire/core/logging/DefaultHotwireLogger.kt
Outdated
Show resolved
Hide resolved
core/src/main/kotlin/dev/hotwire/core/logging/DefaultHotwireLogger.kt
Outdated
Show resolved
Hide resolved
|
I started a draft PR to update the website here: hotwired/hotwire-native-site#91 |
* main: Add Session tests to cover visits with restorationIdentifier logic Fix restorationIdentifier + "restore" logic so that "replace" visit actions don't get unintentionally rewritten Fix test formatting Bring back the synethic current visit restore approach, since turbo.js does not always play nicely with same-page "restore" visits Fix documentation Maintain same-page "restore" visits and dispatch a custom event so the web bridge library can be notified when this occurs Fix restoring a web visit after visiting a native screen by manually caching a snapshot when leavin the web screen.
…t what the application wants logged. This also allows consumers to change the log level without writing a full custom logger implementation.
|
@mbarta @jhutarek Please take a look at the latest changes. By introducing a |
|
Happy with the latest changes @jayohms! It's closer to a standard logger implementation where you can set the desired log level for the default logger while still being able to provide your own if more customisation is needed 👍 Thanks! |
This PR drops the
debugLoggingEnabledconfig flag and instead allows client apps to set their ownHotwireLoggerimplementation.The default
DefaultHotwireLoggerlogs debug messages to Logcat based on theBuildConfig.DEBUGvalue and always logs warnings and errors. If clients need to handle debug logging differently or require logging to other destinations (file, Sentry, etc.), they should provide their own implementation ofHotwireLoggerand set it in theHotwire.config.