-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
Route tags #37344
Route tags #37344
Conversation
src/core/server/http/router/route.ts
Outdated
authRequired?: boolean; | ||
|
||
/** | ||
* Additional meta-data information to attach fot the route. |
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.
typo: fot --> to
ACK: will take a look on Friday or Monday at the latest. |
💔 Build Failed |
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.
Approach looks good to me, but can you please add a usage example into PR description? Just to have a better idea how it's going to be used.
src/core/server/http/router/route.ts
Outdated
/** | ||
* Additional meta-data information to attach fot the route. | ||
*/ | ||
tags?: string[]; |
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.
question: do you think using ReadonlySet<string>
would introduce too much unnecessary friction? I usually prefer Map
and Set
where uniqueness is implied unless it really reduces API ergonomics.
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 using Set could be error-prone because strings are iterable in js
new Set('my:tag') // wrong declaration, don't throw
new Set(['my:tag']) // correct declaration, but not intuitive
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.
Yeah, it's arguable and may not be the best choice in some cases, don't have a strong opinion on that, feel free to pick whatever you think is better.
P.S. We decided to move with Set
for a similar thing in EcnrytpedSavedObjects
to signify uniqueness of the setting. It's not super important, just slowly transforming my coding habits towards string[] ---> Set<string>
and Record<string, string> ---> Map<string, string>
where appropriate 🙂
import { Request, ResponseToolkit } from 'hapi'; | ||
import { merge } from 'lodash'; | ||
|
||
type DeepPartial<T> = T extends any[] |
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.
@elastic/kibana-platform would be useful to declare some type helpers on project level or add a ready toolkit.
💔 Build Failed |
Pinging @elastic/kibana-platform |
Pinging @elastic/kibana-security |
💔 Build Failed |
retest |
💚 Build Succeeded |
Do we feel that sticking to the way that "tags" are implemented currently and replicating them in the new platform is strategically advantageous? At the time the I don't want to completely derail this effort though, if the legacy and new platform's interaction makes using the same approach across both strategically advantageous in the short-term. |
retest |
💔 Build Failed |
@elastic/kibana-platform could someone review, please? @eliperelman is on vacation |
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.
Looks good. I made a docs language suggestion, but if you accept it you'll need to re-generate the docs.
@skaapgif ok, then I will update wording manually. thanks ❤️ |
💚 Build Succeeded |
* expose route info in KibanaRequest * update mocks in test * make tags readonly, getRouteInfo is private method * add mocks for hapi internals * mode deepFreeze to core utils level as it env agnostic * freeze route props * fix typo * add tests for route options * fix integration tests. deep_freeze was moved under core utils * add comments, expose public types and regenerate docs * address comment. remove unnecessary async in route handlers * make routeSchema optional instead of union with undefined * @skaapgif improvements * update docs
* expose route info in KibanaRequest * update mocks in test * make tags readonly, getRouteInfo is private method * add mocks for hapi internals * mode deepFreeze to core utils level as it env agnostic * freeze route props * fix typo * add tests for route options * fix integration tests. deep_freeze was moved under core utils * add comments, expose public types and regenerate docs * address comment. remove unnecessary async in route handlers * make routeSchema optional instead of union with undefined * @skaapgif improvements * update docs
Summary
Related discussion that may require changing the whole approach to authorization: #38009
2 main changes
KibanaRequest
exposes route configthere are tons of changes in docs after I merged master and run
yarn core:acceptApiChanges
. looks like the reason for this is@microsoft/api-documenter
update #37759Probably it's easier to review commit by commit
Checklist
Use
strikethroughsto remove checklist items you don't feel are applicable to this PR.[ ] This was checked for cross-browser compatibility, including a check against IE11[ ] Any text added follows EUI's writing guidelines, uses sentence case text and includes i18n support[ ] Documentation was added for features that require explanation or tutorials[ ] This was checked for keyboard-only and screenreader accessibilityFor maintainers