mirror of
https://github.com/Nanaloveyuki/BitLogger.git
synced 2026-07-27 10:22:18 +00:00
📝 clarify root logger target behavior
This commit is contained in:
@@ -37,6 +37,7 @@ Detailed rules explaining key parameters and behaviors
|
||||
- This is a public root struct, not a type alias.
|
||||
- The current fields are `min_level : Level`, `sink : S`, `target : String`, and `timestamp : Bool`.
|
||||
- The sink type parameter is preserved across composition, which is why helpers such as `with_context_fields(...)`, `with_filter(...)`, `with_patch(...)`, and `with_queue(...)` can return more specific logger shapes.
|
||||
- The root logger also preserves the core target contract used across the sync API surface: `log(..., target=...)` can override the target for one call, while fixed-level helpers such as `trace(...)`, `debug(...)`, `info(...)`, `warn(...)`, and `error(...)` continue using the stored logger target unless code derives another logger first with `with_target(...)` or `child(...)`.
|
||||
- `Logger::new(...)` constructs this type as the main synchronous entry point.
|
||||
- This root type is also what sits underneath both facade families: `ApplicationLogger` is a direct alias over the configured `Logger[RuntimeSink]` line, while `LibraryLogger[S]` is a narrowing wrapper around a `Logger[S]` value.
|
||||
|
||||
@@ -53,6 +54,17 @@ let logger : Logger[ConsoleSink] = Logger::new(console_sink(), target="app")
|
||||
|
||||
In this example, the root logger keeps the concrete console sink type visible for later typed composition.
|
||||
|
||||
#### When Need A One-call Target Override On The Root Logger
|
||||
|
||||
When sync code should keep one logger value but emit a single record under a different target:
|
||||
```moonbit
|
||||
logger.log(Level::Error, "boom", target="app.audit")
|
||||
```
|
||||
|
||||
In this example, the emitted record uses `app.audit` only for that one call.
|
||||
|
||||
And later `trace(...)`, `debug(...)`, `info(...)`, `warn(...)`, or `error(...)` calls still use the logger's stored target unless code derives another logger first with `with_target(...)` or `child(...)`.
|
||||
|
||||
#### When Need To Build A Composed Logging Pipeline
|
||||
|
||||
When code should start from one root logger and then derive more specific wrapped forms:
|
||||
|
||||
Reference in New Issue
Block a user