SignalOptions

[Solido]

Experiment with a API alternative to covers specific behaviours
Here keeping track of reflections.

enum Emit {
  identity,
  once,
  always
}

SignalOptions<T> {
  T initialValue, // stream<T> not <T?>
  int bufferSize, // Previous values buffer
  Emit emission, // if false emit even if ==
  [String name], // entry debugLabel
  bool immutable, // immutable data aka ReadOnly
}

[rodydavis]

That is a good point, I think right now we would only require initialValue since it will pass the type inference to the async signal.

[Solido]

As a idea for #65

We may have a case where you may not cover all the requirements for every users expectations.
Thinking about a SignalOption object to configure.

InitialValue is the way to configure the type of the stream and deal with Dart expectation,
if no initial value are provided but a loading state emit then it's type has to be T?, providing initial T would lead to Signal.

Maybe we can see if an SignalOption<String> ( {loading: false, (not T) initialValue: null}) is the most elegant way to solve that.

[rodydavis]

Could you provide some code examples?

The type would have to be T? right because of no value being set yet.

You can always use the requireValue though to unwrap if you know there is a value

[Solido]

Hi Rody, do not worry those are just my note.
I started this Option because I was unhappy when I added initialValue to the first StreamSignal.
At the end of the road we'll have too much parameters and I'm thinking about having something more streamlined but I dot not have definitive ideas. This is strongly linked to the 'named signals' tickets as those parameters can land in options too but still acceptable to have it in third position.

StreamInterface(interface parameters, [optional signals options], [optional named/descriptions])