Skip to content

Conversation

@mmermerkaya
Copy link
Contributor

No description provided.

complete(): any;
error(error: E): any;
next(value: V | null): any;
interface Observer<T> {
Copy link
Contributor

@jshcrowthe jshcrowthe May 8, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this part of the change is breaking and we just shipped our 5.0.0 release.

You'll need to remove this portion (and other relevant edits).

For context: Users can annotate their TS code w/ firebase.Observer<any, any>. This change breaks that experience.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not a breaking change, it's a bug fix. If they are annotating with any, then they are using wrong types and their application will not work as expected. In the implementation, ErrorFn takes an Error instance as its argument, not any. If they expect it to be any, they're going to have a bad time.

Changed it to a generic with a default value of Error, so at least users can do firebase.observer<any> (and second generic will default to Error) as well as firebase.Observer<any, any>.

Copy link
Contributor

@jshcrowthe jshcrowthe May 8, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Disagree wholeheartedly that annotating with any is "using wrong types" and I can write a fully functional application using only any types throughout my app.

That said, I'm happy w/ the default Error type in the generic. Existing type annotations won't break and you support the single param generic use case which, altogether, is a better place to land.

Thanks!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure you could, but if you tried to call .message on a number or a string, you'd get a runtime error :)

@googlebot
Copy link

So there's good news and bad news.

👍 The good news is that everyone that needs to sign a CLA (the pull request submitter and all commit authors) have done so. Everything is all good there.

😕 The bad news is that it appears that one or more commits were authored or co-authored by someone other than the pull request submitter. We need to confirm that all authors are ok with their commits being contributed to this project. Please have them confirm that here in the pull request.

Note to project maintainer: This is a terminal state, meaning the cla/google commit status will not change from this state. It's up to you to confirm consent of the commit author(s) and merge this pull request when appropriate.

@mmermerkaya mmermerkaya force-pushed the mmermerkaya-observer-messaging-types branch from 90a071a to 8f57b8d Compare May 8, 2018 18:52
@googlebot
Copy link

CLAs look good, thanks!

@jshcrowthe jshcrowthe merged commit b351749 into master May 8, 2018
@jshcrowthe jshcrowthe deleted the mmermerkaya-observer-messaging-types branch May 8, 2018 18:52
@firebase firebase locked and limited conversation to collaborators Oct 20, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants