Open mikearnaldi opened 1 month ago
I agree with this 100%. I find the existing Effect.filterMap
API strange anyways.
Seems like there's a matrix of types in/out that can be built:
boolean OUT |
Effect<boolean> OUT |
|
---|---|---|
Array IN |
Array.filter | Effect.filter |
Array<Effect> IN |
Effect.filterMap & ignore result | ? |
and a similar one for filter map
T OUT |
Effect<T> OUT |
|
---|---|---|
Array<T> IN |
Array.filter().map() | Effect.filter > Effect.flatMap |
Array<Effect<T>> IN |
Effect.filterMap | ? |
Wondering if we shouldn't take a different strategy, I currently see a number of issues:
1) filter can't refine unless for simple scenarios where a Refinement can be supported 2) filterMap is verbose and requires mixing values with options 3) filter + filterMap are kind of variants of the same principle and we are duplicating APIs
I have started playing around with the following idea: https://effect.website/play#b7c0272daa18
It looks to me much less verbose and it allows in one shot to both filter/refine and to map
I've placed omit
inside the filter function to reduce the noise but it could very well be exported from the main effect
module and declared in something like Predicate
Filter functions are kind of disaligned between modules and sometimes a bit odd, for example:
I'd expect instead: