clojurescript 2022-04-12

flowthing08:04:16

Any thoughts on what might be going on here? I figure this is somehow related to the AOT-compiled data.json in the ClojureScript JAR, but I can't see how as both ClojureScript versions come with the same data.json version (0.2.6).

flowthing08:04:49

To clarify a bit: the -write method takes three args in data.json 2.4.0, but two in 0.2.6 (which is what ClojureScript comes with). I don't know why the 0.2.6 version gets picked up with CLJS .891 but not with .861.

p-himik08:04:22

Not sure what's going on, but if you need it fixed, you can try adding $slim to the end of the CLJS artifact name to get rid of AOT'ed thirdparty files within the CLJS jar.

flowthing08:04:46

Thanks! I didn't know about $slim. :thumbsup:

flowthing08:04:39

That does indeed fix the issue.

p-himik08:04:37

@U050B88UR @U064X3EF3 Seems like another case for, as you said, "hiding" those AOT dependencies inside the CLJS jar that doesn't have the $slim qualifier. What needs to be done to move this forward?

flowthing08:04:21

On another (but related) note, I was somewhat surprised to find that there's been a breaking change to data.json (in 2.2.0, I believe, when options to write functions were added).

Alex Miller (Clojure team)12:04:44

No change to public api, but we did change the extension protocol, probably should have thought about that more (does not affect most users)

flowthing13:04:21

I guess I'd also consider the extension protocol to be a part of the public API (seeing as it's also listed here: https://clojure.github.io/data.json/#clojure.data.json/-write). But yeah, probably not a whole lot of people use that protocol.

Alex Miller (Clojure team)13:04:11

yeah, I'm not disagreeing with you. honestly, we did not think about it enough

flowthing15:04:28

Yeah, no worries. The strangeness around the AOT-compiled deps in the CLJS JAR seems like a bigger issue to me.

Alex Miller (Clojure team)15:04:28

agreed, @U050B88UR is there some way to agenda-ize shading these deps in the compiled cljs build? data.json is particularly trivial as it is a single namespace - you could easily just copy the source in and s/clojure.data.json/cljsvendor.data.json/ or something

Alex Miller (Clojure team)16:04:12

I know tools.reader is harder, but maybe not much

erre lin17:04:22

Hello, I have a question about reagent's render function. Suppose I have a very simple component:

(defn simple-comp []
  [:div
    [:p "This is a short paragraph"]])

;; I understand I can use it like this:
(defn simple-section []
 [:section
  [simple-comp]])

(simple-section)

;; But I found if I pass an argument to that simple-comp, nothing seems wrong
 (defn simple-section []
  [:section
   [simple-comp "hello"]])

;; it seems the "hello" string will just be ignored

Even when a component (or render function?) is not supposed to receive any parameters, I can still pass arbitrary ones to it and in such cases they will be ignored. Am i right? I haven't found explanation on this.

🤯 1

p-himik17:04:00

The parameters will be ignored, but if such a parameter changes then the component will be re-rendered anyway - because internally, that value is a part of the props.

😌 1

erre lin17:04:08

Thank you. I didn't know that the change to such a parameter will also result in re-rendering of the component. Really helpful tips:clap:

isak17:04:53

The explanation is that the environment the ClojureScript code is compiled to (JavaScript) does not do any arity checking. ClojureScript could wrap every function definition or invocation to add that, but it would have a big runtime cost, so it doesn't. If you had done the same in Clojure, you'd get an error, because the JVM does check the arity.

👍 1

erre lin17:04:17

This explains very well. I was confused exactly because I can't do the same in Clojure; yes, I will get an error. I'll keep this 'arity checking' point in mind. Thank you.

2022-04-12

Channels