-
-
Notifications
You must be signed in to change notification settings - Fork 171
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cljs: JS objects are printed uselessly #356
Comments
@DerGuteMoritz Hi Moritz, thanks for pinging about this. My quick first impression: Middleware will work, but may be needlessly expensive. Could provide some kind of option for a transform at that point, though need to think about the possibilities and tradeoffs. Thoughts/ideas also welcome! |
This will be addressed in forthcoming release. Two relevant changes:
Thanks again for pinging about this 👍 |
Status While now undocumented, backwards compatibility will be retained since: 1. The back compatibility is cheap and simple 2. Appenders in the wild may already depend on the argument (incl. several community appenders) Motivation The problem with :msg_ is that its behaviour can't be easily customized, and customization can be useful (e.g. for #356). So instead of hard-coding a particular :msg_ generator as before, the responsibility of message generation will now be handled as just another aspect of output generation (i.e. handled by output-fns). Note that output fns already have rich customization facilities, incl. per-appender fn and options overrides.
Status While now undocumented, backwards compatibility will be retained since: 1. The back compatibility is cheap and simple 2. Appenders in the wild may already depend on the argument (incl. several community appenders) Motivation The problem with :msg_ is that its behaviour can't be easily customized, and customization can be useful (e.g. for #356). So instead of hard-coding a particular :msg_ generator as before, the responsibility of message generation will now be handled as just another aspect of output generation (i.e. handled by output-fns). Note that output fns already have rich customization facilities, incl. per-appender fn and options overrides.
Status While now undocumented, backwards compatibility will be retained since: 1. The back compatibility is cheap and simple 2. Appenders in the wild may already depend on the argument (incl. several community appenders) Motivation The problem with :msg_ is that its behaviour can't be easily customized, and customization can be useful (e.g. for #356). So instead of hard-coding a particular :msg_ generator as before, the responsibility of message generation will now be handled as just another aspect of output generation (i.e. handled by output-fns). Note that output fns already have rich customization facilities, incl. per-appender fn and options overrides.
Change (both Clj and Cljs): For print-style logging commands (`debug`, `info`, etc.): By default, `pr-str` (rather than `str`) is now called on all non-string arguments when generating `:msg_` and `:output_` vals in Timbre's log data map. I.e. will affect generated output. For format-style logging commands (`debugf`, `infof`, etc.): No change since format-style logging commands presume that a format pattern will explicitly specify the desired formatting, so arguments are not automatically formatted. I.e. should not affect generated output. Motivation: My hope is that this change should be positive or neutral for the vast majority of users. There are several known cases where `pr-str` produces better output (e.g. for JS objects in Cljs), and currently no known cases where `pr-str` produces worse output (though please ping me if you know of something!). To customise this behaviour (message generation), see the `default-output-fn` docstring.
Plain JS objects are printed rather uselessly by default in cljs. E.g.
which results in:
JS arrays are also a bit odd in that they lack delimiters. E.g.
which results in:
We've worked around this with the following middleware so far:
Which makes the above examples print this instead:
Maybe worth including something like this by default?
The text was updated successfully, but these errors were encountered: