[APM] Migrate to Typescript and refactor backend apis #25848
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
sorenlouv
force-pushed
the
refactor-backend-apis
branch
from
1426102 to
9dbf5e4
Compare
💔 Build Failed |
sorenlouv
force-pushed
the
refactor-backend-apis
branch
from
9dbf5e4 to
e0d48a2
Compare
💔 Build Failed |
sorenlouv
force-pushed
the
refactor-backend-apis
branch
4 times, most recently
from
c7e57e8 to
65ec5b4
Compare
💚 Build Succeeded |
|
retest |
💔 Build Failed |
💚 Build Succeeded |
jasonrhodes
reviewed
Nov 20, 2018
There was a problem hiding this comment.
- For the API response types, do you want to stick with the
Iprefix? - I like the fetch/transform abstractions, on the fence about whether to pull fetch stuff into the index files or not. If we keep them separate, can we either have fetch/transform or fetcher/transformer for the file names? (I think I prefer fetch/transform but either way.)
Otherwise I think this LGTM
jasonrhodes
approved these changes
Nov 21, 2018
sorenlouv
force-pushed
the
refactor-backend-apis
branch
from
4e776ba to
96abdae
Compare
💔 Build Failed |
💔 Build Failed |
# Conflicts: # x-pack/plugins/apm/public/services/rest/apm.ts # x-pack/plugins/apm/server/lib/services/get_services.ts
sorenlouv
force-pushed
the
refactor-backend-apis
branch
from
bacaae4 to
2884ebe
Compare
💔 Build Failed |
|
retest |
💚 Build Succeeded |
This was referenced Nov 23, 2018
sorenlouv
added a commit
that referenced
this pull request
Nov 27, 2018
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Extends the work done in #25514
Prefer
unknownoveranyForce explicit return type when using "blackbox" clients
"Blackbox clients" is a term I used about clients where the return type cannot possibly be inferred in compile time. This is the case with the http client, ES client and config manager, that all currently have
anyas return type. This means that the user is able to access properties and methods that might or might not exists, without any warnings. Example with the ES client:To highlight this issue I've made all clients generic, so they accept a return type. The default return type is
void:Types for chart
Both the backend and frontend code the charts was in js and has been migrated to ts