Convert BaseCollection.fetch to return a promise.
Review Request #11629 — Created May 27, 2021 and submitted
This is the first of what is likely to be many steps to move our
codebase towards a more modern feel of using promises and
async
/await
for asynchronous operations. In this change,
BaseCollection.fetch
has been changed, along with everything that
actually uses that including similar methods inside
ResourceCollection
. The old callback usage is still available through
a helper which will wrap the returned promise, but causes a warning to
be logged to the console.This also tweaks to our browserslist config in order to ensure that
async
/await
won't get polyfilled out due to niche browsers
(primarily on mobile) that we really don't care about supporting.
- Ran js-tests.
- Manually tested data population on the review dialog and post commit
views.
Summary | ID |
---|---|
c6399fe4c61a8bfad98ec8e28a99a93699f16102 |
Description | From | Last Updated |
---|---|---|
Col: 11 Expected ':' and instead saw '_loadBranches'. |
reviewbot | |
Col: 27 Expected '}' to match '{' from line 9 and instead saw '{'. |
reviewbot | |
Col: 13 Expected an assignment or function call and instead saw an expression. |
reviewbot | |
Col: 18 Missing semicolon. |
reviewbot | |
Col: 9 Unrecoverable syntax error. (49% scanned). |
reviewbot | |
Col: 30 Expected ')' and instead saw 'function'. |
reviewbot | |
Col: 40 Missing semicolon. |
reviewbot | |
Col: 17 Expected an assignment or function call and instead saw an expression. |
reviewbot | |
Col: 22 Missing semicolon. |
reviewbot | |
Col: 30 Expected ')' and instead saw 'function'. |
reviewbot | |
Col: 40 Missing semicolon. |
reviewbot | |
Col: 17 Expected an assignment or function call and instead saw an expression. |
reviewbot | |
Col: 22 Missing semicolon. |
reviewbot | |
Col: 46 Expected ')' and instead saw 'function'. |
reviewbot | |
Col: 56 Missing semicolon. |
reviewbot | |
Col: 17 Expected an assignment or function call and instead saw an expression. |
reviewbot | |
Col: 22 Missing semicolon. |
reviewbot | |
Col: 37 Expected ')' and instead saw 'function'. |
reviewbot | |
Col: 47 Missing semicolon. |
reviewbot | |
Col: 17 Expected an assignment or function call and instead saw an expression. |
reviewbot | |
Col: 22 Missing semicolon. |
reviewbot | |
Col: 56 Expected ')' and instead saw 'function'. |
reviewbot | |
Col: 66 Missing semicolon. |
reviewbot | |
Col: 21 Expected an assignment or function call and instead saw an expression. |
reviewbot | |
Col: 26 Missing semicolon. |
reviewbot | |
Col: 40 Expected ')' and instead saw 'function'. |
reviewbot | |
Col: 50 Missing semicolon. |
reviewbot | |
Col: 17 Expected an assignment or function call and instead saw an expression. |
reviewbot | |
Col: 22 Missing semicolon. |
reviewbot | |
Col: 47 Expected ')' and instead saw 'function'. |
reviewbot | |
Col: 10 'promiseToCallbacks' is defined but never used. |
reviewbot | |
Col: 29 Missing semicolon. |
reviewbot | |
Col: 65 Missing semicolon. |
reviewbot | |
Col: 50 Missing semicolon. |
reviewbot | |
Col: 50 Missing semicolon. |
reviewbot | |
Col: 2 Unnecessary semicolon. |
reviewbot | |
Can we put this in a Version Changed block, like: Version Changed: 5.0: ... We should document every public function … |
chipx86 | |
Might be worth documenting why we have a function for this instead of just referencing _loadBranches directly (and same below). … |
chipx86 | |
Can we add a Clicked suffix to these? That'd be more in line with the naming for most other click … |
chipx86 | |
So this pattern doesn't quite preserve the logic we had before, and it might bite us. I think we need … |
chipx86 | |
This returns a jqXHR (jQuery specialization of XMLHttpRequest), not a promise. That seems an important distinction in return types. I'm … |
chipx86 | |
This is missing a return type. |
chipx86 | |
Hmm, the semantics of the function definitely changed here. We should document that. Do we depend on the old return … |
chipx86 | |
This is missing Args. Can we also add a Version Added? |
chipx86 | |
Why the move to : function(? |
chipx86 | |
Col: 31 Expected an identifier and instead saw '.'. |
reviewbot | |
Col: 32 Expected ':' and instead saw '$el'. |
reviewbot | |
Col: 36 Expected an operator and instead saw '.'. |
reviewbot | |
Col: 35 Expected an identifier and instead saw '?'. |
reviewbot | |
Col: 36 Expected an assignment or function call and instead saw an expression. |
reviewbot | |
Col: 37 Missing semicolon. |
reviewbot | |
Col: 27 Expected an identifier and instead saw '.'. |
reviewbot | |
Col: 28 Expected ':' and instead saw '$el'. |
reviewbot | |
Col: 31 Expected an identifier and instead saw '?'. |
reviewbot | |
Col: 32 Expected an operator and instead saw '.'. |
reviewbot | |
Col: 32 Expected an assignment or function call and instead saw an expression. |
reviewbot | |
Col: 33 Missing semicolon. |
reviewbot | |
We're no longer calling checkFetchNext(), which was part of the bug fix for the commit list not loading new commits. … |
chipx86 | |
You'll actually need a new Version Changed block for each version. The parser doesn't know how to split this up … |
chipx86 | |
There's 2 spaces between await and this.fetch. |
chipx86 | |
This will have to be above Args to render correctly. It's considered paragraph-level content for the description. |
chipx86 | |
Should this be fetch(...) or fetch: function(...)? |
chipx86 | |
We should probably say in all of these that callbacks are now deprecated and will be removed in Review Board … |
chipx86 | |
Entirely a food-for-thought, and not necessary for this change. What about opting into decorators support in Babel? (It's currently a … |
chipx86 | |
Do we need to still set this._fetchURL? |
chipx86 | |
Leftover debugging? |
chipx86 | |
The "5.0" has to be on its own line, or it won't be interpreted as a section, just text. |
chipx86 | |
Same here. |
chipx86 | |
Mind using parens to make the grouping more clear? |
chipx86 | |
Col: 2 Missing semicolon. |
reviewbot | |
Col: 31 Missing semicolon. |
reviewbot | |
Col: 32 Expected ':' and instead saw '$el'. |
reviewbot | |
Col: 31 Expected an identifier and instead saw '.'. |
reviewbot | |
Col: 35 Expected an identifier and instead saw '?'. |
reviewbot | |
Col: 36 Expected an operator and instead saw '.'. |
reviewbot | |
Col: 36 Expected an assignment or function call and instead saw an expression. |
reviewbot | |
Col: 37 Missing semicolon. |
reviewbot | |
Col: 27 Expected an identifier and instead saw '.'. |
reviewbot | |
Col: 28 Expected ':' and instead saw '$el'. |
reviewbot | |
Col: 31 Expected an identifier and instead saw '?'. |
reviewbot | |
Col: 32 Expected an operator and instead saw '.'. |
reviewbot | |
Col: 32 Expected an assignment or function call and instead saw an expression. |
reviewbot | |
Col: 33 Missing semicolon. |
reviewbot |
- Description:
-
This is the first of what is likely to be many steps to move our
codebase towards a more modern feel of using promises (and eventually async) for asynchronous operations. In this change, BaseCollection.fetch
has been changed, along with everything thatactually uses that including similar methods inside ~ ResourceCollection
.~ ResourceCollection
. The old callback usage is still available through+ a helper which will wrap the returned promise, but causes a warning to + be logged to the console. This also makes a slight tweak to our browserslist config in order to
ensure that async
won't get polyfilled out due to older chrome onandroid. - Commits:
-
Summary ID 1ea75eb10311e7e215d92b73039b86b05799f344 cf1142ac68ffc3d3850d5bdc828e8c2c247eb01a - Diff:
-
Revision 2 (+1550 -760)
- Change Summary:
-
Namespace helper method, fix Review Bot errors.
- Commits:
-
Summary ID cf1142ac68ffc3d3850d5bdc828e8c2c247eb01a 2a7be8ea22bc567b890bdbeb139d3ffcf1a60e85 - Diff:
-
Revision 3 (+1548 -760)
- Change Summary:
-
Semicolon.
- Commits:
-
Summary ID 2a7be8ea22bc567b890bdbeb139d3ffcf1a60e85 1596d1d77ef38df834e0326d5471a6e34d53c10c - Diff:
-
Revision 4 (+1548 -760)
- Commits:
-
Summary ID 1596d1d77ef38df834e0326d5471a6e34d53c10c 79ee4f343b971904505ac601393a356b1e016301 - Diff:
-
Revision 5 (+1548 -760)
Checks run (2 succeeded)
-
-
Can we put this in a
Version Changed
block, like:Version Changed: 5.0: ...
We should document every public function that's been changed to return a
Promise
. That'll help anyone that's trying to update code in 5.0 or even 6.0 timeframe. -
Might be worth documenting why we have a function for this instead of just referencing
_loadBranches
directly (and same below). I know the reasons now, but I'm sure I'll forget in another year. -
Can we add a
Clicked
suffix to these? That'd be more in line with the naming for most other click handlers in the codebase. -
So this pattern doesn't quite preserve the logic we had before, and it might bite us. I think we need to take a harder look at each of these conversions.
Before, the
error
handling code would run only iffetch()
failed, but now, it runs iffetch()
fails or if any of the previously-success
code fails.Any code called after that
await
that raises an exception (unlikely in this particular case, but conceivable) would trigger thecatch(error) {...}
, changing the UI in a way we don't expect.An argument could be made that, hey, in this case, we're just going through and setting up an error display, but 1) we'd lose out on the traceback, and 2) that code expects
err
to be an object with amessage
.I think what we're going to want to do is something more like:
try { await branches.fetch(); } catch (err) { ... return; } // success code here
This comment pertains to all other cases like this.
-
This returns a
jqXHR
(jQuery specialization ofXMLHttpRequest
), not a promise. That seems an important distinction in return types.I'm a bit concerned by just how much we're changing return types for this function, and how mixed it is. The old version would return a
true
orfalse
to indicate that the fetch had something to return in some cases, but ajqXHR
in this case. The new version replaces the booleans with promises but keeps thejqXHR
, but some code calling this assumes it's a promise.So we need to fix that, and we have to be careful, because this is public API.
I don't know the solution. The callbacks situation seems better, but return types are harder. Maybe the the way we're handling callbacks isn't enough? Maybe we need to put the function into a legacy mode if it's taking legacy arguments, and have that also include the return type as part of that legacy mode (in other words, ditch returning promises altogether if receiving callbacks)?
I don't know. I'm too tired to think of a solution. Got a couple more comments I already wrote up for this file, but since we need to solve this, I'll skip doing a full review for now.
-
-
Hmm, the semantics of the function definitely changed here. We should document that. Do we depend on the old return value anywhere in the codebase?
-
- Description:
-
This is the first of what is likely to be many steps to move our
~ codebase towards a more modern feel of using promises (and eventually ~ async) for asynchronous operations. In this change, ~ codebase towards a more modern feel of using promises and ~ async
/await
for asynchronous operations. In this change,BaseCollection.fetch
has been changed, along with everything thatactually uses that including similar methods inside ResourceCollection
. The old callback usage is still available througha helper which will wrap the returned promise, but causes a warning to be logged to the console. ~ This also makes a slight tweak to our browserslist config in order to
~ ensure that async
won't get polyfilled out due to older chrome on~ android. ~ This also tweaks to our browserslist config in order to ensure that
~ async
/await
won't get polyfilled out due to niche browsers~ (primarily on mobile) that we really don't care about supporting. - Commits:
-
Summary ID 79ee4f343b971904505ac601393a356b1e016301 cbad9df88c7ebf1844dd5fb79a3b05dad9127ffd - Diff:
-
Revision 6 (+1700 -764)
Checks run (1 failed, 1 succeeded)
JSHint
-
I love where this is all going.
-
-
We're no longer calling
checkFetchNext()
, which was part of the bug fix for the commit list not loading new commits. Probably a merge issue. -
You'll actually need a new Version Changed block for each version. The parser doesn't know how to split this up into individual blocks.
-
-
This will have to be above
Args
to render correctly. It's considered paragraph-level content for the description. -
-
We should probably say in all of these that callbacks are now deprecated and will be removed in Review Board 6.
-
Entirely a food-for-thought, and not necessary for this change. What about opting into decorators support in Babel? (It's currently a JS proposal.) Then we could wrap the option checks, the warning, and the
promiseToCallbacks
call, without repeating this block throughout the codebase. -
-
-
-
-
- Commits:
-
Summary ID cbad9df88c7ebf1844dd5fb79a3b05dad9127ffd c6399fe4c61a8bfad98ec8e28a99a93699f16102 - Diff:
-
Revision 7 (+1698 -764)