Is it possible to use clojure.zip in cljs? Is it built in?

@mateusz-fiolka: yes, it's ported to in the clojure.zip namespace

Ok, thanks - maybe I'm just doing sth stupid.

see https://github.com/clojure/clojurescript/blob/master/src/main/cljs/clojure/zip.cljs

@dnolen: can we expect a blog post about om.next before EuroClojure or are you waiting to announce it there?

been lurking the repository and reading through the examples in dev.cljs and can't wait to try it out

dialelo: The problem I get is: https://gist.github.com/mateusz-fiolka/f6813cdd4fea91974595

strange, I fired up a REPL with the latest CLJS and I'm getting the same result as you with clojure.zipper

same for clojure.data

although clojure.set works fine

Maybe it's a bug?

looks like it, I'm browsing http://dev.clojure.org/jira/secure/IssueNavigator.jspa?reset=true&jqlQuery=project+%3D+CLJS+AND+resolution+%3D+Unresolved+AND+priority+%3D+Major+ORDER+BY+key+DESC&mode=hide to see if it's reported

I too I'm using figwheel, not sure if it's the culprit

lein cljsbuild once should allow to verify it.

@mateusz-fiolka: calling (enable-console-print!) before creating the zipper solves the issue for me

not sure why it affects the name resolution in a namespace

Doesn't work for me. I was using this function before.

I am using Clojurescript + Reagent + Figwheel and I keep periodically getting an error like this: Uncaught Error: No protocol method IDeref.-deref defined for type undefined I am just derefrencing an atom in another ns. Everything works after a clean build but then after a while it starts failing. Is there maybe a frequently made mistake that I am most probably making? Seems like the atom is dissapearing from the compiled code or something..

@not-much-io: are you setting that atom to nil (rather than the value of that atom)

A moment, I'll check to be sure, but I think not..

Hmm, it is possible: I am using the following code on a slider element to reset! the atoms value: (fn [e] (reset! settings/long-break-time (.-target.value e)))

If there is no .-target.value in the event then It would set it to nil.

I think that is fine - it would set the value the atom is wrapping to nil

aa, yes

I mean, if you have (def db (atom {:a (atom “hi”)})) you would need to deref :a as well as deref’ing the db. If you then did something like (reset! db {:a nil}) subsequent deref’ing of :a would throw the error you get

deref’ing (atom nil) is fine

@not-much-io: can you isolate into a trivially small example?

In settings.cljs: (defonce short-break-time (atom 5)) In components.cljs: (fn [e] (reset! settings/short-break-time (.-target.value e))) That is really it, all the other references to this atom are just de-refrencing it, only the one single slider resets it.

@colin.yates:

@not-much-io: gotta go put kids to bed - back in a bit, but that looks fine (you might want to return nil from the event handler though)

@colin.yates: It's really just a minor annoyance. I am not neccesarily itching to fix it. More like I was wondering if this is an obvious often made mistake.

@not-much-io try to avoid nil as much as possible, no matter the context

@sveri: 0 uses of nil in this small project

@not-much-io: stab in the dark, does it work the first time but then throw nil after figwheel updates? If so, again, another stab in the dark, try (def rather than (defonce. Trying to narrow scope of behaviour, that’s all

Can't even try, I don't know what happened but now I keep getting: Uncaught ReferenceError: goog is not defined -.-

@not-much-io Sorry, i misread this.

@not-much-io: have you lein clean’ed without restarting figwheel?

Yes, it fixes it, but after a while it's back

And now, the goog problem dissapeared by itself...

I do not have a stable setup..

@not-much-io: I think you have bigger problems . Get the setup stable first would be my advice

@colin.yates: I agree.

in Om, can I ‘watch’ a key on appstate, and e.g. make an API call when the appstate key changes?

I suppose I could poll in a go loop, but there’s probably a better way

I’ve never used Om (I like Reagent and Rum), but isn’t the state a simple atom?

oh, does add-watch work?

idk, that’s how I do with reagent/rum 😄

@arohner: alternatively, :tx-listen on om.core/root

@sander: I’m pretty far down in a component

I don’t know how to get a handle on the ‘real’ root from here

and that seems a little weird

@arohner: use will-receive-props or some react function like that?

ah, that looks like it could work

What are the goto templates for building a new cljs app? Chestnut still up there?