I could see that we might want to create a convenient view modifier that only requires a subsystem to inject a new logger in the lower environment?

I kinda like the idea of a dedicated view modifier (like logger(subsystem:category)) but at the same time am not quite sure if embracing standard SwiftUI mechanisms is the better route (e.g., .environment(\.logger, Logger(subsystem: "...", category: "...")).

If we have some elements that currently using a logger (e.g. ValidationEngine) that could maybe benefit from this?

I think a lot of components inside SpeziViews can benefit from this. For example, the AsyncButton and other views.

@Supereg Good point; doesn't really add a benefit to create new modifier just to add this small synthetic sugar that might be harder to understand. Looking at this it might not be worth expanding the API surface just for this.

Good point, might be good to see this tested and applied here @pauljohanneskraft to validate the API design within this package itself.

Logging isn't really used in this package that much in general (I found a static logger in ValidationEngine and regular print statements in Tests), so I'm not sure how to apply it really, since ValidationEngine even seems to be a case, where using the Environment isn't necessarily the most elegant solution (since we would somehow need to inject that logger into ValidationEngine and Logger isn't Equatable, so we can't easily observe when it changes).

About SpeziAccount: It currently has its own implementation of a LoggerKey and it is only used in a way that an app can inject a custom Logger, but doesn't create its own Logger (except for the default value), so I kind of see this as the app being able to inject a Logger to the used views - not the views defining a new logger for its own subviews.

I think looking at #9 I would suggest to add some more functionality for this that the extension provide convenient mechanisms to inject their own Logger instance for all of their subviews (e.g., providing better defaults for the whole app, or something like SpeziAccount would want to inject it's own logger for all of its subviews).

This comment kind of goes the other way, which is why I'm mentioning this. I currently see this feature as Spezi purely reading the logger from the environment and the app primarily setting the logger. What do you think?

@pauljohanneskraft @Supereg Wondering how we should progress about this PR and/or if we should close it.

It might rather make sense to add a logging Module in Spezi that would be environment accessible and could be used to generate derived loggers for Spezi modules and possibly allows access in a SwiftUI environment using the Spezi Module mechanism?

@pauljohanneskraft @Supereg Wondering how we should progress about this PR and/or if we should close it.

It might rather make sense to add a logging Module in Spezi that would be environment accessible and could be used to generate derived loggers for Spezi modules and possibly allows access in a SwiftUI environment using the Spezi Module mechanism?

I think there are two different reasons for improved Logger support in the SwiftUI context that were mentioned in the original issue description:

• There are small, reusable and composable views (like AsyncButton would be) which are typically owned by their parent view and may reuse their logger. While we mention views from SpeziViews as example, there aren't any views that would actually use that as, e.g., AsnycButton doesn't log anything. If we would add support for that, doing a simple logger environment key would probably be the best idea here. However, I'm more and more leaning towards not supporting that as a) we do not really have a use case ourselves and b) if we cannot provide an automatic injection of a Logger it don't see people doing manual injection a lot.
• The other use case is that views want to easily access the Logger of a Module they are linked to. If they are tied to a EnvironmentAccessible module, they might just access the Module via the @Environment property and directly access the logger property. The question is, should we support a mechanism that doesn't require a Module to be environment accessible for that? Something like a @Logger(MyModule.self) var logger DynamicProperty that basically uses the approach @PSchmiedmayer explained under the hood.

Thanks for the context @Supereg!
I think the last option is one to consider, but I have been thinking a bit about this and I am not sure if this is worth the infrastructure surrounding it without a few clear use cases where we ran into issues that made this impossible. Ideally, larger-scale logic that requires a logger should be moved into modules or view models anyways that could constrain their own infrastructure.

As long as the different loggers in the Spezi ecosystem use a similar edu.stanford.spezi prefix, it is also easy to filter them out in the logging console, which should also make this an "easy" mechanism not really requiring infrastructure from our side.

If a developer really wants to access a logger from a module, they could then access it using the environment and access its logger instance (but arguably probably just call a function of the module). I would therefore lean toward not adding something specific around this for now, just pointing toward using a logger instead of print statements within our documentation and maybe even as a hint in SpeziViews.