This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-04-29
Channels
- # announcements (1)
- # babashka (15)
- # beginners (37)
- # calva (94)
- # cider (3)
- # clj-kondo (17)
- # cljsrn (2)
- # clojure (45)
- # clojure-europe (39)
- # clojure-germany (1)
- # clojure-norway (2)
- # clojurescript (16)
- # component (18)
- # conjure (1)
- # cursive (13)
- # datalevin (3)
- # datomic (12)
- # docker (2)
- # duct (5)
- # eastwood (2)
- # emacs (4)
- # events (8)
- # fulcro (8)
- # inf-clojure (5)
- # kaocha (8)
- # lsp (24)
- # malli (11)
- # meander (3)
- # off-topic (19)
- # polylith (11)
- # remote-jobs (4)
- # sci (61)
- # shadow-cljs (9)
- # spacemacs (34)
- # sql (10)
- # tools-deps (27)
- # xtdb (10)
Need help:
(shadow) CLJS + Malli + console multiline printing weirdness - really cannot figure this out.
More details in thread ⬇️
But TLDR: `pretty/reporter` is doing something really crazy, it prints every single character/"word" (or fipp
document node, if I'm not mistaken) on new lines creating MASSIVE illegible walls of text in my console.
> I've also tried other reporters, including just straight console log/warn/error, but since pretty/reporter
is the closest to working and the one whose intended output I want, I'll focus on that one.
I’ve tried pretty/reporter, console.log/error/warn, pretty/thrower
and have even copied and modified tons of the function call chain of pretty/reporter
However:
1. With thrower and default -fail completely illegible schema failures are printed
a. It is extremely "horizontal/squished"
b. and more importantly even inspected in devtools repl, I cannot see the schema failure contents, just the data of the schema I wrote in the first place
i. (I've expanded all the folding bits in devtool's custom formatted content for the error)
2. I also tried replacing some logic within pprint-document
(more on that fn to follow) to console.warn instead, and got some progress somehow
a. This is the first screenshot
b. But as you can see, it looks like it's printing actual characters, instead of what I believe might be encodings for whitespace?
3. And with pretty/reporter
, it looks like something about the whitespace is messed up, and so is also nearly illegible
a. (second screenshot)
b. The content does print, but it looks like each word boundary whitespace is printed as a new line, and most of the time, it's several empty newlines per.
c. As I step through pprint-document, it looks like after the document goes through (serialize document) and the (eduction chain, the print call in (run! print) receives each individual word, instead of the lines that (I think) should have those words in them
(->> (serialize document)
(eduction
annotate-rights
(annotate-begins options)
(format-nodes options))
(run! print))
a. I thought it might have been the println line after the bit I just posted, but it just (as expected) added an extra newline after all the words from the schema error/document had been newline-printed
b. In the screenshot you'll see console.group being used from one my modifications, just for convenience against scrolling through massive number of lines in the console
I'm really confused and stuck by this, and can't seem to find any mention of this in the malli docs, api browser, GitHub issues and slack search about this, or if anyone else has faced this.
I've tried:
1. explicitly setting the print fn to be console.log/error/warn, even window.alert to see if there was some global pollution of my console var making it split several times per word
2. inspecting the contents of document as passed to format-nodes and pruning bits of the latter's cond conditions/code to only address :group, :text etc
3. opening a fresh new chrome profile with no extensions or anything
4. removing any and all scripts from our <head> like tracing/analytics tools
Maybe it's something about my work stack or setup or something. I'm new to clojure though, and so I've never created any clojure projects of my own, let alone shadowcljs web-apps. If it is required tho, I can try looking into making a repro project
Does anyone have any intuition or hunches, or steps to troubleshoot?@U055NJ5CC, I have [metosin.malli LATEST]
in lein
, do you mean a direct git dependency or something?
Oh crazy, I only just found the https://github.com/metosin/malli/issues/675.
Unfortunately at my work we use lein, which has no native git-based dependency support. I think I'd have an easier time justifying the introduction of malli itself versus lein plugin into our work codebase, or split our lein config into using tools.deps
for dependencies.
Is there any chance that the master repo as-is is worthy of a release to your team?
If not, I understand. But then I ask if there's any recommendation you can give to get as much of the latest master's fixes on this bug?
Thanks again.
Oh crazy, I only just found the https://github.com/metosin/malli/issues/675.
Unfortunately at my work we use lein, which has no native git-based dependency support. I think I'd have an easier time justifying the introduction of malli itself versus lein plugin into our work codebase, or split our lein config into using tools.deps
for dependencies.
Is there any chance that the master repo as-is is worthy of a release to your team?
If not, I understand. But then I ask if there's any recommendation you can give to get as much of the latest master's fixes on this bug?
Thanks again.
yep very recent fix: https://github.com/metosin/malli/commit/d1a28f734e6fa3e2f669d5cb08ecfcd0558991de
being stuck on lein is unfortunate, I led a project off of lein to deps across multiple repos last year and know that pain.
however, thanks to Tommi's excellent design of having the reporter be a function you provide, you can address this in your own codebase:
https://github.com/metosin/malli/blob/a3db330eae029863e9be443cda3a2cafd8f61a33/src/malli/dev/cljs.cljc#L32
just copy this ns:
https://github.com/metosin/malli/blob/master/src/malli/dev/pretty.cljc
and this one:
src/malli/dev/virhe.cljc
to include the relevant fix:
https://github.com/metosin/malli/commit/d1a28f734e6fa3e2f669d5cb08ecfcd0558991de#diff-78b0ed5a31a32de704a1f77385e434d91bc5a44a0f74d37bd313ea96a130d97cR27
it should be noted there were two even more recent fixes for cljs though. the implication is that things will work without those fixes only for :malli/schema
metadata style function schemas
but that should get you unblocked!
Thanks so so much for the help! I've been trying to figure this out for like a week, too embarrassed in case it was like an extension or external script or some user error that was causing it - I didn't even think to check if the latest master/docs were released or not.
Regarding your points:
1. I was trying to copy individual functions lol, can't believe I didn't think to just copy the relevant ns completely. Will do this post-haste.
2. Of those 2 recent fixes for cljs, it looks like
a. https://github.com/metosin/malli/commit/f7b4e12d3fe3e2f60ff50057118308b7a3abe148 is about collecting metadata fn schemas, doesn't that mean it's a fix only for metadata style fn schemas? So wouldn't things work without this fix if I didn't use metadata style? ( the inverse of what you said)
Lastly, since I'm here:
1. I'm actually using neither
=>
nor metadata style, as I'm trying to use malli
with helix
defnc
components.
a. I'm directly using a wrapper over (-instrument {:schema ... :reporter ...} some-fn-arg-from-wrapper)
i. Would that have some implications regarding any of the since-last-release cljs fixes?
b. Without too many specifics, but in case helps to know why,
i. defnc
does not forward metadata to the expanded fn, so that route doesn't work, would have otherwise used that
1. (yet again, there's an unpublished recent change that added metadata forwarding lol - oh lein)
ii. the output of the defnc
macro could sometimes be an Fn
, in which case =>
would work, but at other times it produces a js obj with a key render
that has the equivalent Fn
1. This is just a detail of React, wherein the latter case of the obj.render
is a special case handled automatically by React
iii. so my wrapper just instruments the output of defnc
with the provided schema for this special case, so it picks out the render
key's val if it's an obj, or the fn itself if it's an fn, and then passes either to -instrument
for 2. even though it's about collect it doesn't impact functionality - just developer experience (requires saving your code twice to see new fn schemas)