Lance tables often contain references to external assets (image paths, S3 keys, document URLs), but the viewer displays them as plain text. Adding inline previews would make the viewer much more useful for ML/CV workflows where datasets reference images or documents.
Proposed approach: URL template via environment variables
PREVIEW_URL_TEMPLATE=http://minio:9000/my-bucket/{image_key}
PREVIEW_COLUMNS=image_key
PREVIEW_TYPE=image # image | link | iframe
The viewer constructs URLs at render time by substituting {column_name} placeholders with row values, then renders an <img>, <a>, or <iframe> tag.
Why a URL template (not S3 integration):
- Works with any HTTP-accessible storage (MinIO, Nginx, CDN, pre-signed URLs)
- No credentials or SDK dependencies in the viewer
- The viewer stays read-only and stateless
- Extensible to documents, audio, video by changing
PREVIEW_TYPE
Implementation outline:
- Backend: 3 env vars + a
/config endpoint so the frontend knows the preview settings
- Frontend: cell renderer checks if column is in
preview_columns, constructs URL, renders preview element with loading="lazy" and thumbnail CSS
This is the largest proposed change so I wanted to get input on the approach before implementing.
Lance tables often contain references to external assets (image paths, S3 keys, document URLs), but the viewer displays them as plain text. Adding inline previews would make the viewer much more useful for ML/CV workflows where datasets reference images or documents.
Proposed approach: URL template via environment variables
PREVIEW_URL_TEMPLATE=http://minio:9000/my-bucket/{image_key} PREVIEW_COLUMNS=image_key PREVIEW_TYPE=image # image | link | iframeThe viewer constructs URLs at render time by substituting
{column_name}placeholders with row values, then renders an<img>,<a>, or<iframe>tag.Why a URL template (not S3 integration):
PREVIEW_TYPEImplementation outline:
/configendpoint so the frontend knows the preview settingspreview_columns, constructs URL, renders preview element withloading="lazy"and thumbnail CSSThis is the largest proposed change so I wanted to get input on the approach before implementing.