The behavior I'd like to get from VHook

Discard need to make every awaitable hook optional

Also a default value is not always possible or makes sense. I'd suggest to use late and have a _hasValue flag present.
I recognize that an optional default parameter could be tricky when the default value of null is really required. The question is if no value wouldn't carry the same information. Open for discussion.

// VHook([T? default])
final hook = VHook<int>();

Completer like API including method to fail with an error

Would be more convenient for new devs as well. The completeError method would add value to VHook

// void complete(T value)
hook.complete(0);

// void completeError(Exception exception) | or dynamic exception?
hook.completeError('Unfortunately 0 is not a number today. Try again tomorrow.');

Method to set / modify the value without completing

Sometimes the value is important to really call the hook completed. Like when tracking active connections or any other counter.

// T update(T Function(T?));
hook.update((int? current) => current + 1 ?? 0);

// Future<T> updateAsync(Future<T> Function(T?));
hook.updateAsync((int? current) async => current + 1 ?? 0);

// void updateValue(T);
hook.updateValue(1);

// void finish();
// Completes the hook with the last value and skips possible handlers.
hook.finish();

Method to await based on content

If no value handler is provided the future completes when the first value arrives from any update method. The complete method would skip the handler at all.

The method should always throw on timeout. Maybe the timeout should be optional?
The return value is the value is a future of the value on which it completed.

// Future<T> awaitValue(Duration timeout, [bool Function(T)? handler]);
hook.awaitValue(Duration(eternities: 66), (int value) => value > 2);

Combined expect and await method

This method could be used instead of awaitValue to instantly apply a matcher on completion.

// Future<T> expectAsync(Duration timeout, [Matcher? matcher]);
hook.expectAsync(Duration(eternities: 66), equals(3));

from flyde.

'Basic' refactor with commit 9c8ae6d

• No requirement for values (no requirement for null nor optionals)
• Set value without completing (primitive set(T val), updaters will be added soon)
• Await based on content (own conditions)
• Complete value
• Await completion

The other requested features will follow soon. I will also try to update all existing tests to the new VHook.

from flyde.

Added updaters with 73cbb4a

from flyde.

Added error handling with aac46d3

Im not sure about the behaviour of awaitValue though:
If we already completed with an error and awaitValue is called, should we return the Future that contains the error or simply throw the error?

I would like to throw as this comes closes to the behaviour when we complete with an Error while awaiting a value through:

Future<T> awaitValue({Duration? timeout, bool Function(T)? condition}) async {
    // ...

    // Throw if already completed with error
    _assertNotCompletedError();                                         // <---------- BUT SHOULD WE?

    // ...

    // Subscribe to changes and find first that satisfies [condition]
    Future<dynamic> value = _stream.stream.firstWhere(wrappedCond);     // <---------- THIS WILL THROW ON ERROR!

    // ...
  }

from flyde.

Added simpler matching with 0e05c59 and 2e9c07c

from flyde.

Added error handling with aac46d3

Im not sure about the behaviour of awaitValue though:
If we already completed with an error and awaitValue is called, should we return the Future that contains the error or simply throw the error?

I would like to throw as this comes closes to the behaviour when we complete with an Error while awaiting a value through:

Future<T> awaitValue({Duration? timeout, bool Function(T)? condition}) async {
    // ...

    // Throw if already completed with error
    _assertNotCompletedError();                                         // <---------- BUT SHOULD WE?

    // ...

    // Subscribe to changes and find first that satisfies [condition]
    Future<dynamic> value = _stream.stream.firstWhere(wrappedCond);     // <---------- THIS WILL THROW ON ERROR!

    // ...
  }

Maybe I don't fully understand your question, but there is no difference between returning a future which completes with an error or throwing an error in an async function. Both returns a future which rejects. If I understood your code correctly _asssertNoError throws if the Completer object was called with completeError and _stream is called with addError. So both should throw the same error object, shouldn't they? The only difference would be possible side effect between those calls, otherwise the behavior would be the same.

from flyde.

You are totally right, I was just wondering what would be nicer here. But we'll just stick to throwing.

from flyde.