-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reinstating *some* of the resultSelectors #5824
Comments
Also worth noting: The secondary function/mapping argument is a little confusing to read, IMO: While we have until v8 to make this decision, I think we should try to decide quickly so we can get our messaging across sooner rather than later. |
I remember that @cartant wanted to discuss some of the deprecations as well, this is probably a good time to do this |
Currently we have deprecated resultSelectors on the following:
The reasons for this were two fold:
Given that I think recently the cost of 1 has gotten to be substantially less, I think we may want to revisit the operators where 2 is not the case (basically anything that isn't a map-and-flatten operator).
I'd propose that we can probably "undeprecate" the resultSelector argument for these creation functions:
This is providing that they are not encumbered by issues 1 and 2 above. (I'm sure that 2 is not an issue, but 1 may or may or may not be true). I think this is especially okay if we're getting rid of "n-args" for sources for
forkJoin
,combineLatest
, and (probably)zip
.The text was updated successfully, but these errors were encountered: