I am compiling some code using advanced compilation and some of my property access names seem to being munged (aget data "offer") works but `(.-offer data)` gets munged away what is the correct way to access properties? Why does the .- syntax exist if it is not going to work in these situations?

Put a type hint (.-offer ^js data)

thanks @roman01la! how do I know when to used that and when to not?

use it when it's unkown/runtime JS data

ok, got it thanks

also the compiler should print warnings

hmm, I didn’t get warning, I am using shadow-cljs, I wonder if that is it

I don't know how shadow works, ask in #shadow-cljs

yep thanks @roman01la, that was a big help :thumbsup:

I recently submitted https://clojure.atlassian.net/projects/CLJS/issues/CLJS-3248 , would be awesome if we could get some kind of feedback on that. It would go a long way towards providing people a good testing experience.

@plexus thanks though better to mentions tickets and patches in #cljs-dev

For data, you might want to just use the facilities in goog.object @sofra

I like the approach because it's just must simpler, the source mapping stuff not nearly as straightforward for the obvious reasons

@plexus I'm gonna put that patch through CI and Canary

thanks @mfikes. Got it @dnolen will put a message there in the future

Anyone got this error before: "clojure.lang.ExceptionInfo: Invalid :refer, var cljs.tools.reader.impl.errors/reader-error does not exist in file target/public/cljs-out/dev/cljs/tools/reader/impl/commons.cljs"

looks like a dependency conflict on tools.reader maybe?

is this the correct channel for :target :nodejs questions?

I'm experiencing some difficulty working with functions that reference this internally.

@goomba sure, what's your question?

I bet the FAQ on that one is using this-as

@noisesmith I think it's the inverse problem. I mean I'm calling a nodejs function that interally binds this. Let me construct a repro...

(ns some.example
  (:require [cljs.nodejs :as nodejs]
            [cljs.core.async :as a :refer-macros [go go-loop]]
            [cljs.core.async.interop :refer-macros [<p!]]
            cljs.pprint
            ["zlib" :as zlib]
            ["util" :as node-util]
            ["level" :as level]))

(def promisify node-util.promisify)
(def unzip (-> (.-unzip zlib) promisify))
(def db (level. "add-deps-db"))

(defn db-put! [k v]
  (let [put! (promisify db.put)] 
    (go
      (try
        (<p! (put! k v))
        (catch :default e
          (println "Problem: " e))))))

(comment
  (db-put! "name" "bob")
  ;;=> Problem:  #error {:message Promise error, :data {:error :promise-error}, :cause #object[TypeError TypeError: db._isOpening is not a function]}
  )

the interesting part is that db.__isOpening is, in fact, a function

(comment
  (db-put! "name" "bob")
  
  ;;=> Problem:  #error {:message Promise error, :data {:error :promise-error}, :cause #object[TypeError TypeError: db._isOpening is not a function]}

  db._isOpening ;;=> #object[Function]
  )

so I'm wondering if I'm doing something wrong on the invocation of db, perhaps?

sure

that's a classic js mistake

what if core.async is resolving its own put! instead of the local binding?

n/m it's probably not that

db.put doesn't have the reference to db

I believe this is the code in reference:

LevelUP.prototype.put = function (key, value, options, callback) {
  var self = this
  var promise

  callback = getCallback(options, callback)

  if (!callback) {
    callback = promisify()
    promise = callback.promise
  }

  if (maybeError(this, callback)) { return promise }

  options = getOptions(options)

  this.db.put(key, value, options, function (err) {
    if (err) {
      return callback(new WriteError(err))
    }
    self.emit('put', key, value)
    callback()
  })

  return promise
}

try (.bind (.-put db) db)

kk

same thing :thinking_face:

(for reference)

hehe

what about #(.put db %1 %2)?

I'll give it a shot!

it has to be (promisify (.bind (.-put db) db))

not just call it in a top level form

give this a read https://www.smashingmagazine.com/2014/01/understanding-javascript-function-prototype-bind/

like so?

(defn db-put! [k v]
  (let [put! (promisify (.bind (.-put db) db))] 
    (go
      (try
        (<p! (put! k v))
        (catch :default e
          (println "Problem: " e))))))

yep

niiiiiiiiiiiiiiiiiiiiice

that's it

wait

I'd also go easy on the core.async stuff if you're starting out with cljs/js

no

wait wait

no that was it

sorry repl output + excitement

I'm quite familiar with cljs but node is newish to me

I'd study the basics (promises, how does this work) first before getting out the heavy concurrency machinery (core.async)

ever since I learned about nexe though my mind has been reeling with the possibilities

I'd wager that's a fairly intermediate/advanced fix 😄

and yes I couldn't agree more, and thank you 🙂

any suggested reading, besides the above?

i think this is good for js https://exploringjs.com/impatient-js/index.html

well the marketing is certainly spot on 😄

so @pesterhazy after reading that article, I'm wondering why we wouldn't always bind this?

would be simple enough to make an invocation macro