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

Migrate find / findAll to wait for selectors. #29

Closed
rwjblue opened this issue Mar 2, 2017 · 3 comments
Closed

Migrate find / findAll to wait for selectors. #29

rwjblue opened this issue Mar 2, 2017 · 3 comments
Assignees
Milestone

Comments

@rwjblue
Copy link
Collaborator

rwjblue commented Mar 2, 2017

I am working up updates to the testing RFC (thanks to this library pushing things forward), and am beginning to incorporate the changes suggested by @machty in emberjs/rfcs#119 (comment).

The crux of his proposal is that we make find and findAll (and therefore all the other helpers that use them to sanitize selector inputs) wait for the selector to return a match. It would wait until either the selector is present or wait() completes (whichever happens first). The change to consumers are fairly small (in most cases apps wouldn't even be aware of the distinction), but the impact has the potential to be quite large for many edge cases.

Conveniently @machty has already done a ton of work in this area (custom find helper implemented in ember-concurrency), that we can take advantage of.

Again, to reiterate what I mentioned above, the 90% use case for folks does not change (other than making find an async operation).

@rwjblue rwjblue added this to the 0.4.0 milestone Mar 2, 2017
@rwjblue rwjblue self-assigned this Mar 2, 2017
@pixelhandler
Copy link
Collaborator

pixelhandler commented Mar 2, 2017

@rwjblue so find and findAll become async by default. The current acceptance helpers have find as sync. But a default async find makes sense in that it waits for "its world" to "settle" first. I like that :).

However, I'm curious about how long the wait is for "the selector is present or wait() completes", is it enough? is there potential for race condition? So, should there also be a findSync and findAllSync for no need to be Promise aware?

I Notice that there are times when I test that I need some kind of extra run loop for things to settle. Does using an async find helper that can wait to settle address that scenario?

Does making the find helpers async add any confusion about "leading edge wait" vs "trailing edge wait"? Wait to exist is "leading", while the world settles. But, other helpers that are async are "trailing", after the world settles.

What is the use case for "wait to exist" when other helpers also wait for settling?

@cibernox
Copy link
Owner

cibernox commented Mar 2, 2017

My understanding is that in integration find/findAll don't need to be asynchronous, right?

@rwjblue
Copy link
Collaborator Author

rwjblue commented Mar 23, 2017

I am working on updating the RFC to match the various changes that we have worked through in this repo.

I think for now we are going to suggest using thewaitUntil helper...

@rwjblue rwjblue closed this as completed Mar 23, 2017
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

3 participants