Define and export type SearchResponse
See original GitHub issue🚀 Feature Proposal
Export the generic types defined in https://www.elastic.co/guide/en/elasticsearch/client/javascript-api/current/typescript.html (specially the SearchResponse<T>
)
Motivation
This way people won’t have to reimplement these types every time.
Example
The exact same documentation example, but we would only have to define the Source
type.
Issue Analytics
- State:
- Created 4 years ago
- Reactions:11
- Comments:17 (12 by maintainers)
Top Results From Across the Web
What is `export type` in Typescript? - javascript - Stack Overflow
This is a type alias - it's used to give another name to a type. In your example, feline will be the type...
Read more >Documentation - TypeScript 3.8
TypeScript 3.8 adds a new syntax for type-only imports and exports. ... in order to use await , and then immediately called the...
Read more >TypeScript support | Elasticsearch JavaScript Client [8.5] | Elastic
The client offers a first-class support for TypeScript, shipping a complete set of type definitions of Elasticsearch's API surface.
Read more >Test Script - /FHIR4-0-1-BulkData/02-BulkData-Export ... - Touchstone
This test ensures the $export operation is defined, the server is responding ... Touchstone will send a request for 4 Patients and 6...
Read more >Composing Workflows | Guide | @esri/hub.js - Esri GitHub
export type PipelineFn<T> = (value: IPipeable<T>) => Promise<IPipeable<T>>;. Working from the previous example, we could define an ITemplate as
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
I think that until we have a real API spec from Elasticsearch that defines the full typings so we can generate all types, developers in the wild are going to end up writing types by hand anyways. I know in the case of Kibana, we will definitely want to fill in the gaps of what’s missing.
So then the question becomes, why duplicate all this work in each project rather than having them done in one place? By having handwritten types in this package, all projects can benefit from more complete typings, even if they’re not 100% perfect. I think we’re much more likely to get it right if done here then if done in each downstream project that consumes this library.
In terms of where these types should live, I personally prefer they live in this module rather than in
@types/elasticsearch
. Primary benefit being that it’s much more obvious if the full types ship with the library than if they’re in some auxiliary package.If that’s the direction we go, I think we should also look into having
@types/elasticsearch
removed or at least marked as deprecated in some way.Hello! Thank you @joshdover for the summary! I’ve just opened #1119, which should vastly improve the developer experience with TypeScript and help the future work that will start from this issue. A review would be highly appreciated!