Open sugarmanz opened 7 months ago
re. return value, you can still support all hook types but at the call site, only process the taps that qualify?
Also would you consider something like tapIsInstance
?
only process the taps that qualify?
Conceptually, yes - but we'd need to tap
to process the hook value for filter
or map
or w/e. So, for instance, if I try to filter on waterfall hook value, if it doesn't match the filter, I'd need to return the incoming value from the filter
method.
tapIsInstance
I don't really see why not, but the idea is to mirror collection or flow-like APIs that already exist. Collapsing a few into a singular tap
convenience would definitely be in scope.
Is your feature request related to a problem? Please describe.
When tapping a hook that provides an abstract data type, we may only care about a specific implementation. A simple early return allows us to "filter" out types we don't care about:
Describe the solution you'd like
It'd be awesome to have functional methods for hooks, such that we can patternize filtering, data manipulation, etc.
Describe alternatives you've considered
Tapping can effectively be thought of as collecting. Maybe it's worth adopting similar terminology? Probably not. Maybe a conversion layer to
Flow
s would solve better than trying to coerce hooks as aFlow
-like data type.Additional context
This is somewhat difficult to consider for the more complex hook types, since return value is more important. We'd want to ensure we have appropriate handling for each hook type, or not support certain hook types at all.