Fork me on GitHub
#clojurescript
<
2017-12-20
>
briantrice00:12:09

I’m inclined to call the “aset js/window etc” version or just insert the same JS into the html scripts earlier but was hoping I could invoke (.polyfill js/something).

briantrice00:12:54

apparently there is js* which takes a string to “eval”. okay

noisesmith00:12:19

one thing to note there is that it’s explicitly documented that aset is designed for arrays and only accidentally works for fields on objects - goog.object is the proper way to do arbitrary object operations on objects

briantrice00:12:43

thanks; good point!

briantrice00:12:40

I found out that the (require [cljsjs.smoothscroll-polyfill]) clause was sufficient to activate the plugin because of how require interacts with those modules.

rnandan27305:12:11

any pointers on experience using https://github.com/aws/aws-amplify in clojurescript projects?

Empperi13:12:00

hi, I have a problem with javascript interop, given following piece of ClojureScript code ((aget (Object.) "lol")) I get this JavaScript: ((new cljs.user.Object())[“lol”]).call(null);

Empperi13:12:29

this is fine in many cases but not when function context matters, ClojureScript passes null as context which essentially now breaks my code

Empperi13:12:09

the reason why I need to do it like this is because the library I’m using does not have a full set of externs definitions in place and thus :advanced compilation munges the function name reference

Empperi13:12:45

so I would appreciate some ideas on how to bypass this problem

mfikes13:12:57

Is this what this-as is for?

Empperi13:12:19

seems very promising!

mfikes13:12:34

Hrm. Experimenting with (let [x (goog.object/get o "lol")] (this-as x (x)))

Empperi13:12:28

still generates the .call(null)

mfikes13:12:37

Right... I think that's the wrong path

Empperi13:12:39

which effectively forces the context to be null

mfikes13:12:56

What JavaScript would you like generated?

Empperi13:12:05

in short, I’m using CodeMirror

Empperi13:12:15

need to call cm.getCursor() in my code

mfikes13:12:19

((new cljs.user.Object())["lol"])()?

Empperi13:12:33

using (.getCursor cm) gets munged

Empperi13:12:52

so, tried all kinds of things

mfikes13:12:31

Yeah... I see the problem you are faced with.

Empperi13:12:47

I’m kinda running out of ideas

Empperi13:12:44

using CodeMirror from cljsjs so it has externs definitions in place, just not comprehensive enough (or is it even possible to define externs for .getCursor since it is actually dynamically applied within CodeMirror?)

Empperi13:12:36

or to be more exact: .getCursor is there in the code but my calls to it get munged and since the function call goes through prototype chain I’m betting closure doesn’t see .getCursor and you can’t really define externs properly for it

mfikes13:12:13

@niklas.collin goog.bind seems promising for this

Empperi13:12:18

need to check

Empperi13:12:47

compiling… Let’s see how it goes

Empperi13:12:04

yes! Worked!

Empperi13:12:15

cheers @mfikes, saved my day 🙂

Empperi13:12:28

really did not like the almost 2 meg footprints of :simple compilation 😛

mfikes13:12:45

So you end up with something like ((let [o [1 2 3]] (goog.bind (goog.object/get o "indexOf") o 2)))

Empperi13:12:12

(defn binded-call [obj fn-name & args]
  (apply (goog.bind (aget obj fn-name) obj) args))

...
(binded-call cm "getCursor")

mfikes13:12:55

Cool. I'd recommend using goog.object/get over aget. The former is for objects, the later for primitive arrays.

mfikes14:12:14

If you enabled checked-arrays, you would get something like this for the aget call:

