This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-09-15
Channels
- # announcements (51)
- # beginners (65)
- # calva (44)
- # cider (6)
- # clara (3)
- # clj-kondo (30)
- # cljsrn (5)
- # clojure (63)
- # clojure-australia (7)
- # clojure-dev (7)
- # clojure-europe (43)
- # clojure-gamedev (1)
- # clojure-nl (6)
- # clojure-uk (7)
- # clojurescript (51)
- # conjure (1)
- # cursive (9)
- # datascript (16)
- # datomic (14)
- # depstar (20)
- # events (1)
- # exercism (17)
- # figwheel-main (6)
- # fulcro (9)
- # graphql (3)
- # gratitude (2)
- # honeysql (4)
- # jobs (7)
- # leiningen (3)
- # lsp (107)
- # meander (7)
- # minecraft (3)
- # off-topic (16)
- # other-languages (4)
- # pathom (4)
- # pedestal (26)
- # practicalli (4)
- # re-frame (3)
- # reitit (7)
- # remote-jobs (1)
- # shadow-cljs (26)
- # tools-deps (67)
- # vim (19)
- # vscode (1)
Hi all, I'm running into an issue with figwheel hot reload time that I don't understand. I have a single function that when present in the file blows up the reload time to 24 seconds, and with it commented out reload time is 4 seconds. This function is a validator that steps through a block of data and checks to make sure that all user set options within the data are valid, and when it finds an invalid option it writes to a global state atom. It contains a bunch of doseq's to step through all of the data, including some nested doseq calls. If I swap out those doseq's for (dorun (for ...)) reload time is 8 seconds, and if I swap them out for (dorun (map ...)) it's back down to 4 seconds. Does anyone know why this is happening when using doseq? What's the "right" way to do iteration in clojurescript?
Hot reload time consists of three stages: • Compiling the code • Sending the code • Evaluating the code If you can figure out which of them takes the most time, it would be a good starting point. Also, there's #figwheel
Hopefully someone can point me in the right direction to fix this issue. When starting a piggieback cljs repl some of us get this error, some of us do not. The repl works in most other ways, we can eval, run js, etc. We all have the same classpath, etc.
clj.user=> (do (require 'cider.piggieback 'cljs.repl.browser) (cider.piggieback/cljs-repl (cljs.repl.browser/repl-env)))
cljs.user=> (require 'our.application)
Unexpected error compiling at (REPL:1).
Not supported: class cljs.repl.browser.BrowserEnv$fn__7854
Actually, not just piggieback - we get the same results with lein trampoline cljsbuild repl-listen
I just spend quite a lot of time to get CLJS browser repl setup working nicely with piggieback and encountered many errors, but this was not one of those. You see the browser opening, index page loading fine, REPL connection made and no errors in browser Console?
Hey, thanks for replying. We have narrowed it down (we think) to a version of timbre log library but we’re still not sure why some of us can require that ns and others cannot.
And yes all other functionality seems fine.
Hi Guys, I have the following clojurescript code https://gist.github.com/stuartstein777/24087befcaeb40f6f7b6768c51dfca20 IT works, but I was getting console error:
template.cljs:244 Warning: Reactive deref not supported in lazy seq, it should be wrapped in doall:
This was stopping it from working properly.
The doall
I had to add was this line in app
fn
(doall
(for [[key repo] (helpers/keyed-collection repos)]
(repo-summary key repo)))
Adding that fixed my problems, but it feels like a hack and I don't understand why I had to add it.
Is it because within the for
, I'm calling a function and that function derefs a reframe subscription? What is a better way to do this?> Is it because within the `for`, I'm calling a function and that function derefs a reframe subscription? Exactly. > What is a better way to do this? Avoiding laziness when it comes to derefing ratoms.
https://github.com/reagent-project/reagent/blob/master/doc/UsingSquareBracketsInsteadOfParens.md
Surprising, considering most open source libs I have to use have virtually no documentation at all
> Man, the reagent and re-frame docs are really, really, good Absolutely. :) I only wish Reagent also had good docstrings in the code.
How to send a promise from a go block? Clojurescript app
(defn foo []
(go 1))
Node app
var r=await foo(); //how to make it to wait and get 1
You can't. Just as in Node, where you can't use that await
out of the blue - you have to use it within an async
function.
The goal is to send to a node app, a value from a go, i found this way(someone from here helped before some days) (take! (go 1) (fn [r] (cb r))) but this works with callbals, i want to use await/promise, any help appreciated
You have to return a regular JS promise to Node, and then Node can await
that promise.
And you resolve that promise in the go
block.
That all assumes that you already have a go
block that you don't want to change. If you do not have such a block, just do everything using promises.
Read online about JS promise API, then use JS-CLJS interop to create a promise, that's it.
You do not "make the go block return a promise". You return a promise from a CLJS function. That very same function also has a go block that resolves that promise. Node then calls that function, awaits that promise, and gets the result when the resolve is done within the go block.
(defn call-me-from-node []
(js/Promise. (fn [resolve _]
(go (resolve 1)))))
I think that's how it would look like. I rarely construct promises, so might misremember things.You can create a promise in your clojure function, and resolve it within your go block. Something like this
(defn my-async-func []
(new js/Promise
(fn [resolve _]
(go
(let [result (<! (async-op))]
(resolve result))))))
i think it worked perfectly :)) i am just new to all those, creating npm libraries, async code etc
A quick unsolicited advice - if at all possible, don't tackle the concepts all at once. CLJS+NodeJS+promises+core.async is a hell of a combination to learn that way.
i know i will go one by one slow, read all (i was also new in shadow-cljs so i had this also)
i'll plug https://github.com/funcool/promesa if you just need to do normal async stuff
i'm personally not convinced core.async is useful on the frontend when most of what you would use go blocks for is for putting a single result onto a single channel per block - thats just promises with worse stacktraces
I think one of the big draws for it on the frontend was that you could be uniform with a backend also using core.async