Why does (.-foo-bar a) compile to a.foo_bar and not a.foo-bar?

because dash character is not a valid symbol in js names

because that would be a.foo - bar in JS, so actual math

ha, even worse!

related question: in #js {:key val} key is generated as a string, does that mean that accessing such object should be done via gobj/get?

yes, data should always be accessed the gobj/get (or alternatives)

it’s especially tempting to use (.-prop-key o) when seeing #js {:prop-key v} in code

so maybe Clojure style names in literal js objects should be avoided, to not confuse yourself

no, mixing interop styles should be avoided

you must stay consistent or the gcc will get you into trouble

could be nice type inference warning btw, cc @mfikes

I have a issue where a bug is only present when doing the advanced compilation. I'm using no external JS libraries, so not related to externs, but somewhere, something is working differently. I'm trying to track it down, but having to do a normal build then a advanced build slows down the workflow a bit, and only way I could confirm potential fixes. Anyone have any debugging tips for tracking down the issue?

:pseudo-names true in compiler options might help

yeah, did that, but the error that happens is because of a data inconsistency issue that happens before, so seeing the actual names in the error didn't help too much

whats the error?

js->clj has some potential to break in :advanced code

Error: Vector's key for assoc must be a number but again, the error is a symptom because of another issue

oooh, that's very useful @thheller, I'm pretty sure I knoiw the issue if that's the case

thanks a lot!

@thheller you happen to sit on some resource that explain more about the potential issues?

hmm there is an open issue in the jira. can't find it though

but :pseudo-names would make that problem go away

so if it is still happening then it is not js->clj

hmm, I see.

the data inconsistency still could be related to js->clj as the data that ends up being unexpected is being passed through js->clj at one point

thanks for the pointers in any case

but the error sounds like (assoc some-vec nil "foo") or so is used

so maybe something is nil (or anything not a number) cause of some renamed property

yeah, no, the problem is the value I'm expecting to be a keyword in the assoc call is nil indeed. The problem happens before that though

yeah, trying to read and understand more about where exactly the properties would be renamed to a different format than I expect

(.-foo x) will be renamed, unless there are externs for foo

nothing else is renamed basically, so js->cljs gobj/set are all safe from renaming

I see. Thanks! Any ideas if macros get special attention somehow when doing advanced builds?

no they do not

js->clj can become problematic because of a potential conflict with the "fast-path" protocol dispatch. that is a property with a rather long name usually, but can be renamed to something short like x. so if you happen to have JS data with { x: 4 } or so running through js->clj that may break the detection and do unexpected stuff, often ending in completely insane errors running code that usually isn't even involved.

huh, that's very good to know. I'm pretty sure your note about (.-foo x) being renamed helped me finally found the cause of the error

Yes! That was the issue indeed. I was doing (-> p# .-props .-argv second) and changed it to (second (goog.object/getValueByKeys p# "props" "argv")) instead and issue fixed! Thanks a lot for the help @thheller

externs or externs inference type hints are also possible fixes

anybody doing clojurescript game dev?

Hey folks, I'm trying to understand how the browser repl works in cljs. I have a cljs source file and a "build" file that compiles the source and watches for changes (following the Learning ClojureScript book). Here are my files: src/cljs-first-project/core.cljs:

(ns cljs-first-project.core
  (:require [clojure.browser.repl :as repl]))

(defonce conn
  (repl/connect ""))

(require 'cljs.repl)
(require 'cljs.build.api)
(require 'cljs.repl.browser)

;; build the project and write it to out/main.js
(cljs.build.api/build
 "src"
 {:main      'cljs-first-project.core
  :output-to "out/main.js"
  :verbose   true})

;; start a repl, watch for changes
(cljs.repl/repl (cljs.repl.browser/repl-env)
                :watch "src"
                :output-dir "out")

ClojureScript 1.10.520
cljs.user=> (in-ns 'cljs-first-project.core)
nil
cljs-first-project.core=> conn
WARNING: Use of undeclared Var cljs-first-project.core/conn at line 1 <cljs repl>
#object[Object [object Object]]

Quick question about Reagent: When styling width like {:width 150} or {:width "150px"} it works fine, but using !important fails {:width "150px!important"} or {:width "150px! important"}

How should I do?

!important would have no effect in inline styles, they already override everything else

Does anyone have any info on seeing something like this as a CLJS compilation error

The interesting part is, this using clojurescript 1.9.946. and based on the error, looks like it is trying to compile it’s own ns core.cljs

I know there were reader tag changes around infinity etc, or whatever.

but I never knew of a situation where the cljs compiler would be able to read it’s own cljs (same version)

Hi all, I've been out of actively trying clojure for a while, but have some time on my hands. What's the current state of play for the various webui frameworks? If you were starting a new project tomorrow, which would you use? Did om-next arrive? Is it still reagent, reframe, something else?

nevermind, I think it’s just not getting a new enough clojure.tools.reader somehow

that looks like there's an #Inf rather than ##Inf?

yeah, things changed a bit since then

I moved my deps order aroudn slightly & and another dep “won” on the transitive dep resolution

so I ended up with cljs 1.9.946, but not the tools.reader it needed

time to bump CLJS as well 😉

yeah, I am

it’s an older project and was curious why it seemed I needed to to get it to continue to build

the dep order revealed the problem with the reader

the only sad part going from 1.9.946 to 1.10.x is that val and key calls break

when not on map entries

I can’t actually pinpoint exactly the changelog lnie that happens, but I do remember discussion around it whewn it first happened

it was one of those “you were never supposed to call key/val on non map entry anyways”

but some of these older app’s I oversee did 😞

extend to vector?

so have to search all over and change to first & second

yeah thats unfortunate

to be safe, unless you know you’re seq’ing over a map

> extend to vector? maybe, but sounds like it could have scary other implications hah

I was able to bring it up to modern cljs versions though - just had to find/replace these and be careful…

for fun, those changes came with https://clojure.atlassian.net/browse/CLJS-2478 if anyone is ever stumbling over this and wonders when vectors stopped being able to have key and val on them

which can be seen in cases like:

(->> {:a 1}
     (map (fn [e] (prn (type e)) [(key e) (val e)]))
     (into {}))
cljs.core/MapEntry
{:a 1}

(->> {:a 1}
     (map (fn [[k v]] [k v]))
     (map (fn [e] (prn (type e)) [(key e) (val e)]))
     (into {}))
;; cljs.core/PersistentVector

;; #object[Error Error: No protocol method IMapEntry.-key defined for type cljs.core/PersistentVector: [:a 1]]
;;   cljs.core/missing-protocol (jar:file:/.../clojurescript-1.10.520.jar!/cljs/core.cljs:316:4)
;;    cljs.core/-key (jar:file:/.../clojurescript-1.10.520.jar!/cljs/core.cljs:644:1)
;;   cljs$core$key (jar:file:/.../clojurescript-1.10.520.jar!/cljs/core.cljs:9010:4)