The Node method synchronize is not exposed in the Session

[avinasha]

The wait_until method in the Session is now removed and the wait_until method for the Node is renamed to synchronize

According to this

https://github.com/jnicklas/capybara/blob/master/lib/capybara/node/base.rb#L15

synchronize should be exposed in Session

But I could not find it. Is there any other way to access this method?

[jnicklas]

Technically yes. It's a deliberate decision not to expose synchronize in the session. People are going to assume that synchronize is a waiting function, and use it as such. It's not. It has very specific semantics, which are very different from wait_until. I'm afraid people are going to do s/wait_until/synchronize/ and not realize that what they're doing is wrong/unnecessary.

[avinasha]

Thank you for the clarification..

[johncant]

How can you decide not to expose this incredibly useful function based on a possible error which some people might make? Would you consider exposing it if I made a pull request?

[jnicklas]

I'm open to a discussion certainly. I've seen so many people misuse wait_until though, and write silly stuff like

wait_until { page.body.match /<h2>Foobar</h2>/ }

I guess some people will always simply not RTFM and I shouldn't be bothered about that. So maybe I'm wrong, I just have a feeling that it's too hard to understand what the hell synchronize does without some kind of understanding of the Capybara internals.

[johncant]

Hi jnicklas,

Not that I'm any kind of expert in the semantics of wait_until and synchronize, but I'd say that (1) It's useful and (2) They're buried deep within the documentation/code, so you'd have to RTFM to even find them!

[natritmeyer]

Hi @jnicklas,

A philosophical point:

So I understand your arguments for why you want to hide #synchronize, and how the method is not simply a renaming of the capybara 1.x #wait_until method. It is also cool how generally in capybara you don't need to concern yourself with waiting for elements to appear due to automagic synchronizing. Kinda analogous to how OS X makes things all pretty and easy to use - lots of things happen automatically without having to concern yourself with trivial details. But... Apple still give me Terminal.app to use when I want to do something with my mac that Jonny Ive would rather I didn't. In the same spirit, if I were in your position, I'd leave #synchronize public.

A practical question:

With #wait_until gone and without access to #synchronize, I'm trying to work out how to allow for customized wait times. How would I convert the following capybara 1.x code to work in 2.x?

#using capybara 1.x, wait for 30 seconds for something to appear in the DOM

Capybara.default_wait_time = 5

Capybara.using_wait_time 30 do
  wait_until { has_selector? "div.title" }
end

If I understand capybara 2.x's code right, shouldn't the following be what I want?

#using capybara 2.x, is this how I'd wait for 30 seconds for something to appear in the DOM?

Capybara.default_wait_time = 5

Capybara.using_wait_time 30 do
  has_selector? "div.title"
end

Ie: just get rid of #wait_until and let #has_selector? do the synchronizing in the background?

Regards,

Nat Ritmeyer

[jnicklas]

@natritmeyer: you're spot on in your second example. The wait_until call there was redundant even under Capybara 1.x. It would have worked just as well without it.

It's not so much that you can't manually wait. It's trivial to implement wait_until yourself: https://gist.github.com/d8da686061f0a59ffdf7, but I would consider it a last resort.