[Streams] Support closed field/getter and cancelOnError config

[manuel-plavsic]

I suggest adding:

• an optional bool? cancelOnError param when creating the resource (only if it is a stream)
• a bool closed field to the resource states of a stream. This way it is possible to adapt what is displayed in the build method.
  • I'm not entirely certain whether adding a closed argument to the callbacks below would make them overly verbose.

  R on<R>({
    required R Function(
      T data,
      bool refreshing,
      bool closed,
    ) ready,
    required R Function(
      Object error,
      StackTrace? stackTrace,
      bool refreshing,
      bool closed,
    ) error,
    required R Function(bool closed) loading,
  }) {
    return map(
      ready: (r) => ready(r.value, r.refreshing, r.closed),
      error: (e) => error(e.error, e.stackTrace, e.refreshing, e.closed),
      loading: (l) => loading(l.closed),
    );
  }

  • Or maybe it is enough to just add a isClosed or closed getter, such as resource.isClosed (thus no extra arg to the callbacks)?

How would you implement this? Maybe we should have two separate resource classes, one for streams and the other one for futures? Note: A while ago I attempted this by splitting Resource into two classes: Resource and StreamResource. However, it resulted in some duplicated code.

More in general, what is your opinion about supporting cancelOnError and cancel?

[nank1ro]

I don't understand the utility of having the cancelOnError field if the purpose of the resource is just to wrap the state of the asynchronous value.
The asynchronous value must be able to change state, so go from error to ready without any problems.
This would no longer happen if cancelOnError is set to true.

The use case you describe doesn't seem quite in line with the functionality that a resource provides.

In addition, this also applies to the stream when it goes into the done state.
If the stream has been closed, the resource consequently will no longer output values.
If you want to restart it, dispose the resource and recreate it with a new active stream.

What is the use case where you need to show something different when the stream has been closed?
I can't think of anything

[manuel-plavsic]

Your point about cancelOnError makes sense.

Regarding closed/done, simple refreshable widgets might not need it. However, more complex situations might require it. Imagine a screen where bets can be placed. At some point the stream enters the done state, meaning it should no longer be possible to place bets. Do you see this like a plausible scenario, or should an error event be emitted instead?

[nank1ro]

Can you provide an example code of what you mean?

[manuel-plavsic]

I typically don't use streams. I opened this discussion because I noticed not all stream aspects are supported by Solidart, and my example was hypothetical. While I could provide a code snippet, it is unlikely to accurately reflect real-world usage. I think it is better to have this discussion again if someone really hits this limitation.

[nank1ro]

If there was such a complex use-case, it would be enough to continue using the stream directly.
The resource is to handle the most common case, it does not go to replace the stream as a whole.