-
Notifications
You must be signed in to change notification settings - Fork 108
data explorer: "Copy as Code" comms #8536
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
Changes from 12 commits
02a2c28
dc9ef57
6f502e0
dcf380b
32eb2c0
f9a2c01
2b9f962
5083889
5be588b
d59fd66
cc2d069
bae6ced
4d624bc
ac12c66
0d6e7d9
c33df7c
45cd402
1adfc02
7a0d40b
9cbe02a
51893f0
9517202
36bf5f5
da70e52
b6bbe5c
ccd15c4
0cc6f14
0c0ffac
a85ef9f
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -215,6 +215,98 @@ | |
} | ||
} | ||
}, | ||
{ | ||
"name": "translate_to_code", | ||
"summary": "Translates the current data view into a code snippet.", | ||
"description": "Translate filters and sort keys as code in different syntaxes like pandas, polars, data.table, dplyr", | ||
"params": [ | ||
{ | ||
"name": "column_filters", | ||
"description": "Zero or more column filters to apply", | ||
"required": true, | ||
"schema": { | ||
"type": "array", | ||
"items": { | ||
"$ref": "#/components/schemas/column_filter" | ||
} | ||
} | ||
}, | ||
{ | ||
"name": "row_filters", | ||
"description": "Zero or more row filters to apply", | ||
"required": true, | ||
"schema": { | ||
"type": "array", | ||
"items": { | ||
"$ref": "#/components/schemas/row_filter" | ||
} | ||
} | ||
}, | ||
{ | ||
"name": "sort_keys", | ||
"description": "Zero or more sort keys to apply", | ||
"required": true, | ||
"schema": { | ||
"type": "array", | ||
"items": { | ||
"$ref": "#/components/schemas/column_sort_key" | ||
} | ||
} | ||
}, | ||
{ | ||
"name": "code_syntax", | ||
"description": "The code syntax to use for translation", | ||
"required": true, | ||
"schema": { | ||
"type": "string", | ||
"items": { | ||
"$ref": "#/components/schemas/code_syntax" | ||
} | ||
} | ||
} | ||
], | ||
"result": { | ||
"schema": { | ||
"name": "exported_code", | ||
"type": "object", | ||
"description": "Resulting code", | ||
"required": [ | ||
"code" | ||
isabelizimm marked this conversation as resolved.
Show resolved
Hide resolved
|
||
], | ||
"properties": { | ||
"data": { | ||
"type": "string", | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. How sure are we that we want a string? As opposed to an array of strings, i.e. one per line. I can't say exactly if/why this matters, but somehow sending lines of code back to the front end feels more proper than a single collapsed string. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Oh, I like this idea! It does feel more proper, somehow. An array would probably be easier for formatting anyway; I'll move over to this structure. 👍 |
||
"description": "Exported code as a string suitable for copy and paste" | ||
} | ||
} | ||
} | ||
} | ||
}, | ||
{ | ||
"name": "get_code_syntaxes", | ||
"summary": "Get code syntaxes supported for code translation", | ||
"description": "Get all available code syntaxes supported for translation for a data view", | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I feel like there's some notion that the backend is expected to reply using knowledge of the type of data being viewed. In the R world, i.e. that the backend will know the class(es) of the object, in this sense: class(palmerpenguins::penguins)
#> [1] "tbl_df" "tbl" "data.frame" which would effect which syntaxes are supported or which syntax is the default. I don't see this information being sent over. Does the backend obtain that info another way? I do understand that the object in question must already exist in the runtime and, therefore, the backend already knows (or can know) this. And I even have some sense that all of this is unfolding inside a data explorer instance and therefore the target data object is implicitly available. I just don't understand the information flow yet. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The table lives on the |
||
"params": [], | ||
"result": { | ||
"schema": { | ||
"name": "code_syntax_options", | ||
"type": "object", | ||
"description": "Code syntaxes available for export", | ||
"required": [ | ||
"code_syntaxes" | ||
isabelizimm marked this conversation as resolved.
Show resolved
Hide resolved
|
||
], | ||
"properties": { | ||
"code_syntaxes": { | ||
"type": "array", | ||
"description": "Available code syntaxes supported for export", | ||
"items": { | ||
"type": "string" | ||
} | ||
} | ||
} | ||
} | ||
} | ||
}, | ||
{ | ||
"name": "set_column_filters", | ||
"summary": "Set column filters to select subset of table columns", | ||
|
@@ -1293,6 +1385,10 @@ | |
} | ||
} | ||
}, | ||
"code_syntax": { | ||
"type": "string", | ||
"description": "The syntax for translated code" | ||
}, | ||
"supported_features": { | ||
"type": "object", | ||
"description": "For each field, returns flags indicating supported features", | ||
|
@@ -1302,7 +1398,8 @@ | |
"set_row_filters", | ||
"get_column_profiles", | ||
"set_sort_columns", | ||
"export_data_selection" | ||
"export_data_selection", | ||
"export_as_code" | ||
], | ||
"properties": { | ||
"search_schema": { | ||
|
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 "translate" is not a great verb here, because it could have so many meanings. Translate from English to another language? Translate from R to Python? I realize there's a lot of context to help someone clarify this, but I suspect it would be even better to use a different verb.
For example, I think "convert" or "generate" are better.
This choice obviously affects a lot of locations (every instance of "translate", "translation", "translated", etc.), so I won't repeat the comment elsewhere.
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 had started with generate and moved away from it since I felt it was too AI-y, but I'm on board with
convert
instead 💯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 hear you re: "generate" and "AI-y" in terms of the UI. But internally, I think "generate" is a very viable option. I'm thinking about how nice "generated code" feels versus "converted code".
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.
In any case, both "generate" and "convert" might be handy for actual names and then also for docstrings.