Remove Refreshing From AsyncState

[mcmah309]

This came as a result of looking into #351 . The idea of having a "refreshing" state and a "reloading" state does not make a lot of sense for signals. The reasoning in the article I previously referenced states that - one is for when the original condition that led to the data/error is the same and the other is for when the condition changes.

Diving into riverpod's source code. I found this reasoning to be more specific to the riverpod implementation - "refreshing" signifies that the refresh was a manual action caused by ref.refresh()/ref.invalidate() (thus original condition not changed). While "reloading" is from a dependency change resulting in the provider being recomputed. In fact, in riverpod there is no ref.reload(), this is only handled by the framework. As a previous user of riverpod I have yet to ever care about
this distinction between the two states.

In signals, we expose .refresh() and .reload() to the end user. Thus, what is the proper distinction between the two for this library? Since we expose .reload() it would seem the reasoning behind the "reloading" state existing in riverpod,
does not exist here. We could probably just remove .refresh() and ..Refreshing state. And have ..Reloading refer do both an internal refresh (dependencies change) and a manual call to .reload(). I'd argue, this is what users care about anyways. This would streamline the API.

I chose removing ..Refreshing over ..Reloading since "reloading" makes sense for the data and error state, while "refreshing" makes less sense for error state in my opinion. But removing ..Reloading instead is also an option.

[rodydavis]

Well I think there are 2 reasons we could keep it:

1. Help with users migrating from Riverpod and the shared abstraction over async state
2. Control in the UI to refresh data without showing the loading indicator.

For 2 this is common in an infinite list where the initial load you show the indicator but not when new data comes in (firestore or sqlite stream) or when appending to the end of the list.

I think we can simplify this more in a future release (v7?) but v6 can be about ease of migration, documentation, examples and cleaning up as much as possible.

[mcmah309]

For 2, the AsyncLoading state would handle the initial load and AsyncDataReloading would handle new data being fetched (note AsyncErrorReloading would also still exist). I don't think an additional AsyncDataRefreshing/AsyncErrorRefreshing state is needed.

Having both, with no functional difference, may be confusing. In some places users might call .refresh() and other .reload(). Meaning for most cases users to have to account for both cases, like -

switch(state) {
    AsyncDataReloading(:final data) || AsyncDataRefreshing(:final data) => ...,
    AsyncData(:final data) => ...,
    AsyncError() => ...,
    AsyncLoading() => ...,
}

Rather than just

switch(state) {
    AsyncDataReloading(:final data) => ...,
    AsyncData(:final data) => ...,
    AsyncError() => ...,
    AsyncLoading() => ...,
}

Definitely going to require a v7, as you mentioned, as this is a breaking change. But the sooner the better in my opinion. It might be worth while if this is the accepted, to deprecate .refresh(), .isRefreshing, AsyncDataRefreshing, and AsyncErrorRefreshing now.

[rodydavis]

Yes I am totally in favor of deprecating to prepare!