Skip to content

Commit

Permalink
Changed the .debugState paragraph
Browse files Browse the repository at this point in the history
  • Loading branch information
lucavenir committed Sep 8, 2023
1 parent 54e645f commit 8972111
Showing 1 changed file with 21 additions and 7 deletions.
28 changes: 21 additions & 7 deletions website/docs/migration/from_state_notifier.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -187,15 +187,29 @@ Becomes this:
In a nutshell: if you want to listen to a `Notifier`/`AsyncNotifer`, just use `ref.listen`,
[as explained here](/docs/concepts/reading#using-reflisten-to-react-to-a-provider-change).

### From `.debugState`
### From `.debugState` in tests

`StateNotifier` exposed `.debugState`: this property had some use within `state_notifier`,
as it enabled accessing state from outside the class when in development mode, for testing purposes.
`StateNotifier` exposes `.debugState`: this property is used for pkg:state_notifier users to enable
state access from outside the class when in development mode, for testing purposes.

Again, for uniformity reasons, such property is not available in the new APIs.
If you want to interact with `Notifier`/`AsyncNotifier` in a testing environment, you should do
it just like with any other provider: by reading them directly (as opposed of directly instantiating
a `Notifier` by hand).
If you're using `.debugState` to access state in tests, chances are that you need to drop this
approach.

`Notifier` / `AsyncNotifer` don't have a `.debugState`; instead, they expose `.state`, which is
`@visibleForTesting`.

Nonetheless, accessing this property from tests is viable _if and only if_ you had a `Notifier` /
`AsyncNotifer` properly instantied; then, you could access `.state` inside tests freely.

Indeed, `Notifier` / `AsyncNotifier` should _not_ be instantiated by hand: they should instead be
interacted with by using its provider.
Failing to do so will *break* the notifier, due to ref and family args not being initialized.

Don't have a `Notifier` instance? No problem, you can read its provider to obtain one.

If you want to interact with `Notifier`/`AsyncNotifier` in a testing environment, there's a good
chance you should do so just like with any other provider: by reading them directly (as opposed of
directly instantiating a `Notifier` by hand).

The [testing guide](/docs/cookbooks/testing) fully explains how to use `ProviderContainer.read` to do so.

Expand Down

0 comments on commit 8972111

Please sign in to comment.