docs: update documentation

website/docs/3.0_migration.mdx

@@ -8,15 +8,15 @@ import { AutoSnippet } from "/src/components/CodeSnippet";
 For the list of changes, please refer to the [What's new in Riverpod 3.0](whats_new) page.
 
 Riverpod 3.0 introduces a number of breaking changes that may require you to update your code.
-They should in general be relatively minor, but we recommend you to read this page carefully.
+They should, in general, be relatively minor, but we recommend you read this page carefully.
 
 :::info
 This migration is supposed to be smooth.  
 If there is anything that is unclear, or if you encountered a scenario that is difficult
 to migrate, please [open an issue](https://github.com/rrousselGit/riverpod/issues/new/choose)).
 
-It is important to us that the migration is as smooth as possible, so we will do our best to help you ; 
-improve the migration guide ; or even include helpers to make the migration easier.
+It is important to us that the migration is as smooth as possible, so we will do our best to help you, 
+improve the migration guide, or even include helpers to make the migration easier.
 :::
 
 ## Automatic retry
@@ -118,7 +118,7 @@ class MyWidget extends StatelessWidget {
 ## StateProvider, StateNotifierProvider, and ChangeNotifierProvider are moved to a new import
 
 In Riverpod 3.0, `StateProvider`, `StateNotifierProvider`, and `ChangeNotifierProvider` are considered "legacy".  
-They are not removed, but are no-longer part of the main API. This is to discourage their use
+They are not removed, but are no longer part of the main API. This is to discourage their use
 in favor of the new `Notifier` API.
 
 To keep using them, you need to change your imports to one of the following:
@@ -196,7 +196,7 @@ class MyObserver extends ProviderObserver {
 
 ## Simplified Ref and removed Ref subclasses
 
-For the sake of simplification, [Ref] lost its type parameter. And all properties/methods that were
+For the sake of simplification, [Ref] has lost its type parameter, and all properties/methods that were
 using the type parameter have been moved to [Notifier]s.  
 
 Specifically, `ProviderRef.state`, `Ref.listenSelf` and `FutureProviderRef.future` should be replaced by
@@ -308,8 +308,8 @@ To easily migrate, you can do a case-sensitive replace of `AutoDispose` to ` ` (
 
 ## The family variant of Notifiers is removed
 
-In the same vein as the previous point, the family variant of Notifiers is removed.
-Now, we use `Notifier`/`AsyncNotifier`/`StreamNotifier` only, and `FamilyNotifier`/... are removed.
+In the same vein as the previous point, the family variant of Notifiers has been removed.
+Now, we only use `Notifier`/`AsyncNotifier`/`StreamNotifier`, and `FamilyNotifier`/... have been removed.
 
 To migrate, you will need to replace:
 - `FamilyNotifier` -> `Notifier`

website/docs/concepts/about_hooks.mdx

@@ -11,7 +11,7 @@ import hookConsumerWidget from "!!raw-loader!./about_hooks/hook_consumer_widget.
 import { CodeSnippet } from "/src/components/CodeSnippet";
 import { Link } from "/src/components/Link";
 
-This page explains what are hooks and how they are related to Riverpod.
+This page explains what hooks are and how they are related to Riverpod.
 
 "Hooks" are utilities common from a separate package, independent from Riverpod:
 [flutter_hooks].  

website/docs/concepts2/auto_dispose.mdx

@@ -52,11 +52,11 @@ When automatic disposal is enabled, Riverpod will track whether a provider has l
 This happens by tracking [Ref.watch](https://pub.dev/documentation/hooks_riverpod/3.0.0-dev.17/hooks_riverpod/Ref/watch.html)/[Ref.listen](https://pub.dev/documentation/hooks_riverpod/3.0.0-dev.17/hooks_riverpod/Ref/listen.html)
 calls (and a few others).  
 
-When that counter reaches zero, the provider will be considered as "not used", and
+When that counter reaches zero, the provider is considered "not used", and
 [Ref.onCancel](https://pub.dev/documentation/hooks_riverpod/3.0.0-dev.17/hooks_riverpod/Ref/onCancel.html)
-will be triggered. 
-At that point, Riverpod will wait for one frame (cf `await null`). If after that frame,
-if the provider is still not used, then the provider will be destroyed and
+is triggered. 
+At that point, Riverpod waits for one frame (cf. `await null`). If, after that frame,
+the provider is still not used, then the provider is destroyed and
 [Ref.onDispose](https://pub.dev/documentation/hooks_riverpod/3.0.0-dev.17/hooks_riverpod/Ref/onDispose.html)
 will be triggered.
 ## Reacting to state disposal
@@ -68,11 +68,11 @@ In Riverpod, there are a few built-in ways for state to be destroyed:
 - The provider is recomputed, such as with `ref.watch`.
   In that case, the previous state is disposed, and a new state is created.
 
-In both cases. you may want to execute some logic when that happens.  
-This can be achieved with `ref.onDispose`. This methods enables
-registering a listener to whenever the state is destroyed.
+In both cases, you may want to execute some logic when that happens.  
+This can be achieved with `ref.onDispose`. This method enables
+registering a listener for whenever the state is destroyed.
 
-For example, you may want use it to close any active `StreamController`:
+For example, you may want to use it to close any active `StreamController`:
 
 <AutoSnippet {...onDisposeExample} />
 

website/docs/concepts2/consumers.mdx

@@ -89,7 +89,7 @@ of Riverpod's <Link documentID="concepts2/auto_dispose" /> in a reliable way. Th
 an implementation that "mostly works" with `BuildContext`.
 The problem is that there are lots of subtle edge-cases which could silently break the auto-dispose feature.
 
-This would cause memory leaks, but that's but that's not the real issue.  
+This would cause memory leaks, but that's not the real issue.  
 Automatic disposal is more importantly about stopping the execution of code that is no longer needed.
 If auto-dispose fails to dispose a provider, then that provider may continuously perform
 network requests in the background.

website/docs/concepts2/containers.mdx

@@ -94,7 +94,7 @@ Riverpod does this for a few reasons, which come down the the same logic: "No gl
 1. Better separation of concerns.  
   If Riverpod were to allow providers to store their own state,
   it would imply that _anything_ could read/write to that state. This means
-  that it would be difficult to control how/when is a state is modified.
+  that it would be difficult to control how/when a state is modified.
 
   Using Riverpod's architecture, state updates are centralized: All the logic
   for modifying a provider is done in the provider itself.

website/docs/concepts2/family.mdx

@@ -96,7 +96,7 @@ class Example extends ConsumerWidget {
 
 ## Overriding families
 
-When trying to mock a provider instead tests, you may want to override a family provider.  
+When trying to mock a provider in tests, you may want to override a family provider.  
 
 In that scenario, you have two options:
 - Override only a specific parameter combination:

website/docs/concepts2/offline.mdx

@@ -92,7 +92,7 @@ When specifying `key`, it is critical to ensure that:
 By default, state is only cached for 2 days. This default ensures that
 no leak happens and deleted providers stay in the database indefinitely
 
-This is generally safe, as Riverpod is designed to be use primarily
+This is generally safe, as Riverpod is designed to be used primarily
 as a cache for IO operations (network requests, database queries, etc).
 But such default will not be suitable for all use-cases, such as if
 you want to store user preferences.

website/docs/concepts2/overrides.mdx

@@ -12,7 +12,7 @@ In Riverpod, _all_ providers can be overridden to change their behavior.
 This is useful for testing, debugging, or providing different implementations in different environments,
 or even <Link documentID="concepts2/scoping"/>.
 
-Overriding a provider is done at on <Link documentID="concepts2/containers"/>, using the `overrides` parameter.
+Overriding a provider is done on <Link documentID="concepts2/containers"/>, using the `overrides` parameter.
 In it, you can specify a list of instructions on how to override a specific provider.
 
 Such "instruction" is created using your provider, combined with value methods named `overrideWithSomething`.  

website/docs/concepts2/providers.mdx

@@ -30,7 +30,7 @@ Future<User> fetchUser() async {
 }
 ```
 
-One issue with this function is, if we were to try using it inside a widgets,
+One issue with this function is, if we were to try using it inside widgets,
 we'd have to cache the result ourselves ; then figure out a way to share 
 the value across all widgets that need it.
 

website/docs/concepts2/refs.mdx

@@ -112,7 +112,7 @@ Riverpod offers two ways to listen to a provider's state:
 - [Ref.watch] - This is a "declarative" way of listening to providers.  
   It is the most common way to listen to providers, and should be your go to choice.
 - [Ref.listen] - This is a "manual" way of listening to providers.  
-  It is use typical "addListener" style of listening. Powerful, but more complex.
+  It uses a typical "addListener" style of listening. Powerful, but more complex.
 
 For the following examples, consider a provider that updates every second:
 

website/docs/from_provider/motivation/motivation.mdx

@@ -65,7 +65,7 @@ In the previous snippet, watching `evenItemsProvider` will produce the following
 
 With Provider, the above features aren't remotely achievable, and even less easy to workaround.
 
-### Combining providers is hard and error prone
+### Combining providers is hard and error-prone
 With Provider we may be tempted to use `context.watch` inside provider's `create`.  
 This would be unreliable, as `didChangeDependencies` may be triggered even if no dependency 
 has changed (e.g. such as when there's a GlobalKey involved in the widget tree).

website/docs/from_provider/quickstart.mdx

@@ -52,7 +52,7 @@ Take your time, as it is important to get yourself familiar with Riverpod first;
 you'll quickly find out that *almost* all Providers from pkg:provider have a strict equivalent in pkg:riverpod.
 :::
 
-## Starts with *leaves*
+## Start with *leaves*
 
 Start with Providers that do not depend on anything else, i.e. start with the *leaves* in your dependency tree.  
 Once you have migrated all of the leaves, you can then move on to the providers that depend on leaves.

website/docs/how_to/cancel.mdx

@@ -85,7 +85,7 @@ The exact code needed to cancel the request will depend on the HTTP client.
 In this example, we will use `package:http`, but the same principle applies
 to other clients.
 
-The key here that `ref.onDispose` will be called when the user navigates away.
+The key here is that `ref.onDispose` will be called when the user navigates away.
 That is because our provider is no-longer used, and therefore disposed
 thanks to automatic disposal.  
 We can therefore use this callback to cancel the request. When using `package:http`,

website/docs/how_to/pull_to_refresh.mdx

@@ -103,7 +103,7 @@ Fortunately, when listening to an asynchronous provider in Riverpod,
 Riverpod gives us an `AsyncValue`, which offers everything we need.
 
 That `AsyncValue` can then be combined with Dart 3.0's pattern matching
-as followed:
+as follows:
 
 <AutoSnippet raw={displayActivity4} />
 

website/docs/migration/from_state_notifier.mdx

@@ -29,7 +29,7 @@ were introduced: `Notifier` / `AsyncNotifier`.
 This page shows how to migrate from the deprecated `StateNotifier` to the new APIs.
 
 The main benefit introduced by `AsyncNotifier` is a better `async` support; indeed,
-`AsyncNotifier` can be thought as a `FutureProvider` which can expose ways to be modified from the UI..
+`AsyncNotifier` can be thought as a `FutureProvider` which can expose ways to be modified from the UI.
 
 Furthermore, the new `(Async)Notifier`s:
 

website/docs/root/faq.mdx

@@ -105,7 +105,7 @@ Riverpod would migrate to using `BuildContext` instead of `Ref`.
 This would enable using `StatelessWidget` instead of `ConsumerWidget`.  
 But that's for another time!
 
-## Why doesn't hooks_riverpod exports flutter_hooks?
+## Why doesn't hooks_riverpod export flutter_hooks?
 
 This is to respect good versioning practices.
 

website/docs/whats_new.mdx

@@ -964,7 +964,7 @@ resumed
 ... // And so on every second
 ```
 
-### Exceptions in providers are rethrown as "ProviderException".
+### Exceptions in providers are rethrown as a `ProviderException`.
 
 For the sake of differentiating between "a provider failed" from "a provider is depending on a failed provider",
 Riverpod 3.0 now wraps exceptions in a `ProviderException` that contains the original.