You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It's come up more than once in recent days where I've run across code or confused developers that didn't know where an EmptyError was originating from.
Basically one of the problems is this:
source$.pipe(/* ... operators ... */first(somePredicate),/* ... operators ... */first(somePredicate),/* ... operators ... */catchError(err=>{if(errinstanceofEmptyError){// who did this?}}))
Current Workarounds
You can always leverage the defaultValue argument, but if you want to use the error channel, you'd have to do something like this catching and rethrowing right after:
Neither of the above are great. Sadly, the best solution to this will require a breaking change we can't really deprecate cleanly (but we can deprecate in a dirty way):
The problem with this solution is the second argument is currently the defaultValue, has a similar use case. We could examine the default value like typeof defaultValue === 'object' && 'emptyError' in defaultValue and it would probably be fine in 99.999999% of cases, but it's not bulletproof. That object would also have to support a defaultValue property, so we'd need to check for that too. For at least a whole major release.
Proposed Solution 2: Function
In this one we would examine the second argument, and if it's a function, we'd call it to get the default value. If it throws it emits the error (obviously).
The problem here is I think collisions with existing code and regressions are more likely than the other one. It's also not as readable.
Proposed Solution 3: Combination of the above
In this one we have a configuration/options object with a defaultValue, valueNotFound, onEmpty, or getDefault (bike sheddable) property on it that would have a function that works as solution 2 above does.
It's come up more than once in recent days where I've run across code or confused developers that didn't know where an
EmptyError
was originating from.Basically one of the problems is this:
Current Workarounds
You can always leverage the
defaultValue
argument, but if you want to use the error channel, you'd have to do something like this catching and rethrowing right after:This can of course be made into something reusable something like so:
Perhaps a better workaround for some people is
filter
,take
andthrowIfEmpty
:Proposed Solution 1: Configuration
Neither of the above are great. Sadly, the best solution to this will require a breaking change we can't really deprecate cleanly (but we can deprecate in a dirty way):
The problem with this solution is the second argument is currently the
defaultValue
, has a similar use case. We could examine the default value liketypeof defaultValue === 'object' && 'emptyError' in defaultValue
and it would probably be fine in 99.999999% of cases, but it's not bulletproof. That object would also have to support adefaultValue
property, so we'd need to check for that too. For at least a whole major release.Proposed Solution 2: Function
In this one we would examine the second argument, and if it's a function, we'd call it to get the default value. If it throws it emits the error (obviously).
The problem here is I think collisions with existing code and regressions are more likely than the other one. It's also not as readable.
Proposed Solution 3: Combination of the above
In this one we have a configuration/options object with a
defaultValue
,valueNotFound
,onEmpty
, orgetDefault
(bike sheddable) property on it that would have a function that works as solution 2 above does.The text was updated successfully, but these errors were encountered: