Explore a standalone, dependency-free R package for the Data Viewer backend
維護者通常 1 天內回覆
@eitsupi 已經在處理了。
開始於 2026年10月13日。
評估
- 難度
- 5/5
- 預估耗時
- 一週以上
- 新手友好度
- 35/100
- Issue 類型
- 功能
- 描述清晰度
- 基本清楚
- 活躍度
- 活躍
研究方向
Start by examining the Data Viewer backend currently implemented inside sess and compare its metadata, paging, sorting, and filtering behavior with the proposed prototype scope of ordinary data frames and matrices. Investigate whether base R formatting and comparison methods, plus a minimal JSON representation, can preserve the listed value behavior without external package dependencies. The investigation is complete when it documents feasibility and installation from a managed library; the issue names no specific files or tests.
由索引模型根據 Issue 內容生成。
描述
Motivation
The Data Viewer backend is currently implemented inside sess, which depends on external R packages such as jsonlite, processx, and later.
These dependencies can complicate installation and cause conflicts with packages managed by renv, pixi, or other environment managers.
PR #1856 improves installation isolation, but does not eliminate these dependencies.
I propose exploring a small, standalone R package for the Data Viewer backend, similar to how jgd provides a graphics device without external R package dependencies.
Unlike session communication, the enhanced Data Viewer is optional.
If its backend is unavailable, only the enhanced viewer needs to be disabled, without affecting the R session or the standard View() behavior.
The primary goal is dependency isolation and maintainability, not performance optimization.
Proposed direction
- Publish the backend as an independent CRAN package, installed into a vscode-R-managed library rather than bundled with the extension.
- Avoid external R package dependencies (
Imports/LinkingTo), using base R and a small amount of C code where appropriate. - Keep the backend independent of sess, and VS Code-specific communication protocols.
- Reuse existing R methods such as
format()for displaying S3/S4 objects, including vector classes built with vctrs. - Preserve native comparison and sorting semantics independently of formatted display values.
- Generate only the JSON structures required by the Data Viewer, potentially using an embedded C library such as cJSON.
- Keep the existing AG Grid frontend.
A general-purpose serializer such as jsonlite provides much more functionality than the Data Viewer needs.
By normalizing R values into a limited set of display types before JSON encoding, we may be able to avoid both a jsonlite dependency and vendoring its implementation.
Prior art
- jgd: A standalone R graphics device with embedded C code and no external R package dependencies.
- vctrs / pillar: Established conventions for separating vector formatting, type information, and comparison semantics.
- Julia VS Code Table Viewer: Converts language-specific values into a limited JSON representation for AG Grid, with lazy data retrieval.
Initial investigation
A prototype could focus on ordinary data frames and matrices, evaluating:
- Whether the existing metadata, paging, sorting, and filtering behavior can be extracted into a standalone package.
- Whether existing R formatting and comparison methods are sufficient for custom vector classes, including those based on vctrs.
- Whether a minimal JSON encoder can preserve existing behavior for missing values, numeric precision, dates,
integer64, and complex columns. - Whether the package can be installed and loaded from a managed library without modifying
.libPaths().
This is an architectural investigation, not a proposal to immediately replace the current implementation.
PR #1804 (lazy Arrow/DBI viewing) should proceed independently.
Arrow IPC / nanoarrow are not required for the initial prototype.
Separating the Data Viewer also does not eliminate sess's own jsonlite dependency, which is a separate concern related to #1859.
However, an independent backend could eventually be reused through alternative transports such as arf.
Related: #1856, #1859, #1804.
- 主要語言
- TypeScript
- 星號
- 1.2k
- 分支
- 152
- 平均合併
- 18 小時 28 分鐘
- 30 天內合併 PR
- 56
環境準備
- 沒有 Dockerfile 或 Docker Compose 檔案
- 沒有 Pull Request 範本
- 閱讀貢獻指南
從這裡開始
- 先讀完整個 Issue,再讀專案的貢獻指南。
- 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
- Fork 儲存庫,在一個分支上完成修改。
- 送出 Pull Request,並在描述裡引用這個 Issue 編號。
REditorSupport/vscode-R 的其他 Issue
-
[Bug]: indentation clash (formatter vs lintr)可能已有人在做 @renkun-ken 於 16 天前認領。 未關閉bug
難度 1/5 1 小時以內 新手友好度 92/100
REditorSupport/vscode-R#1883 ·
維護者通常 1 天內回覆
-
bug
難度 2/5 1-3 小時 新手友好度 68/100
REditorSupport/vscode-R#1846 · 2 則留言 ·
維護者通常 1 天內回覆
-
(feat) Additional Arrow support可能已有人在做 @Fred-Wu 於 21 天前認領。 未關閉enhancement
難度 2/5 1-3 小時 新手友好度 72/100
REditorSupport/vscode-R#1785 · 2 則留言 ·
維護者通常 1 天內回覆
-
難度 4/5 3-5 天 新手友好度 25/100
REditorSupport/vscode-R#1923 · 1 則留言 ·
維護者通常 1 天內回覆
-
難度 3/5 1-2 天 新手友好度 45/100
REditorSupport/vscode-R#1922 ·
維護者通常 1 天內回覆
查看 REditorSupport/vscode-R 的全部 Issue
相似的 Issue
-
test-reliability
難度 2/5 1-3 小時 新手友好度 78/100
Azure/azure-sdk-for-js#40672 · 1 個 reaction ·
維護者通常 1 天內回覆
-
難度 2/5 1-3 小時 新手友好度 74/100
HarperFast/studio#2067 ·
維護者通常 2 天內回覆
-
難度 2/5 1-3 小時 新手友好度 65/100
維護者通常 1 天內回覆
-
難度 2/5 1-3 小時 新手友好度 78/100
維護者通常 1 天內回覆
-
documentation
難度 2/5 1-3 小時 新手友好度 76/100
liberation-data/drivine#639 · 2 則留言 ·
維護者通常 1 天內回覆