This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # admin-announcements (29)
- # aws (2)
- # beginners (25)
- # boot (110)
- # business (15)
- # cider (39)
- # cljs-dev (3)
- # clojure (90)
- # clojure-czech (28)
- # clojure-hamburg (1)
- # clojure-japan (24)
- # clojure-poland (149)
- # clojure-russia (46)
- # clojure-sg (9)
- # clojure-uk (6)
- # clojure-ukraine (1)
- # clojurescript (105)
- # core-async (37)
- # cursive (9)
- # dato (7)
- # datomic (6)
- # emacs (10)
- # events (1)
- # hoplon (22)
- # jobs (4)
- # ldnclj (38)
- # leiningen (4)
- # off-topic (17)
- # om (173)
- # onyx (134)
- # re-frame (46)
- # reagent (35)
@bhauman: Should devcards work without Figwheel just by calling
start-devcard-ui! and defining some cards? I'm seeing the UI but no cards.
@juhoteperi: one peice of it is that you have to have :devcards true in the compiler options
also not sure how it would even work given JS has no reflective capability with respect to source locations at runtime
I was hoping they might do something like this https://gist.github.com/bgrins/5108712 to keep line numbers
it would only produces nightmares .. eg. jars compiled/created with different cljs version than you are using
Right, that's true. I'm mentally noodling on a way to AOT Clojure macros in a ClojureScript lib so the lib is consumable by self-hosted environments.
FWIW I even hate that that exists ... I really don't see the point to it excepts headaches
Yeah, the real underlying issue I'm noodling on is the fact that self-host is different than conventional ClojureScript with respect to macros, and what that means for lib consumption.
ClojureScript codes bases are already crossing into the 20-30K area, and I would not be surprised if there are things people haven’t talked about publicly that are bigger than that
there are points where caching is not possible (ie.
:emit-constants) but AOT isn't as well
If we did have AOT, and it extended to macros, producing things like
foo$macros.js, that could lead to a strange way for self-hosted environments to consume libs that would not otherwise be possible to consume owing to the use of Clojure macros that can't compile as ClojureScript. Not a well baked thought, but that was my reason for asking about it. :)
@mfikes: right there’s going to be stuff that doesn’t work, but that’s a barrier that’s not worth crossing anyway
most stuff like that is tooling stuff and I’ve already expressed by deep skepticism about recreating all the tooling we already have again in JS
@dnolen: @mfikes (sorry to jump in) I agree with the tooling on the JVM side, but I think bootstrapped cljs has promise when it comes to "cleaning up" js tooling (grunt, gulp) which I find unbearable.
my problem with the JVM is that I have an old machine which freezes if I have 2 JVMs running
how do om/reagent/other-cljs-react-wrapper users deal with the fact that passing callbacks breaks
shouldComponentUpdate since it never
(= prev-props next-props)?
but Om Next is not a render from the root model anymore so I think not a big deal for Om Next
well if you render A for whatever reason, that embeds B and passing a callback to it ... rendering A will now always cause B to render
@thheller: that said another thing is that Clojure(Script) already has a solution to this problem.
well ... if I pass
:onChange (fn [new-value] (js/console.log "got new value")) I consider this as didn't change 😉
ok ... enough with my worrying about stuff ... it probably doesn't matter if everybody just ignores this
@thheller: you can always define the function somewhere, and pass it in, that way the reference will always be the same. Unless I misunderstood
React seems to suggest passing
this.theCallback.bind(this) but I have nightmares about