This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-12-24
Channels
- # adventofcode (13)
- # beginners (163)
- # boot (8)
- # cider (1)
- # clojure (86)
- # clojure-germany (1)
- # clojure-italy (2)
- # clojure-spec (66)
- # clojure-switzerland (1)
- # clojure-uk (25)
- # clojured (1)
- # clojurescript (58)
- # core-async (1)
- # cursive (4)
- # datomic (11)
- # events (1)
- # funcool (3)
- # hoplon (86)
- # off-topic (8)
- # om (11)
- # onyx (1)
- # protorepl (7)
- # re-frame (15)
- # ring-swagger (4)
@bhauman is there some way to prevent figwheel from reloading when i change totally unrelated .clj files?
i’ll use that for now - but i’m sure it will burn me later when i am wondering why the heck something isn’t reloading 😛
btw, the error "The key :reload-clj-files should probably be placed here” is super confusing - i guess it’s telling me that :reload-clj-files doesn’t go in [:cljsbuild :builds :figwheel] and instead belongs in [:figwheel]
it says The key :reload-clj-files at (:cljsbuild :builds 0 :figwheel) is on the wrong path.
Has anyone succeeded in using react-toolbox?
@pupeno looks like it's not packaged for cljsjs yet: https://github.com/cljsjs/packages/issues/847
but it's probably not hard to adapt another formula like this one: https://github.com/cljsjs/packages/blob/master/react-bootstrap/build.boot
Yes, I know… hence the difficulties in getting it to work.
Not sure. react-toolbox is distributed with sass that expect you to have webpack or some way of compiling them. Really annoying.
I don’t see any sass in that formula.
the formula uses less: https://github.com/cljsjs/packages/tree/master/react-bootstrap
perhaps something similar could work with sass
out of curiousity, why do you choose react-toolbox as opposed to other react styling frameworks?
It seems to be the best out there, but I’m happy to be proven wrong.
Do you have a recommendation?
no I'm looking myself
Here is an interesting puzzle: The JavaScript generated for
(loop [x (map str (range))]
(recur (rest x)))
uses CPU but constant memory on V8. But on JavaScriptCore and SpiderMonkey memory grows.I've tried cljs->js followed by JSON stringify, but it reveals hidden fields in the Clojure object (like _hash and a bunch of protocol masks) and lacks pretty printing.
It seems crazy to have to round-trip to the server just to convert edn into a json string. Would like to do it client-side.
Wait... Cljs->js and stringify should work, if you're working with simple cljs values
Can you give an example of what doesn't work?
It looks fine as clojure data, it looks fine as javascript data, but when I go to stringify it, see all the extra hidden fields that are present?
I know a while back David Nolen said that clj->js can't really be trusted, but I thought that was only in advanced optimization mode. And here, it looks fine prior to stringifying.
In any case, I'd ideally want this pretty printed anyway, so rather than debugging clj->js or stringify, I'm more interested in finding something robust like cheshire.
`=> (.stringify js/JSON (clj->js (random-uuid))) "{\"uuid\":\"c1dd9227-880f-4b0f-a6e5-98da39ba0d2c\",\"hash\":null,\"cljs$lang$protocol_mask$partition0$\":2153775104,\"cljs$lang$protocol_mask$partition1$\":2048}"`
Ah, figured that out as well. stringify can take some extra inputs that allow for pretty printing.
Problem solved. But can clj->js still break in advanced optimization mode, or has that behavior been fixed in recent Clojurescript builds?
I'm just going to leave this here because I would love to see it in CLJS but don't have the skills or time to make it. https://ryantsao.com/blog/virtual-css-with-styletron
Just realised it would need to be a CLJC thing so we can take advantage of serverside rendering