Open cjohansen opened 6 years ago
Yes this is something that I have been mulling over.
Unfortunately as you have noticed the runtime error notifications are different from compile error notifications. What does it mean when a Compile warning and Spec warnings all come in at the same time? The current design of the HUD has a limited amount of information that it can present. So right now logging well formatted errors makes the most sense from a UI point of view, keep in mind that this could be part of binaryage/devtools
which does advanced logging in Google Chrome.
This is definitely something that I'm going to be taking on soon as I think its really important to make this smooth to demonstrate the power and flexibility of a spec based workflow in CLJS.
So, if I understand you correctly, you're suggesting I keep spec failures in the console for now, but eventually the figwheel HUD will be able to display them? If so, 👍 Let me know if I can help in any way.
Yep that sounds about right. I'll let you know ...
I'm using
cljs.spec.alpha/fspec
to add some constraints to functions in my code-base, among other places in React components, as an improvedPropTypes
(if you're familiar with those). Anyway, when these fail, they result in an exception that can be caught withjs/window.onerror
. I figured I'd set up a handler and display the errors. Then it hit me that Figwheel's HUD would be perfect for this, but I'm a little unsure how to best do this. So this is mostly a couple of questions:1) Is it a good idea to use the HUD for global uncaught exceptions? 2) If yes, what is the best way to proceed?
I'm able to display something using
(figwheel.client.heads-up/display-system-warning "header" "body")
, but there's a few problems:<pre>
as it's already nicely formatted (using expound)Any suggestions on how to approach this (or a stern warning not to go this route, should there be good reasons for that) would be appreciated!