Skip to content

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

Open
wants to merge 4 commits into
base: main
Choose a base branch
from

Conversation

isabelizimm
Copy link

@isabelizimm isabelizimm commented Jul 15, 2025

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.

flowchart TD
    A["Modal opens"] --> B["Get all potential syntaxes from language pack  with **_get_code_syntaxes_**"] 
    B--> C[Use default syntax]
    C --> D["Translate data view (filters, sorts) to code with **_translate_to_code_**"]
    D --> E[Display code for user to copy]
    E -->|user chooses another syntax from modal dropdown| D
Loading

@isabelizimm isabelizimm requested a review from Copilot July 15, 2025 22:01
Copy link
Contributor

@Copilot Copilot AI left a 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 and get_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!(),
Copy link
Preview

Copilot AI Jul 15, 2025

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.

Suggested change
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.

Copy link
Author

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 😅

@isabelizimm isabelizimm marked this pull request as ready for review July 15, 2025 22:06
@isabelizimm isabelizimm requested a review from jennybc July 15, 2025 22:14
@jennybc
Copy link
Member

jennybc commented Jul 15, 2025

I started with an early review of posit-dev/positron#8536. So I'll let this age a bit, while we converse over there.

isabelizimm added a commit to posit-dev/positron that referenced this pull request Jul 21, 2025
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>
Copy link
Member

@jennybc jennybc left a 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(),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
code_syntax_name: "base r".into(),
code_syntax_name: "base".into(),

code_syntax_name: "base r".into(),
},
CodeSyntaxName {
code_syntax_name: "data table".into(),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
code_syntax_name: "data table".into(),
code_syntax_name: "data.table".into(),

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants