-
Notifications
You must be signed in to change notification settings - Fork 17
data explorer: update comms with copy to code messages #873
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
base: main
Are you sure you want to change the base?
Conversation
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.
Pull Request Overview
This PR extends the data explorer communication layer to support exporting the current view as code and retrieving available code syntaxes, and stubs out the corresponding backend handlers.
- Added new comm structs and enum variants for
translate_to_code
andget_code_syntaxes
- Introduced unimplemented match arms in the RDataExplorer backend for handling the new requests
Reviewed Changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
File | Description |
---|---|
crates/ark/src/data_explorer/r_data_explorer.rs | Added match arm stubs for TranslateToCode and GetCodeSyntaxes requests in backend dispatch |
crates/amalthea/src/comm/data_explorer_comm.rs | Defined ExportedCode , CodeSyntaxOptions , TranslateToCodeParams , and updated request/reply enums |
Comments suppressed due to low confidence (1)
crates/amalthea/src/comm/data_explorer_comm.rs:1090
- Add unit tests for the new TranslateToCode and GetCodeSyntaxes communication messages to verify serialization, deserialization, and correct request/reply handling.
/// Parameters for the TranslateToCode method.
@@ -556,6 +556,7 @@ impl RDataExplorer { | |||
format, | |||
}, | |||
)), | |||
DataExplorerBackendRequest::TranslateToCode(_) | DataExplorerBackendRequest::GetCodeSyntaxes => todo!(), |
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.
Avoid using todo!() for unimplemented request handlers; implement the TranslateToCode and GetCodeSyntaxes logic to translate filters into code and retrieve available syntaxes, returning the appropriate reply variants instead of panicking.
DataExplorerBackendRequest::TranslateToCode(_) | DataExplorerBackendRequest::GetCodeSyntaxes => todo!(), | |
DataExplorerBackendRequest::TranslateToCode(filters) => { | |
let translated_code = self.translate_filters_to_code(filters)?; | |
Ok(DataExplorerBackendReply::TranslateToCodeReply(translated_code)) | |
}, | |
DataExplorerBackendRequest::GetCodeSyntaxes => { | |
let syntaxes = self.get_available_code_syntaxes()?; | |
Ok(DataExplorerBackendReply::GetCodeSyntaxesReply(syntaxes)) | |
}, |
Copilot uses AI. Check for mistakes.
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.
Due to my unfamiliarity with Rust, I'm honestly not sure if this will break if those methods don't exist 😅
I started with an early review of posit-dev/positron#8536. So I'll let this age a bit, while we converse over there. |
related issue: #8531 related pr for Ark: posit-dev/ark#873 I'm not exactly sure of the flow of these PRs with Ark, but I believe we'll want to merge that PR, release Ark, and then pick up the new release in this PR before this PR is merged. This PR implements makes 3 major changes to the comms: - **add `convert_to_code` as a supported feature:** there are other supported features, such as row filters and column filters. This structure includes if it is supported as well as supported syntaxes, as an array of values. - **`suggest_code_syntax` message:** for a particular data explorer instance, decide what options a user has for generating code. I would expect the return value of this to be `base-r` or something to that effect. - **`convert_to_code` message:** for a particular data explorer instance, this message sends over the filters and sorts applied to the data and the desired syntax. The expectation is that this will return a code snippet string. The front end will (eventually) apply code highlighting and formatting. Below is a diagram of the general flow through comms. Note that these comm messages will not call each other; they will be triggered by a modal in Positron core. ```mermaid flowchart TD A["Data explorer instance is created"] --> B["Get all potential syntaxes from language pack via the **supported_features**." ] B --> C["Also set suggested syntax with **suggest_code_syntax**"] C --> D[Open modal] D --> E["Use **dataExplorerInstance.suggestedSyntax**"] E --> F["Translate data view (filters, sorts) to code with **_translate_to_code_**"] F --> G[Display code for user to copy] G -->|user chooses another syntax from modal dropdown| F ``` There is an open PR that builds off this branch to use these comms, so you can actually fire them off/interact with them #8537 ### Release Notes <!-- Optionally, replace `N/A` with text to be included in the next release notes. The `N/A` bullets are ignored. If you refer to one or more Positron issues, these issues are used to collect information about the feature or bugfix, such as the relevant language pack as determined by Github labels of type `lang: `. The note will automatically be tagged with the language. These notes are typically filled by the Positron team. If you are an external contributor, you may ignore this section. --> #### New Features - N/A #### Bug Fixes - N/A ### QA Notes It doesn't look like we have much testing for comms, but open to ideas! Currently I plan on adding unit tests on each language runtime and then e2e tests for the UI pieces. --------- Signed-off-by: Isabel Zimmerman <54685329+isabelizimm@users.noreply.github.com> Co-authored-by: Jennifer (Jenny) Bryan <jenny.f.bryan@gmail.com>
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 far as a stub goes, LGTM.
Will you make sure that the main PR description gets any updates to reflect what actually went in? That might already be the case, this is just a reminder to double check. We went through a lot of renaming and reframing on the comms.
support_status: SupportStatus::Supported, | ||
code_syntaxes: Some(vec![ | ||
CodeSyntaxName { | ||
code_syntax_name: "base r".into(), |
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_syntax_name: "base r".into(), | |
code_syntax_name: "base".into(), |
code_syntax_name: "base r".into(), | ||
}, | ||
CodeSyntaxName { | ||
code_syntax_name: "data table".into(), |
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_syntax_name: "data table".into(), | |
code_syntax_name: "data.table".into(), |
related to: posit-dev/positron#8531
This PR implements 2 comm message types:
get_code_syntaxes
: for a particular data explorer instance, decide what options a user has for generating code. I would expect the return value of this to be['base-r', 'dplyr']
or something to that effect. The first item in the array will be the default, which means it will be the first option in the modal and what users will see generated code for without making a different selection.translate_to_code
: for a particular data explorer instance, this message sends over the filters and sorts applied to the data and the desired syntax. The expectation is that this will return a code snippet string. The front end will (eventually) apply code highlighting, but the formatting responsibility is TBD.Below is a diagram of the general flow through comms. Note that these comm messages will not call each other; they will be triggered by a modal in Positron core.