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
feat(common): allow any Subscribable in async pipe #39627
Conversation
639bee3
to
1a952a8
Compare
This is an interesting idea, but I want to check with the rest of the team before making any decision on whether to go ahead with this. |
Agreed that this seems totally reasonable and straightforward. Because it actually expands the type rather than narrowing it, I believe this is a non-breaking change (triggered presubmit as a sanity check) and I can't think of any good reason not to move forward with it. I suppose there's a question as to why this change is necessary since I can't say I've ever encountered anyone asking for this feature (other than now). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As expected, the presubmit doesn't have any failures related to this change. I'm in favor of moving this forward. As I said before, I can't think of any reason to not allow Subscribable
since it really is already supported as the pipe is implemented; the type just needs to accurately reflect the wider range of supported inputs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This change looks good to me from the API perspective. Thanks
Reviewed-for: public-api
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM for dev-infra
Reviewed-for: dev-infra
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewed-for: public-api
FYI, I've also added the "cleanup" label since there is a merge conflict with the master branch. Feel free to remove it once the conflict is resolved. Thank you.
1a952a8
to
bf34062
Compare
As only methods from the Subscribable interface are currently used in the implementation of the async pipe, it makes sense to make it explicit so that it works successfully with any other implementation instead of only Observable.
bf34062
to
8da7b7e
Compare
@AndrewKushnir @gkalpak @IgorMinar @atscott Thank you for your review 👍 I do not have the ability to remove the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewed-for: public-api
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
As only methods from the Subscribable interface are currently used in the implementation of the async pipe, it makes sense to make it explicit so that it works successfully (regarding type-checking) with any other implementation instead of only Observable.
PR Checklist
Please check if your PR fulfills the following requirements:
PR Type
What kind of change does this PR introduce?
What is the current behavior?
The following component does not compile successfully:
Here is the compilation error:
(cf https://stackblitz.com/edit/angular-ivy-fypzxs?file=src/app/hello.component.ts )
What is the new behavior?
The compilation of the previous component is successful.
Does this PR introduce a breaking change?
Other information
The important part of this PR is about changing the input type from
Observable
toSubscribable
in async pipe.For consistency, I have renamed some local variables to contain
subscribable
instead ofobservable
.In
packages/core/src/util/lang.ts
, I have added theisSubscribable
function that does the same thing asisObservable
but, in case theTODO
mentioned inisObservable
is implemented those two methods would be different.