This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-03-10
Channels
- # announcements (1)
- # babashka (44)
- # beginners (188)
- # calva (37)
- # chlorine-clover (28)
- # cider (12)
- # clj-kondo (40)
- # clojars (1)
- # clojure (323)
- # clojure-austin (7)
- # clojure-europe (20)
- # clojure-italy (4)
- # clojure-nl (16)
- # clojure-spec (7)
- # clojure-uk (37)
- # clojuredesign-podcast (1)
- # clojurescript (30)
- # cryogen (2)
- # cursive (30)
- # data-science (1)
- # datomic (26)
- # emacs (1)
- # events (1)
- # figwheel-main (13)
- # fulcro (89)
- # garden (1)
- # graalvm (20)
- # graphql (8)
- # jobs (1)
- # jobs-discuss (1)
- # joker (6)
- # kaocha (125)
- # lambdaisland (1)
- # meander (42)
- # off-topic (18)
- # pathom (3)
- # pedestal (6)
- # shadow-cljs (55)
- # spacemacs (21)
- # sql (18)
- # tools-deps (8)
- # uncomplicate (2)
- # vim (1)
- # yada (3)
månmån
Wes' stupid question of the day (might make this a thing...): Is there any sensible way to compile a snippet of clojurescript in a clojure file in a fairly lightweight way? Context is that I am creating a ring handler that loads the "graphiql" front end. Mostly this is done by script tags that pull resources off of a CDN but there is a little bit of embedded JS required to tell it how to fetch, what URL to hit, what headers to set etc and then to render the react component into a div.
Right now, I have all this as JS inside a string in a [:script ...] which works, but is fairly sucky. It would be fairly nice to convert it to cljs expressions and compile it on the fly (with some caching potentially).
My intuition is that cljs compilation is a little too heavy and sophisticated to do this kind of thing on the fly, but I thought I might get opinions before I pull this stuff out as JS to some kind of template file and just pull it in as JS.
This is a pertinent problem for me. We recently moved some interactive elements over to JS because as soon as you use CLJS you're obliged to take a relatively large amount of boilerplate required in order to execute it.
We haven't found an alternative tool that fits nicely into the environment. Would love to hear about other people's experiences in delivering 'lightweight' JS via CLJS or another LISP.
This is probably the lightest way: https://clojurescript.org/guides/quick-start
Thanks @U06HHF230. Yeah did look here as well as at some functions and internals like cljs.build.api but definitely got a feeling that I might have been messing around with things I probably shouldn't be. I might play with it at some point but I think for now, something like selmer templates to generate dynamic JS is probably where I will go.
yeah probably not worth doing anything too fancy for such small snippets
Why do I love Clojure? One of the reasons is I can pull down a library (carmine, for redis stuff), do a quick PoC on the repl, get immediate feedback, and know its going to work when I write Real(tm) code 🙂
At work, I run an "everything" REPL (with all our dev/test dependencies for our whole monorepo) and with the add-lib branch of t.d.a. and that way I can easily add new libs and try them out, without REPL restarts or any interruption to my edit/eval workflow.
Unfortunately, the latest version of add-lib can't be used directly from GitHub because it includes Java code and now there needs to be a "build" step. I d/l'd it and built it locally so I can depend on that for dev, for now.
Eventually, add-lib will likely be added to Clojure itself (in some form, yet TBD).
Anybody else slightly lament the underutilisation of :pre and :post conditions? I don't really use them, mostly because almost nobody else does, and I think nobody else really does mostly because they can be turned off. I can't help but feel that were this not the case, they would be much more widespread and would probably reduce confusing errors.
doesn't spec-ing or schema-ing fns provide a more structured alternative ?
@U0524B4UW In some senses it's worse because you have to explicitly enable fdef with instrumentation.
Ultimately, if you want validation that validates, and always validates, it needs to go in the function body.
I like preconditions, but I often find myself replacing them with more descriptive exceptions.
I think Spec's fdef, instrument, and check are "better" as an overall framework for dev/test than pre/post-conditions. If we have stuff we want to check/validate in production, we tend to write it in the code directly (although we also use assert in some places -- and we don't turn those off in production).
(I've railed against assert in the past because it could be turned off in production -- if I want to validate & "abort", I'm going to want that in production to avoid potentially corrupt data by letting stuff continue!)
we have some function schemas with ^:always-validate metadata in judicious places which works quite nicely
Interesting. I like assert because I can turn it off in production! Guard rails for development, speed in production. The exception in production should be rare, and will point directly at my code.
@U09LZR36F I'm more concerned about the situation where the assert would have triggered if it were enabled but without it the code just "does the wrong thing" (rather than blows up).