This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-04-30
Channels
- # announcements (7)
- # beginners (103)
- # boot (62)
- # cider (14)
- # clara (10)
- # cljdoc (4)
- # cljs-dev (2)
- # cljsrn (2)
- # clojure (51)
- # clojure-dev (15)
- # clojure-europe (13)
- # clojure-italy (25)
- # clojure-japan (3)
- # clojure-nl (4)
- # clojure-spec (6)
- # clojure-uk (9)
- # clojurescript (72)
- # clojureverse-ops (2)
- # community-development (2)
- # core-async (35)
- # cursive (16)
- # datascript (1)
- # datomic (12)
- # duct (2)
- # emacs (2)
- # fulcro (9)
- # graphql (5)
- # hoplon (5)
- # leiningen (3)
- # luminus (1)
- # nyc (1)
- # off-topic (41)
- # other-languages (1)
- # pathom (16)
- # pedestal (2)
- # re-frame (44)
- # reitit (1)
- # shadow-cljs (33)
- # spacemacs (12)
- # test-check (9)
- # tools-deps (15)
- # vim (4)
@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.
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
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 %)])])
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
@dentong93 if you need it, lmk if you want me to try updating that example repo
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.
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 %))])
@U0G2E3SEM ; does yours open the file dialog on click? Mine works for drop but the onClick doesn't seem to be working
This fixes the click issue!
[:> Input {:input-props (.getInputProps props)} ...
@U0G2E3SEM
(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
@m373h4n excess parens: (defn ^:export move [from to key] (
<-- that last one is not correct
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
yes, you could consider putting both in a map, as a single atom: (atom {:left foo :right bar})
Hm, this might be a good addition to js-interop. Just not sure what to call a recursive version of j/obj..
@U09LZR36F I’ve just added a proposed implementation of this to js-interop here: https://github.com/appliedsciencestudio/js-interop/pull/6
Because we were mob programming and nobody else felt comfortable writing the macro. And getting #js wrong was deemed a high risk.
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
@lilactown have you used your react hooks library with reitit-frontend ?
I did some benchmarks recently using the npm benchmark
lib for node which worked out ok https://www.npmjs.com/package/benchmark
If I'm defining a macro using js-obj
, do I need to require cljs or something in clojure?
yes and no. you can either require cljs.core :as x
and emit (x/js-obj ...)
or just directly (cljs.core/js-obj ...)
yeah there is no standard way to get the alias for that so I would recommend adding a utility fn to your .cljs ns
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?
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?
#js
is a reader literal just like any other reader literal. so it is compile time not runtime.
but it's implemented with clojurescript, in the read-js
function? using goog/object
?
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?
maybe it’s coming: https://github.com/tc39/proposal-class-fields#private-fields
@borkdude the warning about private var access is quite new so people didn't really "know" about private oftentimes and just used things
maybe not that important, just wondering if there’s thought behind the difference between CLJ and CLJS in this area
@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
The original ticket is this one FWIW https://dev.clojure.org/jira/browse/CLJS-1702