-
Notifications
You must be signed in to change notification settings - Fork 373
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
Support SSRC conditions #2487
Support SSRC conditions #2487
Conversation
bab6beb
to
44591cd
Compare
6eb36de
to
4e6a1c9
Compare
*/ | ||
export interface RemoteConfigServerCondition { | ||
export interface RemoteConfigServerNamedCondition { |
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.
@lahirumaramba I see some interfaces with the RemoteConfig prefix and others without. Is there a guideline for what needs the prefix?
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 can't recall a reason. Looking at this proposal (go/admin-sdk-remote-config) from 2020 it looks like the types that were added later are missing the prefix.... maybe we weren't strict about the prefix in follow up proposals?
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 was just reviewing a change for the REST API and I think what happened is the TS API naming biased toward the REST API. The REST API has nested protos, but TS interfaces can't be nested. The parent protos had more qualified names than the child protos. When we created interfaces to match the protos, we retained the existing names.
I think the guideline we discussed against product prefixes still holds and will help the TS API be more consistent.
Double scratch that. I see |
Lahiru and I discussed offline. For future ref, he suggested deleting and regenerating package-lock.json, which fixed the issue. |
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.
Thanks! LGTM!
Add support for condition evaluation.
Note this is based on #2496.
Discussion
Working with @lahirumaramba and @trekforever.
Testing
Ran npm test and all tests pass.
Functionally tested using a local server.