From 98f3bd15ec8eb18cedf92fe54d48a6744f5b9f59 Mon Sep 17 00:00:00 2001 From: Mohaned Benmesken Date: Mon, 29 Jan 2024 15:11:38 +0200 Subject: [PATCH] Fix typos in = combining_requests.mdx (#3309) --- .../docs/essentials/combining_requests.mdx | 20 +++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/website/docs/essentials/combining_requests.mdx b/website/docs/essentials/combining_requests.mdx index 7acf31d05..324d8736e 100644 --- a/website/docs/essentials/combining_requests.mdx +++ b/website/docs/essentials/combining_requests.mdx @@ -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 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 @@ -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: @@ -77,12 +77,12 @@ Then, we could use this location to fetch the list of restaurants near the user. :::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. ::: @@ -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