-
Notifications
You must be signed in to change notification settings - Fork 206
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
Generic interface for provider enhancement #1020
Conversation
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.
Couple of suggestions and changes.
src/v2/providers/alerts/alerts.ts
Outdated
| 'appDistribution.newTesterIosDevice' | ||
| string; | ||
|
||
/** Options */ |
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.
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?
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.
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
src/v2/providers/alerts/alerts.ts
Outdated
} | ||
|
||
/** Cloud Event Type */ | ||
interface WithAlertTypeAndApp { |
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.
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).
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.
I notice that this name was approved in the API proposal. I should've objected then - feel free to ignore.
}); | ||
}); | ||
|
||
describe('defineEndpoint', () => { |
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.
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?
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.
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.
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.
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?
src/v2/providers/alerts/alerts.ts
Outdated
alertType: string, | ||
appId?: string | ||
): void { | ||
Object.defineProperty(func, '__endpoint', { |
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.
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!
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.
Makes sense, changed to static definition
src/v2/providers/alerts/alerts.ts
Outdated
// 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; |
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.
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?
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.
Re-named and changed to
func.__endpoint = getEndpointAnnotation(...);
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, one minor comment on test
src/v2/providers/alerts/alerts.ts
Outdated
eventFilters: { | ||
alertType, | ||
}, | ||
retry: false, |
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.
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)
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.
Replaced this hard coded value with opts.retry
in the latest commit
*/ | ||
export function getOptsAndAlertTypeAndApp( | ||
alertTypeOrOpts: AlertType | FirebaseAlertOptions | ||
): [options.EventHandlerOptions, string, string | undefined] { |
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.
Returning a tuple is pythonic. Returning an object would have probably been more idiomatic JS. Regardless, this is probably easier to read so LGTM.
* 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
* 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
Change for the generic interface. Exposes
onAlertPublished
from thev2/alerts
namespaceEx ~