Fork me on GitHub
#clojurescript
<
2016-12-24
>
bbloom00:12:25

@bhauman is there some way to prevent figwheel from reloading when i change totally unrelated .clj files?

bhauman00:12:42

I'm in transit. But there are knobs and there is a change in snapshot as well

bhauman00:12:42

@bbloom: ^

bbloom00:12:04

@bhauman i tried :reload-non-macro-clj-files, but it was rejected as unknown key

bhauman00:12:13

:reload-clj-files

bhauman00:12:34

It's in the readme

bbloom00:12:04

i saw that, but that turns off all clj reloading, including macro files

bbloom00:12:54

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 😛

bhauman00:12:19

Snapshot fixes that. Where it only reloads macro files that are dependents

bbloom00:12:53

ok - i’ll just wait for that release then - no big deal. thanks

bbloom00:12:36

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]

bbloom00:12:04

it says The key :reload-clj-files at (:cljsbuild :builds 0 :figwheel) is on the wrong path.

bbloom00:12:07

but doesn’t tell me the right path

bbloom00:12:13

and the “probably” section is ambiguous

bhauman00:12:20

Yes that's what it's saying

bhauman00:12:40

It's a better than nothing situation

bhauman00:12:55

Of course it can be improved

bbloom00:12:02

the specific feedback: tell me the path in the second section

bhauman00:12:30

That's a great feedback

bhauman00:12:16

But the intention is that the example is from the root

bbloom00:12:14

gotcha - would also help: include the defproject form and a ...

pupeno11:12:58

Has anyone succeeded in using react-toolbox?

pesterhazy11:12:55

@pupeno looks like it's not packaged for cljsjs yet: https://github.com/cljsjs/packages/issues/847

pesterhazy11:12:53

but it's probably not hard to adapt another formula like this one: https://github.com/cljsjs/packages/blob/master/react-bootstrap/build.boot

pupeno11:12:59

Yes, I know… hence the difficulties in getting it to work.

pupeno11:12:59

Not sure. react-toolbox is distributed with sass that expect you to have webpack or some way of compiling them. Really annoying.

pupeno11:12:16

I don’t see any sass in that formula.

pesterhazy12:12:29

perhaps something similar could work with sass

pesterhazy12:12:53

out of curiousity, why do you choose react-toolbox as opposed to other react styling frameworks?

pupeno12:12:47

It seems to be the best out there, but I’m happy to be proven wrong.

pupeno12:12:09

Do you have a recommendation?

pesterhazy12:12:40

no I'm looking myself

mfikes18:12:28

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.

puzzler20:12:50

Is there something like cheshire for clojurescript?

puzzler20:12:21

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.

puzzler20:12:41

I want something like cheshire's encode with pretty-printing set to true.

puzzler20:12:15

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.

pesterhazy21:12:04

Wait... Cljs->js and stringify should work, if you're working with simple cljs values

pesterhazy21:12:44

Can you give an example of what doesn't work?

puzzler21:12:29

Let me try to come up with a compact example...

puzzler21:12:01

Hmmm, it works on simpler data.

puzzler21:12:39

I can't seem to create a simpler example, so I'll just show you what I'm seeing.

puzzler21:12:18

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?

puzzler21:12:43

I'm running no optimizations, so it doesn't have to do with name munging.

puzzler21:12:47

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.

puzzler21:12:53

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.

puzzler21:12:49

Oh, it's the uuid object that is the problem.

puzzler21:12:46

`=> (.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}"`

puzzler21:12:43

So, I can fix this by handling the uuid's specially.

puzzler21:12:55

But what about pretty-printing?

puzzler21:12:23

Ah, figured that out as well. stringify can take some extra inputs that allow for pretty printing.

puzzler21:12:50

Problem solved. But can clj->js still break in advanced optimization mode, or has that behavior been fixed in recent Clojurescript builds?

grounded_sage22:12:31

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

grounded_sage23:12:43

Just realised it would need to be a CLJC thing so we can take advantage of serverside rendering