vercel-labs / vercel-labs/json-render

Best practices for generating UI with large datasets that may exceed model context

Open
#44 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
TypeScript
Stars
16.8k
Forks
901
Avg merge
3h 14m
Merged PRs (30d)
4

Description

Summary

Looking for guidance on the recommended approach when using json-render to generate visualization UI (e.g., line charts, dashboards) backed by large datasets that may exceed the model's context window.

Use Case

I want to enable end users to create data visualizations by prompting, such as:

"Create a line chart showing sales trends over the past year."

However, the underlying dataset could be thousands or tens of thousands of data points—potentially exceeding the LLM's context window if we try to include the full data in the prompt.

Question

What is the recommended approach in json-render for handling this scenario?

Options I'm Considering
  1. Data binding by path/reference — pass only metadata or a reference path to the AI, not the full dataset. The AI generates the JSON structure with valuePath or dataPath pointing to the actual data, which is resolved at render time.

  2. Sampling/aggregation before prompt — pre-process large datasets to reduce size before sending to the AI.

  3. Streaming/chunking — send data to the AI in chunks (if the model/API supports it), though this may affect the coherence of the generated UI structure.

  4. Hybrid approach — AI generates the UI component skeleton with placeholders or references, then later populates or updates it with the actual data.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reviewing json-render's existing handling of valuePath and dataPath, along with the four approaches listed in the issue. Since no files or tests are named, trace the relevant data-binding and rendering entry points; done means documenting a recommended approach for datasets that exceed the model context window.

Written by the indexing model from the issue text.

Assessment

Tech stack
typescript
Domain
frontend
Issue type
Documentation
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.