(defn f [x y])

(def some-map {:g f})

(def args [1 2])

; this line of code is in a library...
(apply (:g some-map) args)
; is it possible to it check args number before running?

Hi, I'm attempting to use recharts with reagent. In my home.html I have {% script "/js/Recharts.js" %} but when I try and call it I get exceptions back

Recharts.js:968 Uncaught TypeError: Cannot read property 'PropTypes' of undefinedmodule.exports @ Recharts.js:968__webpack_require__ @ Recharts.js:30testObject @ Recharts.js:99__webpack_require__ @ Recharts.js:30Object.defineProperty.value @ Recharts.js:80__webpack_require__ @ Recharts.js:30(anonymous function) @ Recharts.js:50(anonymous function) @ Recharts.js:53webpackUniversalModuleDefinition @ Recharts.js:9(anonymous function) @ Recharts.js:10
ui_recharts_wrapper.cljs:5 Uncaught TypeError: Cannot read property 'PieChart' of undefined(anonymous function) @ ui_recharts_wrapper.cljs:5

My source looks like (def PieChart (r/adapt-react-class js/window.Recharts.PieChart.))

Doesn't seem to matter to much where I try and import in my code (moving it around lines), but interestingly it -sometimes- works.

(well figwheel makes it work)

Which tends to suggest to me its being called before everything is ready. What am I missing here?

Fix it...

(defn make-pie-chart
  ""
  [{:keys [width height data]}]
  (let [PieChart (r/adapt-react-class js/window.Recharts.PieChart.)
        Pie (r/adapt-react-class js/window.Recharts.Pie.)
        ToolTip (r/adapt-react-class js/window.Recharts.Tooltip.)
        Cell (r/adapt-react-class js/window.Recharts.Cell.)]
    [PieChart {:width width
               :height height}
     [{:fill "#82ca9d"
       :data data
       :inner-radius 80}
      [Cell {:key 1 :fill red-color}]
      [Cell {:key 2 :fill green-color}]
      [Cell {:key 3 :fill blue-color}]]
     [ToolTip]])

  )

Need to be called like that. The defs where being evaluated on load... which wasn't what I wanted... I should have known better... ha well...

Not quite sure what to even search for on this. I just moved a data structure out of my code into a .edn file that I am loading at run-time using cljs-http library. At this point it starts failing the specs. What appears to be the issue is that my namespace qualified keywords, when loaded remotely, don’t get namespace qualified but stay as “::value"

cljs-http is handling conversion of the HTTP response body from EDN into clojure data structures

i’m actually a little suprised they don’t get qualified into, e.g., the cljs-http.client namespace

I don’t think ::double-colon-keywords are valid EDN

Ah

i mean now i think about it, it’s ambiguous

outside of the context of a namespace

if you want a qualified keyword, you should probably just write out the full namespace. :foo.bar/keyword

well i was qualifying because this appeared to be the "right thing to do"

within the context of my source

however in the context of a separate data file I think I will just switch back to unqualified and switch my specs

there’s a related issue in clojure that ::some-alias/foo is only valid when some-alias already refers to a namespace. meaning you cannot read clojure source code that contains those aliases unless the alias is set up in the current namespace.

“::" is not really qualifying anything. that’s just a shorthand for “keyword qualified with whatever the current namespace is” which makes little sense in a data file

Yes. As soon as you pointed it out I realised the meaninglessness of what I was doing.

I've got a *.cljc library that I include in my cljs project. The *.cljc library has a namespace form like:

@fenton: in clojurescript, you have to require cljs.spec.impl.gen

require that?

clojure.spec.impl.gen will also work, the point I’m trying to make is the impl part there

ok, put that in my cljc library?

require that instead of clojure.spec.gen

for the CLJS branch

(There already is a var named cljs.spec/gen that would otherwise collide, given the way namespaces and vars are implemented in the generated JavaScript.)

ah so i use this library for *.clj projects too, so I should resort to reader conditionals in this case.

@fenton Yes. (Perhaps you can even avoid directly using that namespace.)

@mfikes, ok...i'll look into that...thanks all! 🙂

@fenton: @anmonteiro: I’m trying to get clojure.spec.gen to alias cljs.spec.impl.gen for this reason

http://dev.clojure.org/jira/browse/CLJS-1696

David said: > I'd rather wait to see if people actually use this namespace frequently enough for this to be desirable.

so voice your opinion there if you want the alias

@shaunlebron turned out i only had it in my namespace to help with REPL testing...so i could safely delete it as mike suggested...what do you use it for?

I haven’t used spec at all

just advocating for consistency when including clojure namespaces

(i’m the owner of the api docs, and would like it to stay sane)

