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.

Sign up for GitHub

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

New Async Component API #148

Merged
merged 5 commits into from
Apr 9, 2020
Merged

New Async Component API #148

Changes from 1 commit
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
00c9a98
async component
yyx990803 Mar 25, 2020
7eac42c
createAsyncComponent -> defineAsyncComponent
yyx990803 Mar 26, 2020
16c6988
rename loading/error options, update retry usage
yyx990803 Mar 27, 2020
2793672
update retry control per feedback
yyx990803 Apr 7, 2020
b0e002a
Rename 0000-async-component-api.md to 0026-async-component-api.md
yyx990803 Apr 9, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
27 changes: 23 additions & 4 deletions active-rfcs/0000-async-component-api.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -71,8 +71,13 @@ const AsyncFooWithOptions = defineAsyncComponent({
delay: 100, // default: 200
timeout: 3000, // default: Infinity
suspensible: false, // default: true
retryWhen: error => error.message.match(/fetch/) // default: () => false
maxRetries: 5 // default: 3
onError(error, retry, fail, attempts) {
if (error.message.match(/fetch/) && attempts <= 3) {
retry()
} else {
fail()
}
}
})
```

Expand Down Expand Up @@ -104,9 +109,23 @@ const AsyncFooWithOptions = defineAsyncComponent({

## Retry Control

The new `retryWhen` option expects a function that returns a boolean indicating whether the async component should retry when the loader promise rejects. The function receives the rejection error as the argument so it can conditionally retry only on certain types of errors.
The new `onError` option provides a hook to perform customized retry behavior in case of a loader error:

``` js
const Foo = defineAsyncComponent({
// ...
onError(error, retry, fail, attempts) {
if (error.message.match(/fetch/) && attempts <= 3) {
// retry on fetch errors, 3 max attempts
retry()
} else {
fail()
}
}
})
```
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@CyberAP that doesn't seem to be much different from retryWhen, and it doesn't have the flexibility @Morgul wanted.

I agree with @backbond87 that a separate onError option might be the most straightforward.

I am ok with that idea as well. Could onError arguments be contained in a single destructurable object? So there's no need to remember the exact order in which they're passed to a callback.

Suggested change
``` js
const Foo = defineAsyncComponent({
// ...
onError(error, retry, fail, attempts) {
if (error.message.match(/fetch/) && attempts <= 3) {
// retry on fetch errors, 3 max attempts
retry()
} else {
fail()
}
}
})
```
``` js
const Foo = defineAsyncComponent({
// ...
onError({ error, retry, fail, attempts }) {
if (error.message.match(/fetch/) && attempts <= 3) {
// retry on fetch errors, 3 max attempts
retry()
} else {
fail()
}
}
})

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know, the order feels pretty natural to me. With destructure instead of the order, you'll have to remember the exact names. It's not much different imo.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Its less about remembering imho, but more about needing only a few of the args most of the time, depending on the use case. See my examples


The `maxRetries` option determines how many retries are allowed (default: `3`). When max times of retries have been attempted, the component will go into error state (render the `errorComponent` if provided) with the last failed error.
Note that `retry/fail` are like `resolve/reject` of a promise: one of them must be called for the error handling to continue.

## Using with Suspense

Expand Down