Fork me on GitHub

Why for a form-2 inner function, its parameter count can be arbitrary, but there is no arity exception?


(defn counting-button [txt] (let [state (reagent/atom 0)] (println “I am in counting”) (fn [a b c d e ,,,] ; params can be of arbitrary amount (println “In inner” a “” b “” c ““) [:button {:on-click (fn [e] (swap! state inc))} (str txt ” -- ” @state)])))


ClojureScript doesn’t enforce correct fn call arity in the same way that Clojure does


I think that the compiler will warn error if you call a fn with too many/too few arguments, but at runtime it’s not enforced, and works the same as in JavaScript


(defn f [a b c] (println a b c)). Call (f 1) I have Wrong number of args (1) passed to understanding-re-frame.components/f


((fn [a b c] (println a b c)) 2 3) is fine in cljs, but not in clj.


It's not a runtime warning, it's a compile-time one. Note how apply and (def f1 f) (f1 1) both won't produce any warnings.


The compiler explicitly checks forms like (f 1). If f is not a function with an arglist known at the compile time, there will be no warning.


Right, so the compiler errors when you statically call a fn like (f 1 2 3) , but e.g. (apply f [1]) doesn’t cause an error, because the compiler can’t necessarily determine what fn will be passed to apply


@UE72GJS7J For (defn f [a b c]), calling (apply f ’(1 2)) will incur Execution error (ArityException)


However, in cljs, the exception won’t happen.


As I said, that's because CLJS compiler does that check. The platform, which is JS, does not impose such a constraint on functions in runtime. CLJS does not check arities in runtime as well.


This particular inconsistency between CLJ and CLJS, along with many others, is caused by the differences in the underlying platforms.


How do people map components on page to where it is in code? For example you start in the web-app and want to know where a chunk of the UI came from. How do you find the code that created that chunk? My current approach is to find an unique looking piece of text and grepping but that's super lame.


The third alternative is to follow the code from top to bottom - the app's root, the seemingly relevant div, the next container, and so on until you get to that button or whatever you're interested in.


I combine what p-himik does with using a classname and drive from there, but this depends on the conventions you use. If all of that fails, I too will use the copy to track things down.


copy usually has more indirection though depending on if your using i18n and additional formatters. So, yeah, it really depends on the code base.