You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
@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?
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
andfindAll
(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 orwait()
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).The text was updated successfully, but these errors were encountered: