Fork me on GitHub
#malli
<
2022-08-19
>
ikitommi14:08:35

Hi, is there an example cljs-project with shadow-cljs + malli.dev instrumentation enabled? Starting to port a large app from spec to malli, interested in good practices on how to do dev/prod separation, pretty printing errors in html (for react error boundaries on dev errors + enabling sci-powered code editing on the browser).

ikitommi14:08:10

Goals: • great DX • clear separation of dev & prod validation • tools for building dynamic schema systems • small bundle size

borkdude14:08:46

for SCI-powered code editing I would take a look at https://nextjournal.github.io/clojure-mode/

ikitommi13:08:55

that's great. Not a "dependency + one-liner to get an editor", but awesome in features etc.

ikitommi13:08:51

But, is there a simple (read-only) clojure code formatter for html? Malli error pretty printing is basically a sequence of text blocks and code blocks.

dvingo15:08:35

I started playing around with a setup but it's closed source at the moment. I'd like some more details on what is meant by bullet 2 - separation of dev and prod. and for bullet 3 what is dynamic schema? constructing schema at runtime? based on data? for point 4, the entry namespace in my project includes http://malli.dev which will increase bundle size. With shadow-cljs I think one way to solve this is with ns-aliases but I haven't confirmed this works. I fear you may have to use 2 different builds one for dev one for prod. I'm not sure about great DX - I haven't used the cljs instrumentation on a large project, I think https://github.com/CrypticButter/snoop may offer better DX but has tradeoffs of its own - using new syntax for defn mainly. The reason is that the intsrumentation macro produces large amounts of code (a set! call for every instrumented fn plus the code to filter every ns + fn in them) so on large codebases I can foresee this being prohibitive perf-wise. I've thought a little bit about a shadow-cljs server plugin/extension that would track which functions are instrumented and which are stale, which would have to happen per client (open browser window running the app). Then the macro would have access to this state to only output instrumentation code for stale functions. I'm not sure how feasible that is though, or how much time it would take, or how maintainable it would be.

dvingo15:08:07

@U21QNFC5C I think has been using the cljs instrumentation - any insights?

ingesol15:08:27

This is funny, was about to post a couple of questions about friction with tooling 🙂

ingesol15:08:47

Maybe a bit into the weeds, but there are 2 issues holding us back from a full rollout right now: • If you remove :malli/schema metadata from a function, it remains instrumented • We are relying on function identity, in a way that is not easily changed, and that is broken by the wrapping function added in -instrument. I think we have added the setup required, specifically: • In shadow init, call md/start! before mounting our reagent comp • In after-load, call md/start! This is supposed to be sufficient according to the docs, but nothing is unstrumented until we call md/stop!

ingesol16:08:55

Also, all those ..instrumented ns.here is not very nice when there are tens and hundreds of them. Should ideally be grouped or optional.

ingesol16:09:03

Another issue posted on CLJS instrumentation https://github.com/metosin/malli/issues/752