Fork me on GitHub
#clojurescript
<
2019-09-18
>
sova-soars-the-sora00:09:11

ended up going with

(.log js/console "Lesson " (.getAttribute (. js/document (getElementById "imprt")) "data-lesson"))
(.log js/console "Section " (.getAttribute (. js/document (getElementById "imprt")) "data-section"))
(.log js/console "Lesson Type " (.getAttribute (. js/document (getElementById "imprt")) "data-lesson-type"))

sova-soars-the-sora00:09:42

<div data-lesson="1"></div>

Andreas S.07:09:04

Hello everyone

Andreas S.07:09:00

I wanted to interact with a git repository (gitlab) which API's would you suggest could work good for this?

andy.fingerhut07:09:58

I have never used any APIs for accessing git repos before, but I have heard of a Clojure library called tentacles that you could see if it does anything useful for you: https://github.com/clj-commons/tentacles Warning: according to its README it interacts with a Github API, so that library might be specific to Github, and if so, might not work with the gitlab web site.

Andreas S.07:09:18

Thanks andy! I will take a look.

dpsutton12:09:17

are goog.event/listeners garbage collected when the thing they are listening to is collected or must we take care to also clean these up? Its trivial to do i suppose but a bit ugly so i prefer not to if its all the same

dnolen13:09:00

I don't think that's really a question for goog.event/listen but whether you're attaching events to the DOM period

dnolen13:09:15

historically this could be a source of leaks yes

dnolen13:09:09

probably best to go see what people best practice nowadays

ordnungswidrig14:09:34

Isn’t best practice here not to attach listeners to individual dom nodes but to the “root” node and filter there? Something like delegated event handlers in jquery (See https://api.jquery.com/on/)

dpsutton14:09:10

i'll read through that in a bit. thanks for the docs

Roman Liutikov15:09:02

that was at times when event listeners where expensive in browsers IE6 I guess

dpsutton15:09:47

thanks for the context @roman01la

andy.fingerhut15:09:19

Is there no cljs.edn nor clojure.edn namespace available in cljs? I thought there was, because I was using it in a .cljc file without error before, but perhaps there was a warning and I missed it?

lilactown16:09:42

you can also install tools.reader which is slightly more featured

thheller16:09:58

cljs.reader uses tools.reader nowadays.

thheller16:09:06

there never was a cljs.edn though, always cljs.reader

andy.fingerhut16:09:07

Yeah, it is weird, because I have some cljs deftest-based test namespace that require's clojure.edn that I never noticed errors with before, but perhaps I wasn't looking closely enough. Thanks for the help.

paul a18:09:41

could someone help me understand what's going on with this code? what's really confusing is how the resp-json argument passed to the then callback is a javascript object, but the resp-json argument passed to catch is a promise; that seems wrong somehow

paul a18:09:53

(defn fetch-and-then [url]
  (-> (js/fetch url (clj->js {:headers {"Accept" "application/json"}}))
      (.then (fn [resp]
               (js/console.log "resp ok? " (.-ok resp))
               (js/console.log "resp" resp)
               (let [json (-> resp .json)]
                 (if (.-ok resp)
                   json
                   (throw json)))))
      (.then (fn [resp-json]
               (js/console.log "in then")
               (js/console.log resp-json)
               (js/console.log (-> resp-json .-description))))
      (.catch (fn [resp-json]
                (js/console.log "in catch")
                (js/console.log resp-json)
                (js/console.log (-> resp-json .-description))))))

(fetch-and-then "")
;; wait for output, and then
(fetch-and-then "")

oconn18:09:31

The fetch API returns a promise and then threads it through a js promise chain. If the response is not ok then it throws in the first then with is caught by catch

paul a18:09:42

hmm, i'm not sure what you mean. that doesn't answer my question as to why the second then receives an object in istead of of a promise...

dpsutton18:09:13

then returns a promise. this is in a threading macro ->

dpsutton18:09:23

and the callback to then takes whatever the previous promise delivers. the first then takes the response and calls .json on it. the second takes the json from that first then

paul a19:09:11

right. the first then returns (.json resp), which returns a JS object, so the second then receives that JS object.

dpsutton19:09:36

the callback to the then receives that

paul a19:09:45

likewise, i would expect the first then to throw (.json resp), a JS object, and that catch would receive that

dpsutton19:09:52

the then is chained on the return of the first then which is a promise

dpsutton19:09:16

(.then (fn [input] ouput)) the fn returns an object, but its nested inside of the then which returns a promise

alpox19:09:21

@UN0TDQ30T I believe your confusion may be because .json does not as you say give you a js object but a promise: https://developer.mozilla.org/en-US/docs/Web/API/Body/json

alpox19:09:28

If you throw it, you get the promise in the catch. If you return it from .then, the next .then is evaluated with the resolved value of the former promise from the returned .json call is resolved

paul a20:09:43

okay, this is starting to make sense now. thanks all for your patience and explanations!

Ian Fernandez20:09:12

Guys, I'm new on clojurescript

👍 4
Ian Fernandez20:09:35

How can I see what is in value of this map:

{:req #object[IncomingMessage [object Object]], :res #object[ServerResponse [object Object]]}

dnolen20:09:24

@d.ian.b probably easiest by developing with cljs-devtools and console logging that value

dnolen20:09:38

I believe cljs-devtools allows you to navigate cljs and js values

David Pham20:09:43

Anyone could explain me why Nashorn was useful for CLJS, and why it is not anymore? (Sorry for the newbee question)

andy.fingerhut20:09:14

@neo2551 Others can probably answer more authoritatively than I can, but I think the basic idea is that the Nashorn developers decided it wasn't worth pursuing. Probably they either consider it too far behind the state of the art of other JavaScript run time environments, and/or some combination of that and I believe I have heard that Graal will have its own JavaScript runtime, different than Nashorn, but more actively developed. Probably some developers consider that a better foundation for a modern JS implementation?