cljs.user=> (defn binded-call [obj fn-name & args]
       #_=>   (apply (goog.bind (aget obj fn-name) obj) args))
#'cljs.user/binded-call
cljs.user=> (binded-call [1 2 3] "indexOf" 2)
Assert failed: (or (array? array) (js/goog.isArrayLike array))
	checked-aget' (cljs/core.cljs:469:8)

rauh14:12:20

@niklas.collin I think you can also use js-invoke

rauh14:12:43

Which looks pretty similar to your binded-call fn 🙂

Empperi14:12:24

looks like perfect match yeah

Empperi14:12:32

and exactly what I was looking for

mfikes14:12:19

Hah! I forgot about js-invoke

Empperi14:12:05

never needed it before

Empperi14:12:40

I was expecting that there would be a function for this in core considering it is not that rare case

Empperi14:12:46

just couldn’t find it

Empperi14:12:29

and yes, js-invoke works beautifully :thumbsup:

mfikes14:12:52

The nice thing about js-invoke is it safely uses what would otherwise be an incorrect call to aget, so it is likely much more performant than going through goog.bind. 🙂

Empperi14:12:05

this was pain to debug in overall, took some time to even find where the problem was

rauh14:12:10

If perf matters, then both of them are "improvable"

mfikes14:12:16

I'm a little embarrased, given I made that change 🙂 Heh.

Empperi14:12:18

but finally my app is working with :advanced mode

mfikes14:12:41

There's lot of cool stuff listed under (apropos "js-") that I don't appreciate 🙂

mfikes14:12:15

@rauh As a faster alternative to js-invoke would you cache the result of goog.object/get and then perhaps also optimize the call to .apply by passing a JavaScript array literal for your arguments?

rauh14:12:02

@mfikes Yeah I also see js-in underappreciated. 🙂 I'd probably pluck the array out of the passed IndexedSeq directly, just like some fns in core do it. Then passing that array to apply.

rauh14:12:47

Fun fact: bind will soon be faster in v8: https://v8project.blogspot.de/

mfikes14:12:02

Cool. It looks like js-invoke is not even used in ClojureScript itself anywhere.

rauh14:12:34

Yeah I never used it either. I'm guessing it's super old 🙂

rauh14:12:27

And js-invoke could be made multi arity and then efficiently invoked for low arity with (js* ...)

rauh14:12:03

FWIW, fn-invoke-direct would also properly call it, just not in dev mode.

dnolen15:12:58

heh, I forgot about js-invoke, I think I added that years ago?

dnolen15:12:59

yeah for "@@iterator", 3 years ago

Oleh K.18:12:15

I've got an error compiling cljs with node dependencies: node_modules/firebaseui/dist/firebaseui.css: Unexpected token, expected ( (1:8) Anybody knows what to do with this?

martinklepsch18:12:52

@okilimnik that reads like it’s trying to parse CSS as JS maybe?

Oleh K.18:12:57

FirebaseAuth.js from react-firebaseui module has this code: require('firebaseui/dist/firebaseui.css')

Oleh K.18:12:49

i think it is a common react code

juhoteperi19:12:22

@okilimnik FirebaseUI depends on webpack to bundle CSS. Closure-compiler doesn't support that.

thheller19:12:16

just use shadow-cljs, it already filters css requires.

thheller19:12:55

although you’d need to somehow link them into your your css manually then, so its not perfect either 😉

juhoteperi19:12:42

@thheller It just ignores these requires? I could probably implement same in Cljs compiler

thheller19:12:45

@juhoteperi it depends but most of the time they are safe to ignore since they are blank require statements and their return value is ignored

thheller19:12:52

basically just telling webpack to include the css

thheller19:12:05

but it is not parsed as JS or anything

thheller19:12:37

you could maybe hand the closure compiler a fake empty firebaseui/dist/firebaseui.css.js to make it happy

thheller19:12:21

it is not very common for “dist” files to have these css requires

juhoteperi19:12:35

Yeah, I think using empty files would solve this

Oleh K.19:12:33

Got it, thanks.

thheller19:12:44

its a horrible pattern 😞

juhoteperi19:12:22

Huh, ES6 module using require on runtime..

thheller19:12:37

its really just for webpack, nothing more.

thheller19:12:32

well, I guess const firebaseui = require('firebaseui'); is even worse

thheller19:12:39

closure is going to hate that 😛

juhoteperi19:12:37

It might be able to hoist the requires to top-level, and then just get the exported value later

thheller19:12:44

from their comments I guess they do this so SSR doesn’t load these requires since import can’t be conditional anymore

Oleh K.19:12:28

I think that it is better just to remove css requiring and to add a link in index.html. But how to force cljsbuild do not reload dependencies? It rolls back my changes

juhoteperi19:12:49

@okilimnik If you don't use :install-deps but manually install Node packages, the changes shouldn't be lost. But this is not very clean solution.

Oleh K.19:12:54

Yeah, I've just tried it and it has compiled

Oleh K.19:12:07

I think a clean solution will be when clojurescript will support these cases from the box 🙂

thheller19:12:45

FWIW the react-firebaseui doesn’t seem to do anything useful. you can probably write that in 5 lines of CLJS yourself

juhoteperi19:12:53

And I think firebaseui is implemented as Closure library, so using it as such instead of through Module processing will probably work lot better

thheller19:12:50

@juhoteperi unfortunately firebase is only published as an :advanced compiled bundle. no sources available.

thheller19:12:04

at least I couldn’t find any

thheller19:12:53

oh, ok cool

thheller19:12:06

assumed that was part of firebase itself, guess its not

thheller19:12:15

hmm nope, the firebaseui package again doesn’t contain any sources only the dist file 😞 (which is :advanced)

Miloslav19:12:19

could you please help me?

Miloslav19:12:34

I'm trying to use pouchdb with reframe, so I'm doing exactly what manual says and keep getting Uncaught ReferenceError: cljsjs is not defined

Miloslav19:12:03

I have [cljsjs/pouchdb "6.3.4-0"] in my dependencies in project.clj

Miloslav19:12:27

(ns frontend-boilerplate.db
  (:require cljsjs.pouchdb)) 

(println cljsjs.pouchdb)
this fails

Miloslav19:12:40

what should I do?

juhoteperi19:12:23

@melvoloskov (println js/PouchDB)

Miloslav19:12:51

#object[PouchDB$5]

juhoteperi19:12:47

That looks correct. This package doesn't support :global-exports feature which would allow accessing the JS object using namespace name or alias, so you need to access it using the JS global.

Miloslav19:12:57

it feels like i'm just missing something very basic

Miloslav19:12:06

im using cljsls for the first time

juhoteperi19:12:21

Missing externs won't affect dev builds at all. What's the problem? If it compiles and println prints the object, it seems to be working?

juhoteperi19:12:41

Also the issue is closed and externs have been added.

Miloslav19:12:06

but how do I use it properly, without that js/ thing?

Miloslav19:12:16

just like the other packages

Miloslav19:12:42

or should I use js/PouchDB instead?

antonpaisov20:12:09

now on my macbook it works, but I had to uninstall Java 9 and install jdk 1.8 (I use a machine with Fedora installed as a main one recently and it still doesn’t work there)

michaels20:12:05

Part of my confusion as to what is going on is that I’m using jenv to swap out java versions. 😱

tomc21:12:31

Could someone please help me understand some behavior I'm seeing? I'm not sure where to look for the source of the problem: I'm developing with figwheel and trying to add an npm-dep to a namespace. I've got the project.clj set up to pull in the dep (apollo-client). When I add the dep to the namespace with (:require [apollo-client :as apollo]), figwheel tries to compile but throws this error: "Undefined nameToPath for apollo_client". This points to a failure of mine to understand how to use npm-deps, but that's not the big problem I'm seeing. If I then remove that require from the namespace, figwheel continues to recompile on changes to the namespace, but begins printing not required: ('path/to/file' nil), and no future changes to the file are picked up unless I kill and restart the figwheel process. Any ideas?

Roman Liutikov21:12:10

This was reported so many times already. Probably a bug in cljs. For me it worked well without Figwheel

seako21:12:26

i remember i came across a ticket the other day where someone else ran into an issue using that same library https://dev.clojure.org/jira/browse/CLJS-2369

seako21:12:37

here's another ticket for the other issue i've seen "Reference error: require is not defined."

seako21:12:10

this one's got some patches against the google closure compiler to address the underlying issue https://github.com/google/closure-compiler/pull/2622 https://github.com/google/closure-compiler/pull/2627

seako21:12:15

which is just to say that the npm-deps feature is being actively worked on and some of the issues people are encountering are resolved by patching google closure compiler and it seems getting patches accepted into that project can take a while

thheller21:12:56

in the meantime you could just try shadow-cljs which doesn’t have any of these issues 😉