Fork me on GitHub
#clojurescript
<
2019-04-30
>
hoopes00:04:19

@dentong93 @thheller i have made progress! (by me, i mean you) - thanks, i’m not out of the woods yet, but progress is encouraging. this place is great.

dntn21:04:41

I think I was using an older version of react-dropzone in my project where I got it to work; I didn't fully delete my node_modules so i think it stuck around (major version 7) -- it looks like since version 8, Dropzone components require a rendering function, hence the error we are seeing. I am trying to make it work (I want to use react-dropzone instead of material-ui-dropzone) @U0G2E3SEM

dntn22:04:10

It's funky/not working all the way yet but maybe a step closer/in right direction. might be worth raising in #reagent

(defn my-drop [props]
  (reagent/create-class
   {:display-name "my-drop"
    :reagent-render
    (fn []
      [:div (js->clj (.getRootProps props)) "my-hello"
       [:input (js->clj (.getInputProps props))]])}))


(defn- root-el []
  [:> Dropzone {:on-drop #(js/alert "test000")}
   #(reagent/as-element [:> (my-drop %)])])

hoopes01:05:21

that's basically what i did to get it working with v10 - "react-dropzone": "^10.1.4", is in my package.json now - i didn't make the full class in my-drop - i was able to just return a function which returned a [:div] from there

hoopes01:05:58

@dentong93 if you need it, lmk if you want me to try updating that example repo

dntn15:05:40

May as well update that repo so that others who see it see a working (or closer to working) example for one but yeah I'd selfishly not mind seeing it if you got the behavior working -- like I said, mine was showing some weird behavior with the above snippet.

dntn15:05:43

What worked for me in an expected fashion as changed from the above according to hoopes' note about not bothering with full reagent-create-class, for posterity:

(defn- my-drop [props]
  (let [root-props (js->clj (.getRootProps props))
        input-props (js->clj (.getInputProps props))]
   [:div root-props
    [:input input-props]
    "my-hello"]))

(defn- root-el []
  [:> Dropzone {:on-drop #(js/alert "drop")}
   #(reagent/as-element (my-drop %))])

dntn17:05:19

@U0G2E3SEM ; does yours open the file dialog on click? Mine works for drop but the onClick doesn't seem to be working

hoopes19:05:14

haha...uh. no. not yet. love forgetting to try the simple things. to be continued...

dntn20:05:21

This fixes the click issue! [:> Input {:input-props (.getInputProps props)} ... @U0G2E3SEM

hoopes21:05:15

ah! son of a b.

metehan11:04:45

(defn ^:export move [from to key] (
(if (= from "products") 
  (if (= to "left")
    (swap! state/left assoc (keyword key) (get @state/cards (keyword key)))))))
when i call this function from browser console threedays.core.move("products", "left", "p0004") it gives invalid arity error
ncaught Error: Invalid arity: 0
    at Object.G__11968 [as call] (core.cljs:6971)
    at Object.threedays$core$move [as move] (core.cljs?rel=1556544505009:36)
    at <anonymous>:1:16

metehan11:04:32

it gives error but still works

arbscht11:04:43

@m373h4n excess parens: (defn ^:export move [from to key] ( <-- that last one is not correct

metehan11:04:46

ah thank you i didn't know this if blcok can be a function

metehan11:04:02

now it works properly 🙂

metehan11:04:41

i have another question i have state/left and state/right atoms and there will be more of them. instead of hardcoding variable names can i call them programmatically. lets say state/$myVar

arbscht11:04:20

yes, you could consider putting both in a map, as a single atom: (atom {:left foo :right bar})

metehan11:04:04

thanks i'll do as you suggest

dominicm15:04:47

Is there a recursive form of #js that's compile time?

dominicm15:04:44

Boo! 😊 Any alternatives?

dominicm15:04:37

Otherwise I may be forced to succumb to clj->js use. And that seems suboptimal.

dominicm15:04:14

Okay, so there's no technical reason to not have a recursive form of js-obj?

mhuebert22:04:50

Hm, this might be a good addition to js-interop. Just not sure what to call a recursive version of j/obj..

mhuebert22:04:35

I guess it's not only about objects, also arrays. Maybe j/lit

mhuebert13:05:06

@U09LZR36F I’ve just added a proposed implementation of this to js-interop here: https://github.com/appliedsciencestudio/js-interop/pull/6

❤️ 1
lilactown15:04:52

nope. I think it's just not a common use case

lilactown15:04:04

but when you need it... you need it lol. writing #js over and over is annoying

lilactown15:04:19

curious why you would resort to clj->js though

dominicm15:04:31

Because we were mob programming and nobody else felt comfortable writing the macro. And getting #js wrong was deemed a high risk.

dkrieger15:04:07

questions for the org-mode users: what sorcery is needed to jack in my babel buffers? I can do it with regular clojure babel buffers with no problem, but with clojurescript I get "error in process filter: ClojureScript is not available. See https://docs.cider.mx/en/latest/clojurescript for details" regardless of which repl I choose. fwiw I use figwheel-main for my cljs projects and have CIDER working properly in the context of a project

heefoo18:04:26

@lilactown have you used your react hooks library with reitit-frontend ?

heefoo18:04:25

trying to find how to properly do it

dominicm19:04:40

How do I best benchmark clojurescript? Additionally, how fast is map? vs protocols?

thheller19:04:01

I did some benchmarks recently using the npm benchmark lib for node which worked out ok https://www.npmjs.com/package/benchmark

lilactown19:04:43

@heefoo I have not

👍 8
dominicm19:04:46

If I'm defining a macro using js-obj, do I need to require cljs or something in clojure?

thheller19:04:44

yes and no. you can either require cljs.core :as x and emit (x/js-obj ...) or just directly (cljs.core/js-obj ...)

dominicm19:04:27

and I guess doing a foreign-lib is going to be very close to impossible?

dominicm19:04:03

e.g.

(:require ["react-dom" :as react-dom])
and using it in a macro

thheller19:04:37

yeah there is no standard way to get the alias for that so I would recommend adding a utility fn to your .cljs ns

dominicm19:04:52

ah, I see, clever.

john19:04:59

On the subject of performance testing... I was recently trying to imagine how one might go about building a "process manager" in the sense of an operating system's process manager, which gives you statistics on processes/threads and for example how saturated they are, but for JS Web Workers. JS doesn't expose any of those as telemetry, from inside the runtime, available to read from JS code, AFAIAA. So, does anyone have ideas on how to go about measuring things like saturation in a lightweight way? Perhaps have a polling mechanism that marks delayed pings as increased saturation?

dominicm19:04:34

Hmm, I thought that #js was compile time, but looking at the source it seems to be doing some array pushing, does that mean it's just as fast as runtime interpretation? or does google closure optimize this at compile time because of the structure of it?

thheller19:04:23

#js is a reader literal just like any other reader literal. so it is compile time not runtime.

dominicm19:04:15

but it's implemented with clojurescript, in the read-js function? using goog/object?

thheller19:04:35

hmm where is it using goog.object?

thheller19:04:50

don't forget about self-hosted stuff so there might be multiple impls 😉

dominicm19:04:07

ah, I'm looking at reader.cljs, but maybe it's for self hosted!

dominicm19:04:27

that's helped me find it

thheller19:04:32

no thats the runtime reader. not used during compilation.

borkdude19:04:39

why does the CLJ compiler throw on calling private vars, but CLJS only emits a warning? should a linter also take the difference in error level into consideration?

dominicm19:04:33

I think it's because in js there's no concept of a private var.

dpsutton19:04:11

sounds weird that privacy would be a host language concept

borkdude20:04:48

quite some libraries depend on private cljs.core functions

thheller20:04:54

@borkdude the warning about private var access is quite new so people didn't really "know" about private oftentimes and just used things

thheller20:04:06

that being said some things are private that probably don't have to be too

borkdude20:04:19

when you use a private var from cljs.core you currently don’t get a warning at all

borkdude20:04:09

maybe not that important, just wondering if there’s thought behind the difference between CLJ and CLJS in this area

mfikes20:04:20

@borkdude It was definitely not my intent that the feature behave this way. It was an oversight. https://dev.clojure.org/jira/browse/CLJS-3069 is a valid ticket IMHO

mfikes20:04:18

Oh, wait, sorry misunderstood. Yeah, we just emit a warning intentionally

borkdude20:04:32

oh I believe that, yeah, my question was more about error vs warning 🙂

borkdude20:04:00

cool, yeah, it seems like a good choice if it was introduced at a later stage