Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

xpath/select-all shouldn't be evaluated lazily #46

Open
smoes opened this issue Apr 15, 2020 · 1 comment
Open

xpath/select-all shouldn't be evaluated lazily #46

smoes opened this issue Apr 15, 2020 · 1 comment
Assignees

Comments

@smoes
Copy link

smoes commented Apr 15, 2020

In the following example the behavior of xpath/select-all seems unintuitive because of lazyness:

(let [comp (tu/mount a-div-containing-component)
      divs-before (xpath/select-all comp (xpath/>> ** "div"))
      comp (send-message!! comp :destroy-all-divs)]
    (assert (pos? (count divs-before))))

Assuming the div-containing-component contains at least one div before sending the message and zero after. divs-before returns an empty list, since the query is evaluated after all divs where destroyed. That said, the assertion will fail. Wrapping it in (doall (xpath/select-all ...)) fixes the problem.

I'd expect xpath/select-all to be evaluated eagerly.

@dfrese
Copy link
Member

dfrese commented Jun 30, 2020

I could not reproduce this; even tried it in 2.2.0.
Can you provide a proper test case (in xpath-test maybe) resp. try again?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants