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

Fix typos in = combining_requests.mdx #3309

Merged
merged 1 commit into from
Jan 29, 2024
Merged
Changes from all commits
Commits
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
20 changes: 10 additions & 10 deletions website/docs/essentials/combining_requests.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -12,20 +12,20 @@ import watchPlacement from "./combining_requests/watch_placement";
import listenExample from "./combining_requests/listen_example";
import readExample from './combining_requests/read_example'

Up till now, we've only seens cases were requests are independent from each
Up till now, we've only seen cases where requests are independent from each
other. But a common use-case is to have to trigger a request based on the
result of another request.

We _could_ be using the <Link documentID="essentials/passing_args" /> mechanism to
do that, by passing the result of a provider as parameter to another a provider.
do that, by passing the result of a provider as a parameter to another provider.

But this approach has a few downsides:

- This leaks implementation details.
Now, your UI needs to know about all the providers that are used
your other provider.
- Whenever the parameter change, a brand new state will be made.
By passing parameters, there are no way to keep the previous state
- Whenever the parameter changes, a brand new state will be made.
By passing parameters, there is no way to keep the previous state
when the parameter changes.
- It makes combining requests harder.
- This makes tooling less useful. A devtool wouldn't
Expand All @@ -38,13 +38,13 @@ To improve this, Riverpod offers a different approach to combine requests.
All possible ways of combining requests have one thing in common:
They are all based on the `Ref` object.

The `Ref` object is an object which all providers have access to.
The `Ref` object is an object to which all providers have access.
It grants them access to various life-cycle listeners, but also
various methods to combine providers.

The place where `Ref` can be obtained depends on the type of provider.

In functional providers, the `Ref` is passed as parameter to the
In functional providers, the `Ref` is passed as a parameter to the
provider's function:

<AutoSnippet {...functionalRef} />
Expand Down Expand Up @@ -77,12 +77,12 @@ Then, we could use this location to fetch the list of restaurants near the user.
<AutoSnippet {...watchExample} />

:::info
When the listened provider changes and our request recomputes, the previous
state is kept until the new request completes.
When the listened to provider changes and our request recomputes, the previous
state is kept until the new request is completed.
At the same time, while the request is pending, the "isLoading" and "isReloading"
flags will be set.

This enables UI to either show the previous state, or a loading indicator,
This enables UI to either show the previous state or a loading indicator,
or even both.
:::

Expand All @@ -93,7 +93,7 @@ await for an initial value to be available.

If we omit that `.future`, we would receive an `AsyncValue`, which is a snapshot
of the current state of the `locationProvider`. But if no location is available yet,
we wouldn't be able to do anything.
we won't be able to do anything.
:::

:::caution
Expand Down
Loading