-
Notifications
You must be signed in to change notification settings - Fork 37
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
Simplify waitUntil
#130
base: master
Are you sure you want to change the base?
Simplify waitUntil
#130
Conversation
Was working on migrating this to `@ember/test-helpers` starting with the initial implementation here and simplified it a bit.
We could also probably remove the |
Failing this assertion:
This would be fixed by invoking |
That immediate resolution was added in #97 to avoid the 10ms delay for checking something that might already be true. I don't have strong feelings, but I think that it makes sense to test the condition immediately before doing any waiting. |
@simonihmig Did you do it for solving a problem? |
IIRC the main problem I was trying to solve in that mentioned PR was that before that it would immediately resolve the promise but still schedule another So the main assertion that I think is important there is that the callback is called just once:
Wether the promise resolves immediately (when the condition is fulfilled) or after a first timeout is not important to me. I also think I would make sense to immediately resolve, but I have no strong feelings about that either. |
I currently have https://github.com/rwjblue/ember-test-helpers/blob/b86cd963d6ff383be634d2f76a49bdbbd184578c/addon-test-support/%40ember/test-helpers/wait-until.js#L9-L28 in the WIP PR over in ember-test-helpers that I have been working on. At least in ember-test-helpers its pretty important that the helper is always async (having APIs that are sometimes sync and sometimes async is super error prone), in the current WIP (link above) I am running I'll continue iterating over in that PR (though I would absolutely love the continued help reviewing), and once things have settled implementation wise I'll make another crack at syncing the two libs back up... |
If asynchronously is important them I'm all for removing it. |
let time = 0; | ||
let tick = function() { | ||
function tick() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If I'm right, you should schedule the first tick with a 0 ms delay to exit as soon as possible but still respond asynchronously, correct?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, confirm. We need to change the initial time value to -10 and change the first tick to use 0. That’s what I did in my branch in the test helpers.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you port that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, absolutely. Was just trying to land it in test helpers then bring back any changes/tweaks from the implementations here once the PR in ember-test-helpers has landed.
Was working on migrating this to
@ember/test-helpers
starting with the initial implementation here and simplified it a bit.