This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-03-18
Channels
- # announcements (4)
- # babashka (2)
- # beginners (72)
- # calva (2)
- # cider (18)
- # clj-kondo (30)
- # cljs-dev (2)
- # clojure (106)
- # clojure-austin (2)
- # clojure-europe (17)
- # clojure-italy (6)
- # clojure-nl (4)
- # clojure-uk (109)
- # clojurescript (31)
- # cursive (6)
- # data-science (2)
- # datomic (30)
- # events (1)
- # fulcro (20)
- # graphql (4)
- # jobs (2)
- # joker (8)
- # kaocha (2)
- # meander (31)
- # off-topic (1)
- # pathom (53)
- # re-frame (22)
- # reitit (1)
- # shadow-cljs (26)
- # specter (2)
- # sql (20)
- # testing (2)
- # tools-deps (2)
- # tree-sitter (1)
- # xtdb (20)
- # yada (6)
on the topic of small compile sizes - i've done some experimentation before and found that not using datastructures was a good way to keep the size small (like what @dnolen said). i wonder if there is any way to ask cljs to default to native JS datastructures such that when i ask for {}
i get an object instead of a clojure hash-map
?
i know ther eis the #js
reader macro which is super handy but can get a bit long winded and easy to forget
so i'm thinking a sort of "close to js" mode where you can write clojurescript more like e.g. Wisp
it’s difficult because if you’re doing immutable updates to an object, at some point it becomes more performant to use actual mutable data structures
but a lot of objects live for a short time and then are discarded, in which case using a JS object would be far more performant - for code size and runtime
you also run into really difficult issues with equality if you do this, I’m not sure it can be done
a thing i got working is writing clojurescript in a way that i know will compile with Wisp and then doing that at the final stage. problem is you have to use a ton of js shims for things like assoc. it's very messy but you can get very tiny artifact sizes.
i should finish the half-written blog post I have about this
it's only really useful if your code is very simple and what you are trying to do is very simple (like update a few divs on a page or attach a couple of event handlers)
Not able to refer to js/Buffer
. Getting Uncaught ReferenceError: Buffer is not defined. Any ideas?
(.from js/Buffer "0xf87ea00000000000000000000000000000000000000000000000000000000000000000f85494ca6e9704586eb1fb38194308e2192e43b1e1979c94ce2276efc33fee3c321e634eac28a9476e53b71c94f466a7174230056004d11178d2647c12740fa58b94b83820d6cf4b7e5aa67a2b57969caa5cdf6dff49808400000000c0")
But there's this: https://github.com/feross/buffer
Thanks for the info. Really helpful. For now, I found I can simply pass a string to the other library instead of constructing a buffer myself.
what is the difference between
#js{:a :b}
and
(clj->js {:a :b})
?my use case is that
(clj->js {:root {:flexGrow 1
:title {:flexGrow 1}
:background theme.background}})
works as expected, whereas
#js {:root {:flexGrow 1
:title {:flexGrow 1}
:background theme.background}}
does notah right
thanks
clj->js
is runtime transformation, tagged literal emits JS object directly
so if I go down the clj->js
route I should probably memoize the result
this a MaterialUI themed style so it won't change during the session
yeah, there are also more subtle issues with clj->js
, but I don't know all of them
I got cljs.js/eval-str
working! 🙂 This seems like strange behavior though, is this a bug? It seems like string results need to have pr-str
called on them
(defn eval-str1 [s]
(cljs/eval-str compile-state-ref s (gensym)
{:eval cljs/js-eval}
#(println "eval result:" %)))
(eval-str1 "(str \"asdf\")")
;;eval result: {:ns cljs.user, :value nil}
;;string results need to be pr-str'd?
(eval-str "(pr-str \"asdf\")")
;;eval result: {:ns cljs.user, :value "asdf"}
(eval-str "(conj [1 2 3] 4)") ;;works
;;eval result: {:ns cljs.user, :value [1 2 3 4]}
What are some practical differences when working with reagent vs rum?
reagent only wrap react. You manage all state yourself (and reagent will rerender) rum will tell you a "discipline" about how to manage state. @brandon149