Fork me on GitHub
#clojurescript
<
2019-08-23
>
restenb10:08:14

consider this (incomplete, I know) javascript snippet:

restenb10:08:19

how do I get access to the javascript this inside that function when writing this from clojurescript?

thheller11:08:54

(fn [] (this-as anyting (.. anything -prop1 -prop2)))

thheller11:08:52

this-as binds the JS this to the specified symbol

unbalanced11:08:30

Me, upon reading this:

misha12:08:48

why are keyword qualifiers disallowed in #js {}?

$ planck 
ClojureScript 1.10.339
cljs.user=> #js {:foo/bar 1}
JavaScript literal keys must be strings or unqualified keywords.
https://github.com/clojure/clojurescript/blob/f289ffee2270567f7976d45012a0a52c38eb6488/src/main/clojure/cljs/tagged_literals.cljc#L63-L66

Stefan12:08:47

This is not an answer to your question, but who knows maybe this helps you: cljs-bean seems to support namespaced keywords… https://github.com/mfikes/cljs-bean/issues/67

misha12:08:34

Thanks, Stefan. I already use applied-science.js-interop so can use it's j/obj for this. so I am just curious whether there is a legit justification for this.

👍 4
dpsutton12:08:11

What would the canonical JavaScript representation of :ns/key be?

misha12:08:55

@U11BV7MTK there is none, I was asking from another point of view

dpsutton12:08:11

i don't follow. but what is your suggestion for what #js {:css/width 3} would be?

misha12:08:27

{"width" 3}

dpsutton12:08:39

and what about #js {:css/width 3 :panel/width 5}

misha12:08:33

{"width" 5}, or Map literal contains duplicate key but good point

dnolen12:08:02

@misha it's just not supported and it isn't going to be

dnolen12:08:05

you're not making maps

dnolen12:08:13

you're making JS literals

dnolen12:08:27

so little value in keyword stuff

dnolen12:08:09

#js {:foo 1} is identical to #js {"foo" 1}

dnolen12:08:12

there are no keywords

misha12:08:23

I was thinking about dev time "support", like using qualifiers to aid autocomplete, and narrow down keys set for a particular js obj I might build. So in source code it'd be e.g.`#js {:css/width 10}` and in js, ofc {"width": 10}

dnolen12:08:05

like I said there are no keywords, just strings

dnolen12:08:18

introducing namespacing brings along other expectations

misha12:08:14

well, allowing keywords there brought along my expectation :)

dnolen12:08:24

keywords aren't allowed

dnolen12:08:32

it's just a syntactical thing

misha12:08:49

cljs.user=> #js {:bar 1}
#js {:bar 1}

dnolen12:08:03

I already explained this above

dnolen12:08:05

no keywords

dnolen12:08:49

when this was originally done as a surface syntax it was only for the convenience of saving a character

misha12:08:50

well, yes, I understand, that in js obj it'll be string. but I type in keyword on keyboard.

dnolen12:08:08

i.e. #js {"bar" ...}

dnolen12:08:23

@misha but you're misunderstand what I'm saying

dnolen12:08:30

real keywords do a bunch of things

misha12:08:33

I'm very glad that convenience is there

dnolen12:08:45

and have a lot of semantics

dnolen12:08:05

bringing anymore stuff just into #js isn't desirable

dnolen12:08:26

and your confusion shows that saving a keystroke was probably questionable design idea from one perspective

dnolen12:08:55

anyways - no changes coming here - what's there is what's there

misha12:08:00

I would not say I am confused. It just seems to me that what I ask is the same as saving 1 char. I do not expect any qualified keyword semantics to get transferred to js obj. What I'm saying, is "there is a value in typing in qualified keyword because of IDE suggests assists" the same way there is a value in "saving a char" which is already there.

dnolen12:08:36

I understand quite clearly what you're saying, but I'm also explaining why it isn't a good idea

misha12:08:43

and I'm not asking for change. just wondering why that was explicitly prohibited.

dnolen12:08:51

I already explained that ^

misha12:08:57

you did, thank you

dnolen12:08:23

@misha one typical read time thing that people might expect if you allow this is namespace aliasing

dnolen12:08:32

#js {::foo/bar ...}

dnolen12:08:50

no interest in supporting stuff like this

dnolen12:08:51

that is what you're proposing opens more questions

misha12:08:38

yeah, that's a very good example. thank you

mfikes13:08:21

In the middle of Uncle Bob's latest blog post about Clojure, there's a cool bit about ClojureScript. http://blog.cleancoder.com/uncle-bob/2019/08/22/WhyClojure.html > ClojureScript and ran in the Browser at even higher frame-rates He's referring to http://spacewar.fikesfarm.com 🙂

tatatananana 4
👏 12
8
Stefan13:08:20

> I’m still trying to figure that out. So what’s your explanation @U04VDQDDY? 🙂

mfikes13:08:09

My theory is that the Quil graphics primitives run faster in the browser

mfikes13:08:35

I haven’t truly figured it out either

Stefan13:08:34

That’s ok. The point about “it’s not slow” is what matters.

mfikes13:08:33

Another interesting aspect is that the graphics primitives are more cleanly rendered in the browser

daslu13:08:49

Preparing to the meeting next week, with @jsa-aerial 's talk about interactive data visualization and literate programming with Hanami&Saite: https://twitter.com/scicloj/status/1164887113680281600

❤️ 4