Skip to content
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

Add a more useful default error reporter for cljs instrumentation #678

Conversation

dvingo
Copy link
Contributor

@dvingo dvingo commented Mar 30, 2022

Fipp, the pretty printer, is not designed with the browser console in
mind and the output when developing in cljs is not usable.
(Every print call invokes console.log which will result in a new output line per invocation,
instead of all on one line like in a terminal).
This commit allows navigating directly to the callsite where the error occurred via a JavaScript stacktrace.

This should address #675 and #666

I believe we would have to create another pretty printer namespace for ClojureScript that mirrors the malli.dev.pretty namespace but with the browser console in mind to get useful output.

Fipp, the pretty printer, is not designed with the browser console in
mind and the output when developing in cljs is not usable.
(Every print call invokes console.log which will result in a new output line per invocation,
instead of all on one line like in a terminal).
This commit allows navigating directly to the callsite where the error occurred
 via a JavaScript stacktrace.
@ikitommi
Copy link
Member

ikitommi commented Mar 31, 2022

Thanks! just now read the issues. I think we could wrap the fipp-printing easily.

just printing

https://github.com/metosin/malli/blob/master/src/malli/dev/pretty.cljc#L75

=> just wrap the results with with-out-str and print that using single js/console.log

throwing

https://github.com/metosin/malli/blob/master/src/malli/dev/pretty.cljc#L83

... it seems that the exception messages don't get pretty printed in console. Maybe just print the message there too (with cljs)

@dvingo
Copy link
Contributor Author

dvingo commented Apr 1, 2022

oh right, that's brilliant!

I am going to close this PR in favor of this one: #681

@dvingo dvingo closed this Apr 1, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants