-
Notifications
You must be signed in to change notification settings - Fork 8.2k
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
[Lens] CSV Export for Lens #83430
[Lens] CSV Export for Lens #83430
Conversation
Made the |
Pinging @elastic/kibana-app (Team:KibanaApp) |
@elasticmachine merge upstream |
* | ||
* @returns undefined (download) - Record\<string, string\> (only for testing) | ||
*/ | ||
export function exportAsCSVs( |
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.
lets change this function so it doesn't download the file but just returns csv as a string, this way we can move the function to common and make it usable from server.
the download aspect of it should be moved to some other place (possibly share
plugin) so that can be used for other things as well, as that download function would now just take filename and filecontent in.
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.
You proposing splitting this into two exportCSVs
+ download
plugins?
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.
yes, two functions as converting to csv can be common and downloading can be used for other things beside csv as well.
@elasticmachine merge upstream |
raw?: boolean; | ||
} | ||
|
||
function buildCSV( |
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.
lets rename this one to datatableToCSV
and export it
* | ||
* @returns A dictionary of files to download: the key is the filename and the value the CSV string | ||
*/ | ||
export function exportAsCSVs( |
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 am wondering if this function should be kept inside lens for now. how often will we want to convert multiple datatables at once ? also i am wondering if the reference to filename
here should be omited but rather just use the datatable name ? @lukeelmers whats your opinion ?
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.
Mind that the DataTable
type has no name property. The key:string
passed for the record may be just internal ids (for instance in Lens it represents the layer id).
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.
As we move down the path of creating these various utility functions for datatables, I think it's important to have some consistency in how you interact with them. For any datatable utility function, I'd expect an interface similar to the following:
type SomeFn = (table: Datatable, options?: Record<string, whatever>) => Promise<Something> | Something;
how often will we want to convert multiple datatables at once ?
For the sake of consistency, I would vote to make this function operate on a single table just like our other datatable helpers.
i am wondering if the reference to filename here should be omited but rather just use the datatable name
I think the concept of a filename is only here because the file download functionality was extracted from this function originally. IMHO it would make more sense to remove it and handle it when calling the download helper from the share
plugin.
This would make the interface something like:
exportAsCsv(table: Datatable, options: CSVOptions) => string;
Then Lens would handle calling it multiple times (for multiple tables), assigning a filename, and passing the output to the download helper.
To me this feels like the best way to make these utilities as decoupled as possible, and keeps the lens-specific stuff in lens. (And of course we can always revisit down the road if some of the lens logic is needed for a bunch of other apps)
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.
Tested in Firefox and works well for me. It would be super cool to have a functional test for that but I'm not sure whether that's possible with our current setup.
@@ -27,6 +28,7 @@ export interface Document { | |||
state?: unknown; | |||
}; | |||
filters: PersistableFilter[]; | |||
activeData?: TableInspectorAdapter; |
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.
Seems like this is a leftover
…to feature/lens/csv-export
src/plugins/share/public/index.ts
Outdated
@@ -41,5 +41,6 @@ export { | |||
import { SharePlugin } from './plugin'; | |||
|
|||
export { KibanaURL } from './kibana_url'; | |||
export * from './lib/download_as'; |
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: We prefer to explicitly export named items from the top-level public/index.ts
(instead of using export *
)... that way we avoid accidentally leaking internal items into the public contract later.
* | ||
* @returns A dictionary of files to download: the key is the filename and the value the CSV string | ||
*/ | ||
export function exportAsCSVs( |
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.
As we move down the path of creating these various utility functions for datatables, I think it's important to have some consistency in how you interact with them. For any datatable utility function, I'd expect an interface similar to the following:
type SomeFn = (table: Datatable, options?: Record<string, whatever>) => Promise<Something> | Something;
how often will we want to convert multiple datatables at once ?
For the sake of consistency, I would vote to make this function operate on a single table just like our other datatable helpers.
i am wondering if the reference to filename here should be omited but rather just use the datatable name
I think the concept of a filename is only here because the file download functionality was extracted from this function originally. IMHO it would make more sense to remove it and handle it when calling the download helper from the share
plugin.
This would make the interface something like:
exportAsCsv(table: Datatable, options: CSVOptions) => string;
Then Lens would handle calling it multiple times (for multiple tables), assigning a filename, and passing the output to the download helper.
To me this feels like the best way to make these utilities as decoupled as possible, and keeps the lens-specific stuff in lens. (And of course we can always revisit down the road if some of the lens logic is needed for a bunch of other apps)
* under the License. | ||
*/ | ||
|
||
export * from './export_csv'; |
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.
If we make my proposed changes to exportAsCsv
, then we could move this all to the common
directory. (Maybe common/utils
?) and export it from both public/index.ts
and server/index.ts
src/plugins/data/public/index.ts
Outdated
* Exporters (CSV) | ||
*/ | ||
|
||
export * from './exports'; |
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.
Same comment re: using named exports from top-level public/index.ts
and server/index.ts
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.
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.
code LGTM
@flash1293 added basic functional test :) |
💚 Build SucceededMetrics [docs]Module Count
Async chunks
Distributable file count
Page load bundle
History
To update your PR or re-run it, just comment with: |
Friendly reminder: Looks like this PR hasn’t been backported yet. |
1 similar comment
Friendly reminder: Looks like this PR hasn’t been backported yet. |
Co-authored-by: Kibana Machine <[email protected]> # Conflicts: # src/plugins/data/server/server.api.md
Co-authored-by: Kibana Machine <[email protected]>
Summary
First implementation of the CSV export feature for Lens.
datatableToCsv
functiondata
plugin +download
share pluginonData$
callback and pass theactiveData
to the app, which in turns shows the buttonNote: the embeddable action will be implemented in a subsequent PR.
Fixes part of #74509
Open questions:
filename-N.csv
). In [Lens] CSV export #74509 the suggestion was to use the postfix-Layer N
(=>filename-Layer N.csv
), which is a valid option. Is the- Layer N
postfix the final decision on that? ( Change in later on will be easy )Possible enhancement discussion (out of scope for this PR, but worth discussing):
Checklist
Delete any items that are not applicable to this PR.