Fork me on GitHub
#clojurescript
<
2017-04-06
>
john00:04:41

@robert-stuttaford There is a more recent clj selenium library than clj-webdriver, I believe

anmonteiro00:04:31

@robert-stuttaford are there features in Selenium that you need that clj-webdriver doesn’t have?

anmonteiro00:04:39

we’re still using clj-webdriver FWIW

tmarble00:04:51

@anmonteiro webica abuses introspection to expose the most recent Selenium. At the moment it's a little tricky to expose the API docs (a la codox), but it allows you to use the latest

tbaldridge00:04:40

@robert-stuttaford On several projects I've worked on we've just stuck with cljs.test (or clojurescript.test as it was called back then IIRC), and ran code only tests. That does leave you open to UI bugs, but I have yet to find a solution that that isn't super fragile. And doing code level tests forces you to decouple DOM elements from your business logic, which is a good idea anyways.

lsenta05:04:36

the Clojurescript compiler throws me:

Unsupported binding form: 1 at line 43, column 5 in file test/cljs/budb/cljs/firebase_test.cljs
If I write the code myself, I don't get such error, and the expansion looks fine:
(macroexpand '(test-firebase S 1))
=> (budb.test.helpers/test-async S 
       (budb.test.helpers/test-within S 4000 
         (superv.async/go-try S (do 1))))
Have you seen this case? Where should I look to understand the reason for this exception?

thheller07:04:28

@lsenta that error is from destructuring something, so if you have something like (let [:foo 1] ...)

thheller07:04:32

maybe budb.test.helpers/test-within

thheller07:04:00

or budb.test.helpers/test-async if any of these are macros

thheller07:04:51

you are emitting (let [1 :foo] ...) somewhere

thheller07:04:00

which is what Unsupported binding form: 1 is saying

thheller07:04:38

or (fn [1] ...) or any other place you could have bindings

lsenta07:04:12

Hum, test-async and test-within are functions, and go-try is a superv.async macro

thheller07:04:49

does just this work (superv.async/go-try S (do 1))?

lsenta07:04:10

Yea, even the macro expands work

thheller07:04:14

maybe something in that macro doesn't like the 1?

lsenta07:04:17

(macroexpand '(test-firebase S 1))
=> (budb.test.helpers/test-async S 
       (budb.test.helpers/test-within S 4000 
         (superv.async/go-try S (do 1))))

lsenta07:04:28

If I copy the result (or write it myself without the namespaces)

lsenta07:04:29

it compiles

thheller07:04:07

(test-firebase S :foo) does this change the error to Unsupported binding form: :foo?

thheller07:04:58

so the error is in test-firebase macro

lsenta07:04:17

It's so basic, could you let me know if you see something weird?

(defmacro test-firebase
     [supervisor-sym & body]
     `(test-async ~supervisor-sym
        (test-within ~supervisor-sym 4000
          (go-try ~supervisor-sym
            (do ~@body)))))

danielgrosse07:04:45

@anmonteiro Is there a problem, loading system libraries from nodejs? I recompiled the closure compiler and clojurescript to use the latest version. Now it throws multiple errors like WARNING: JSC_JS_MODULE_LOAD_WARNING. Failed to load module "util" at /Users/danielgrosse/dev/clojure/npm-compile-test/node_modules/json/lib/json.js line 14 :

thheller07:04:16

@lsenta no idea, reduce that until the error goes away. probably the go-try since that is where the 1 ends up

lsenta09:04:06

@thheller thanks for the help, I still don't see what's wrong I'll work around it for now.

thheller09:04:40

@lsenta yeah it a weird one, be aware that line/column information may be off if the form is actually inside another macro

thheller09:04:37

so maybe you are looking at the wrong thing, probably not though since the :foo test worked

thheller10:04:13

@piotr2b not possible in CLJS

piotr-yuxuan10:04:23

@thheller thx for your answer. I was feeling the same. How could we prove it? Perhaps by saying there is no such thing as Var in cljs?

thheller10:04:56

pretty sure it says that somewhere

thheller10:04:16

static vars are ok and possible, dynamic vars are not

thheller10:04:46

@zerusski don't extend protocols onto native types, they are mutable collections. you will get yourself into trouble 🙂

zerusski10:04:20

but the interwebs told me I should

thheller10:04:45

array-seq is the way to go and as you see it works 😉

thheller10:04:09

although still mutable so be careful

zerusski10:04:21

Could you point me to a longwinded explanation as to why please?

zerusski10:04:03

I'm not too immersed in cljs ecosystem and seems like there's much dated information on the net

zerusski10:04:51

Is there perhaps a "best practices" and "dos and don'ts" for cljs?

thheller10:04:26

no idea where that is written down, if at all. it is my personal recommendation based on experience but I'm sure others share my opinion

thheller10:04:30

but you are right, that should probably be written down somewhere. maybe on http://clojurescript.org

zerusski10:04:10

I understand js and browser could be a moving target, but why doesn't it work in this particular case?

zerusski10:04:30

I'm not mutating anything, nor have I reloaded the page

thheller10:04:11

it may depend on your browser ... some browsers in the past didn't let you extend native objects

zerusski10:04:23

the only thing that comes to mind is that this isn't "the droid I'm looking for". Different type that serialises to the same name

thheller10:04:23

I think that was IE though

thheller10:04:33

you might not be working with a HTMLCollection as well. native types do not strictly follow the JS inheritance chain sometimes

thheller10:04:17

native types are scary

zerusski10:04:04

yeah, that's my suspicion here, too. Thank you for answers.

zerusski10:04:19

I'm happy to submit an issue if you feel I should

zerusski10:04:48

haha, @thheller I think you are absolutely right. To test I put some divs on the page, grabbed em with .getElementsByClass. And extend-type worked beautifully. So I suspect the stuff I was getting wasn't HTMLCollection but reported as being one. I guess not worth reporting that

thheller11:04:38

that is my experience with protocols on native types as well .. sometimes they work ... sometimes they don't for reasons unknown 🙂

selfsame13:04:41

@zerusski iframes have their own js sandbox, so you'd need to extend-type from inside it

selfsame13:04:23

(= (type (.. (.-contentDocument frame) -body -children))
   (type (.. js/document -body -children)))
;false

sakalli13:04:22

hi, what blog post or talk would you recommend, if you could choose only one, to inspire a js & frontend developer to try out fp & ClojureScript. we're building a poc app with react native and this could be an opportunity to try out clojurescript. (not for me)

spinningtopsofdoom13:04:22

I'd also show them the FigWheel talk at ClojureWest https://www.youtube.com/watch?v=j-kj2qwJa_E

selfsame14:04:02

@zerusski actually now that I poke around, you can extend-type iframe types like this:

(def frame (-> js/document (.getElementsByTagName "iframe") (aget 0)))

(extend-type frame.contentWindow.HTMLCollection
  ISeqable
  (-seq [o] (array-seq o 0)))

zerusski14:04:33

@selfsame this is very good to know. Thank you very much for investigating!

anmonteiro14:04:39

@danielgrosse are you compiling with :target :nodejs?

danielgrosse11:04:15

It has to run in the browser, and the compiling breaks.

anmonteiro15:04:39

Right. Makes total sense. There's no 'util' module in the browser

danielgrosse06:04:42

But when I compile it with browserify it works.

danielgrosse09:04:35

Okay. Now it does.

anmonteiro15:04:16

Probably because Browserify has a polyfill for some internal Node modules

anmonteiro14:04:24

Oh that's just a warning anyway. It'll work at runtime since it's internal

ghaskins16:04:07

I have a clojurescript macro expansion question for anyone knowledgable here: in a nutshell, the issue I can't figure out is that a simple interop form like (.foo bar baz) correctly expands to bar.foo(baz); but expanding that same form within a macro seems to be adding a phantom .call(null) and I dont understand why

ghaskins16:04:46

e.g. it turns into bar.foo(baz).call(null); inside the macro usage

ghaskins16:04:49

any help appreciated

jr16:04:21

do you have an example?

ghaskins16:04:29

@jr its part of opensource, so let me push my working tree and show you

ghaskins16:04:58

@jr (keep in mind this is a push from mid-hack), here is the basic function I am trying to macroify

ghaskins16:04:35

essentially, hfc.newDefaultKeyStore() uses ES6 promises, and I am trying to wrap them in promesa promises

ghaskins16:04:38

with the idea being I want to do something like (m/pwrap (.newDefaultKeyValStore hfc #js {:path path}))

ghaskins16:04:10

with the idea that the form passed in is expanded in the same way as when I use it natively

ghaskins16:04:06

hmmm, i think I just rubberduck'd it

ghaskins16:04:27

I think the issue was the [& expr] on the macro, when I wanted [expr]

ghaskins16:04:44

forest for the trees...

jfntn20:04:40

I’m looking at cljs test runners, are there any good options besides https://github.com/bensu/doo ?

anmonteiro20:04:45

@jfntn I’ve been using Doo successfully in all my CLJS projects

anmonteiro20:04:04

if you’re using Boot, this is what you want (uses Doo too): https://github.com/crisptrutski/boot-cljs-test/

jfntn20:04:04

@anmonteiro thanks that looks good

jfntn20:04:01

@anmonteiro do you any cljs-specifc reasons for using boot over lein besides personal preference?

anmonteiro20:04:24

mostly personal preference

anmonteiro20:04:29

in some cases I need custom build pipelines