Skip to content

Conversation

@colerogers
Copy link
Contributor

@colerogers colerogers commented Jan 19, 2022

Change for the generic interface. Exposes onAlertPublished from the v2/alerts namespace

Ex ~

import { onAlertPublished } from "firebase-functions/v2/alerts"; export const func1 = onAlertPublished("crashlytics.newFatalIssue",(event) => { … }); export const func2 = onAlertPublished( { alertType: "crashlytics.newFatalIssue" }, (event) => { … } ); export const func3 = onAlertPublished( { alertType: "crashlytics.newFatalIssue", appId: "123456789" }, (event) => { … } ); 
@colerogers colerogers changed the title General Interface for FireAlerts Generic Interface for enhanced provider Jan 19, 2022
@colerogers colerogers requested review from inlined and taeold and removed request for inlined January 19, 2022 22:52
@colerogers colerogers changed the title Generic Interface for enhanced provider Generic interface for provider enhancement Jan 20, 2022
Copy link
Contributor

@taeold taeold left a comment

Choose a reason for hiding this comment

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

Couple of suggestions and changes.

| 'appDistribution.newTesterIosDevice'
| string;

/** Options */
Copy link
Contributor

Choose a reason for hiding this comment

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

nit* I found some of these comments kinda unhelpful - e.g. I can tell from the interface name that this is an option. Can we expand on the documentations or get rid of them?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I had those comments to break up the file into sections, but since we don't really do that anywhere else, I've made them a bit more descriptive

}

/** Cloud Event Type */
interface WithAlertTypeAndApp {
Copy link
Contributor

Choose a reason for hiding this comment

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

I think type names should be a noun and not adjectives, so maybe something like AlertEventExt is more appropriate.

(I think the & type intersection encompasses the with you are trying to capture here).

Copy link
Contributor

Choose a reason for hiding this comment

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

I notice that this name was approved in the API proposal. I should've objected then - feel free to ignore.

});
});

describe('defineEndpoint', () => {
Copy link
Contributor

Choose a reason for hiding this comment

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

I kinda liked our way of testing high-level, external API (e.g. onAlertPublished) vs internal helper function like defineEndpoint. So we could just add a test case to check __endpoint prop is approriately set on each external API instead. WDYT?

Copy link
Contributor

@taeold taeold Jan 20, 2022

Choose a reason for hiding this comment

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

I think i now understand the purpose of defineEndpoint - it's meant to be used across all alerts API. This feels fine then. A minor suggestion for renaming to addEndpointAnnotation to make it a little more obvious that calliing this fn has side-effect.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I ended up changing the function to return the endpoint object (from your comment below) and re-named it to getEndpointAnnotation. How do you feel about that?

alertType: string,
appId?: string
): void {
Object.defineProperty(func, '__endpoint', {
Copy link
Contributor

Choose a reason for hiding this comment

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

I don't think this has to be a dynamic property. We did this in storage trigger only because we needed to get bucket from FIREBASE_CONFIG, but that's not the case here. See https.ts for an example of static __endpoint definition!

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Makes sense, changed to static definition

// that __endpoint doesn't exist. We can either cast to any and lose all type safety
// or we can just assign a meaningless value before calling defineProperty.
func.__trigger = 'silence the transpiler';
func.__endpoint = {} as ManifestEndpoint;
Copy link
Contributor

Choose a reason for hiding this comment

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

Would prefer

func.__endpoint = defineEndpoint(...) 

since I think we should shy away from type assertion if it's unnecessary.

Just inlining the function implementation here could also work fine?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Re-named and changed to

func.__endpoint = getEndpointAnnotation(...); 
@colerogers colerogers requested a review from taeold January 24, 2022 21:41
Copy link
Contributor

@taeold taeold left a comment

Choose a reason for hiding this comment

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

lgtm, one minor comment on test

eventFilters: {
alertType,
},
retry: false,
Copy link
Member

Choose a reason for hiding this comment

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

Do we always hard code retry: false? We should be supporting booleans here now that GCF gen 2 supports retry (though I actually have a thread with them about changing this from a boolean to a more featured struct)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Replaced this hard coded value with opts.retry in the latest commit

*/
export function getOptsAndAlertTypeAndApp(
alertTypeOrOpts: AlertType | FirebaseAlertOptions
): [options.EventHandlerOptions, string, string | undefined] {
Copy link
Member

Choose a reason for hiding this comment

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

Returning a tuple is pythonic. Returning an object would have probably been more idiomatic JS. Regardless, this is probably easier to read so LGTM.

colerogers and others added 4 commits January 27, 2022 09:29
* adding in app distro changes * removing comments & addings package refs * jsdoc comments * fix comments * adding periods to doc strings * fix wording
* adding in billing changes * removing comments & adding package refs * jsdoc comments * addressing pr comments * change handler doc string * changing to BillingEventHandler type * remove BillingEventHandler type
* adding in crashlytics changes * comments & adding package refs * address comments and make doc strings better * add opts.retry to event trigger
@colerogers colerogers merged commit 4aa39c4 into colerogers.providers.firealerts Jan 28, 2022
@colerogers colerogers deleted the colerogers.alerts branch January 28, 2022 16:25
colerogers added a commit that referenced this pull request Jan 31, 2022
* breaking out general interface * cleaning up exports * removing comments & references to specific interfaces * format * jsdoc comments * address pr comments * added param comment * addressing comments * Specific interface for provider enhancement (1/3) (#1021) * adding in app distro changes * removing comments & addings package refs * jsdoc comments * fix comments * adding periods to doc strings * fix wording * adding import/export statement * Specific interface for provider enhancement (2/3) (#1022) * adding in billing changes * removing comments & adding package refs * jsdoc comments * addressing pr comments * change handler doc string * changing to BillingEventHandler type * remove BillingEventHandler type * Specific interface for provider enhancement (3/3) (#1023) * adding in crashlytics changes * comments & adding package refs * address comments and make doc strings better * add opts.retry to event trigger
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

3 participants