This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2015-10-22
Channels
- # 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
Well, now it started working, though I don't think I changed anything š
and by dev time I mean that Google JavaScript devs probably donāt benefit from this so I would be surprised if this facility was there
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
Is āAOT ClojureScript libsā a thing? (Meaning the JavaScript, analysis cache, source maps, etc. included in the JAR for a given lib.)
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
Iāve said as much as Iām going to say about the matter, itās something to think about
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: in your case I could imagine :classifier āaot-cljsā
or something like that.
@dnolen: I don't even think AOT macros would work... If some Clojure macro invokes some crazy Java code at compile-time there's no way AOT could produce equivalent JavaScript for self-host use
@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