This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-02-01
Channels
- # beginners (117)
- # boot (8)
- # cider (22)
- # clara (3)
- # clojure (79)
- # clojure-italy (3)
- # clojure-spec (34)
- # clojure-uk (34)
- # clojurescript (74)
- # cursive (7)
- # datascript (5)
- # datomic (28)
- # defnpodcast (1)
- # dirac (9)
- # docker (25)
- # duct (1)
- # emacs (14)
- # fulcro (67)
- # graphql (1)
- # hoplon (15)
- # jobs (4)
- # juxt (6)
- # off-topic (76)
- # parinfer (3)
- # re-frame (25)
- # reagent (4)
- # rum (6)
- # shadow-cljs (1)
- # spacemacs (30)
- # sql (15)
- # unrepl (36)
- # yada (1)
Seems like the reader-tag idea explored here should make the hiccup renderer pluggable: http://tonsky.me/blog/hiccup/
I don't think you can ship a library with data_readers.clj
file, so this would need to be setup by users. I don't dislike the reader tag, it's a neat idea. You could easily hook up hicada/sablono to it.
Oh wait, I'm wrong. It looks like cljs compiler properly gets all the data_readers.cljc
files from the JVM resources...
the downside of reader tags here is – html/xml is probably the most verbose thing in clojure dev stack, and even with such short ns name like rum
– it will probably suck to read/write it.
I agree, especially if every single react element is tagged. I think the Quote: "Also: what if a new release of the compiler changes the formula and somewhere deep inside your app some rarely-seen dialogue will silently stop working? Seems like a time bomb waiting to explode." could probably be relatively simple detect/warned at build time, if a :span
, :div
(etc) keyword makes it into the build. I'm personally not too worried about this, but I can see how it could silently lead to runtime errors that remain undetected if you don't test components.