Fork me on GitHub
#clojurescript
<
2019-10-18
>
dominicm09:10:38

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

Roman Liutikov09:10:16

because dash character is not a valid symbol in js names

thheller09:10:26

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

🙂 4
Roman Liutikov09:10:44

ha, even worse!

Roman Liutikov09:10:56

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?

thheller09:10:18

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

Roman Liutikov09:10:48

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

Roman Liutikov09:10:34

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

thheller09:10:59

no, mixing interop styles should be avoided

thheller09:10:19

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

Roman Liutikov09:10:14

could be nice type inference warning btw, cc @mfikes

victorb09:10:39

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?

Roman Liutikov09:10:07

:pseudo-names true in compiler options might help

victorb09:10:42

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

thheller09:10:01

whats the error?

thheller09:10:22

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

victorb09:10:29

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

victorb09:10:50

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

victorb09:10:51

thanks a lot!

victorb09:10:27

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

thheller09:10:45

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

thheller09:10:14

but :pseudo-names would make that problem go away

thheller09:10:25

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

victorb09:10:51

hmm, I see.

victorb09:10:29

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

victorb09:10:35

thanks for the pointers in any case

thheller09:10:36

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

thheller09:10:57

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

victorb09:10:47

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

victorb09:10:19

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

thheller09:10:00

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

thheller09:10:29

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

victorb09:10:38

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

thheller09:10:48

no they do not

thheller09:10:36

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.

victorb09:10:07

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

victorb09:10:45

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

thheller09:10:04

externs or externs inference type hints are also possible fixes

Lone Ranger12:10:01

anybody doing clojurescript game dev?

Lucas Barbosa14:10:54

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 ""))
repl.clj:
(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")
I start everything by typing rlwrap java -cp cljs.jar:src clojure.main repl.clj I don't understand the following behaviour:
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]]
It raises a warning of an undeclared var and then shows the value of the var. Am I doing something wrong? Also, the book says that the :watch flag is supposed to automatically evaluate new cljs code I type in src/cljs_first_project/core.cljs. When I add new stuff, I have to reload the browser in order to have the new code there. Is that expected?

deo queiroz carlos14:10:13

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"}

thheller14:10:50

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

mikerod16:10:54

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

mikerod16:10:17

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

mikerod16:10:47

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

mikerod16:10:03

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

lance.paine16:10:13

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?

re-frame 4
ghadi17:10:25

re-frame has been pretty good for us for a big SPA

👍 4
4
ghadi17:10:55

I don't know of many people using om.next

lance.paine17:10:29

Oh, I've just learnt of fulcro. The intro sounds promising.

lance.paine17:10:30

Oh, in fact, as I read through the fulcro docs I see "because that’s the way it was written in Om Next, the predecessor of Fulcro. I assume David Nolen had his reasons for preferring functions/macros over "

mikerod16:10:09

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

dpsutton16:10:19

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

mikerod17:10:30

yeah, things changed a bit since then

mikerod17:10:44

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

mikerod17:10:56

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

thheller17:10:06

time to bump CLJS as well 😉

mikerod17:10:09

yeah, I am

mikerod17:10:21

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

mikerod17:10:27

the dep order revealed the problem with the reader

mikerod17:10:42

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

mikerod17:10:50

when not on map entries

mikerod17:10:09

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

mikerod17:10:19

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

mikerod17:10:33

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

dpsutton17:10:41

extend to vector?

mikerod17:10:43

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

thheller17:10:44

yeah thats unfortunate

mikerod17:10:58

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

mikerod17:10:10

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

mikerod17:10:31

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

mikerod18:10:47

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

mikerod18:10:33

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}
vs
(->> {: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)