In the past I inherited a project with a lot of logic implemented directly client-side.
Mainly most of the actions did not use any filtering strategy for the application log.
In each client action the LogMessage action was used and in each javascript block there were $public.Logger.log/error and console.log/error
The main problem was that much of this information that was being logged was inherent only to development and made no sense to exist outside of that environment.
Outsystems allows audit events to be disabled from the module configuration but this represented a loss of information as some of this logging was actually useful, so the solution was to refactor the log management.
Out of this experience came the Client Logger component ( it is published on forge ) that allows you to enable/disable and configure logging levels in the browser console and in service center.
To this day I often find myself discussing with colleagues/professionals about various strategies for governing client side logging processes.(some log only via server/service action and avoid client-side logging altogether)
Do you have any favorite patterns or strategies that you use in your projects?
I only implement logging when it's useful, e.g. for trouble shooting or when a complex project is just starting and we expect some bugs we need to be able to trace. But I'd avoid having logic that logs (or doesn't log) depending on some setting, because you'll always be checking whether to log or not, and that takes (some) time, with possible performance issues.
I appreciate that some developers really want to log everything, but in general, be careful what you log.
I agree with @Kilian Hekhuis.
In server-side Outsystems already make this for you, of course exists some specific cases/requirements to log changes etc.
On client-side I don't like to do it, only if I'm debugging something. You will be putting weight on your application in which use should be minimal or none.
Regards