Clojurians Log v2

hi, is there a way to click on a link with specific text? something like this (not working because there is no special handling for :text):

(click-visible driver {:tag :a :text "Forgot your password?"})

changed q-xpath to support text queries so that q-expand generates this:

user> (ea/q-expand driver {:tag :a :text "Forgot your password?"})
["xpath" ".//a[text()='Forgot your password?'"]

Just a heads up, if any of you are using reagent ... then don't use the shorthand for classes. Etaoin will correctly find [:div {:class "foo"} "bar"] but it won't find [:div.foo "bar"]. I am assuming this is a problem with reagent and not Etaoin ... but it took me a while to make a guess and figure that out

@gadfly361 How is this related to Reagent at all? It’s just syntax that is supported or not I think?

@borkdude the :tag.classname was sugar added by reagent. I am assuming whatever it is doing to convert to the attribute class has some slight difference than defining it in the attribute hash-map. I don't understand why that would be the case, but just describing what i observed

@gadfly361 I don’t fully understand. It doesn’t matter how Reagent generated the dom nodes. This is unrelated to how etaoin selects them via xpath?

You cannot just use Reagent shorthand syntax in etaoin, the implementation might differ, that’s what I mean

@borkdude Oh, sorry for not being clear, I would be using {:class "foo"} as the q in etaoin in either scenario

@gadfly361 As long as the class is there in the DOM, it should not matter how Reagent does it right? At least, it works here

so let's say in etaoin i was using (wait-visible {:class "foo"}) against some html that was made in reagent using 1) [:div {:class "foo"} "bar"] 2) [:div.foo "bar"]

etaoin only finds 1) and not 2)

If you do inspect element, what do you see in both cases?

that the class is there

what if you try wait-exists instead of wait-visible

@borkdude you were correct to call BS 🙂 I reduced my problem to the following

(defn mycomp []
  [:div.foo
   {:class (string/join " "
                        (remove nil?
                                [nil
                                 nil]))}
   "bar"])

I didn’t call it BS? 😉

@borkdude I appreciate your help!!

But etaoin could help with detecting classes being present instead of matching literally. I guess worth opening up an issue?

I think matching literally makes sense. Honestly, I don't want to ask too much of the maintainer since I am sure there is a lot on the roadmap. Thanks again for helping me figure that out ... I was about to strip out all the .classnames in my codebase hahah

You can always fall back to xpath:

//div[contains(@class, 'some-class')]

Why does fill-el do (vec keys). I get a JsonGenerationException on this, like (cheshire.core/generate-string (vec “foo”))

I’m not sure what’s going on though, it used to work for me

Funny, when bringing in [cheshire "5.8.0"] it works again. I moved my integration tests to a standalone project and didn’t bring in that dependency. It might be a bug to convert the string into a vector @igrishaev?

Ah, when not depending explicitly on cheshire, another dependency brings in an older version of cheshire, which could not yet handle a java Character.

Really cool library. Does it handle iframes?