@shaunlebron I don’t know if I’m in favor of that alias

so I haven’t expressed my opinion because of that

I haven’t needed that namespace yet

ok. my mild opinion is that this is a bit less important than the namespace: [clojure.spec :as s], which aliases okay...

also, introducing a special case like that in the compiler opens a precendent for others that may come 🙂

its not helpful in my use case, which i think is a common use case, and I'd be curious to find out if anyone does use it, and why...thats why i asked... i guess we'll see if anyone has a specific need for it.

i mean, practically, it doesn’t really matter if people don’t use it that much

i haven’t worked in the compiler, so I’m not qualified to have an opinion on how it affects the compiler’s management

i’m only speaking from the API perspective

so, in regards to the API, it seems fine to make the compiler map clojure.* to the appropriate cljs.* namespaces, rather than offloading that responsibility to the user

I guess to make a decision on it @anmonteiro and @dnolen also take into consideration the impact on the compiler code and weigh that against the API perspective. Unless there is more of a case for the uniformity with respect for this namespace, I guess, its not a clear decision to make the compiler mod, and if people want this mod, then maybe more of a case than just uniformity needs to be made... I'm guessing here, thats just my read.

i wonder if moving away from the general method of replacing clojure. with cljs. to see if the namespace resolves is a good idea

wouldn’t explicitly mapping the clojure.* => cljs.* namespaces be better to prevent weird cases like clojure.spec.impl.gen from resolving?

that way, we could replace the general rule + special case, with a finite set of explicit cases

and we wouldn’t have to set a precedent for special cases

the con with that approach is that it could be more brittle in the sense if a new scenario comes up, may not need to touch the compiler as the general case takes care of it... but I dont have a current issue with the way it is for my selfish reasons, lol 😉

the problem is that the general case doesn’t work all the time, and it will continue breaking for other future impl namespaces. namespace additions in clojure are major version events, and can be added to an explicit namespace map as slowly as they come

@shaunlebron IMO your points are valid. Think the discussion has laid out the pertinent issues... now I guess a higher authority will decide! 🙂

yeah! and sorry for the bike-shedding 🚲 (I seem to have strong feelings about api)

@shaunlebron and I like trials biking! Good to have passions! lol 😉

(and now we’re both gushing about our bike hobbies in DM)

aliasing namespaces people aren’t using just isn’t a priority

no decision is going to be made until we get a lot more feedback

from users actively using clojure.spec

so it’s not a yes/no thing - let’s just wait and see

right on 👍

So if you make a utility you like in CLJS, how do you publish it?

@talexxx: are you using lein or boot?

https://github.com/clojars/clojars-web/wiki/pushing

Boot. I see there’s a section for that in that article, I’ll try it. Thanks

boot build-jar push-snapshot                                                   ~/g/hallo-color
Writing pom.xml and pom.properties...
Writing hallo-color-1.0.0.jar...
Installing hallo-color-1.0.0.jar...
CLOJARS_USER and CLOJARS_PASS were not set; please enter your Clojars credentials.
Username: talexxx
Password:
             clojure.lang.ExceptionInfo: java.lang.Exception: missing jar file or repo not found
    data: {:file
           "/var/folders/fq/_rst8fw93jl0dqjsc3vhqzrh0000gn/T/boot.user7039555530317153355.clj",
           :line 33}
java.util.concurrent.ExecutionException: java.lang.Exception: missing jar file or repo not found
                    java.lang.Exception: missing jar file or repo not found
     boot.task.built-in/fn/fn/fn/fn   built_in.clj:  768
  adzerk.bootlaces/eval802/fn/fn/fn  bootlaces.clj:   54
  adzerk.bootlaces/eval841/fn/fn/fn  bootlaces.clj:   62
     boot.task.built-in/fn/fn/fn/fn   built_in.clj:  716
     boot.task.built-in/fn/fn/fn/fn   built_in.clj:  618
     boot.task.built-in/fn/fn/fn/fn   built_in.clj:  342
                boot.core/run-tasks       core.clj:  794
                  boot.core/boot/fn       core.clj:  804
clojure.core/binding-conveyor-fn/fn       core.clj: 1916
                                …

@talexxx: looks like you found an issue => #C053K90BR. (I’ve never published with boot)

I’ll make a ticket in the boot repo.

does the leiningen checkouts feature work with clojurescript? if not how do I do multiple projects?

@jasonjckn I don’t see any reason it shouldn’t work

i put a syntax error into ./checkouts/mydep/src/...cljs. and it didn't notice it during lein cljsbuild

i'm now trying modifying my :source-paths to include ./checkouts/mydep/src

having more luck

@jasonjckn right lein isn’t going to look at :cljsbuild

so you need to dupe the source path stuff