Skip to content
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

Generic interface for provider enhancement #1020

Merged
merged 12 commits into from
Jan 28, 2022

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.

spec/v2/providers/alerts/alerts.spec.ts Outdated Show resolved Hide resolved
spec/v2/providers/helpers.ts Outdated Show resolved Hide resolved
src/v2/core.ts Outdated Show resolved Hide resolved
src/v2/providers/alerts/alerts.ts Outdated Show resolved Hide resolved
| '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.

src/v2/providers/alerts/alerts.ts Outdated Show resolved Hide resolved
});
});

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

spec/v2/providers/alerts/alerts.spec.ts Outdated Show resolved Hide resolved
src/v2/providers/alerts/alerts.ts Outdated Show resolved Hide resolved
src/v2/providers/alerts/alerts.ts Outdated Show resolved Hide resolved
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
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants