[PromptInput]: Support for hosted URL for files
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 2.4k
- Forks
- 283
- Avg merge
- 32m
- Merged PRs (30d)
- 1
Description
According to the documentation of UIMessage, a FileUIPart can either use a hosted URL or a data URL. At the moment, <PromptInput /> uses data URLs.
This works, but has some drawbacks worth mentioning:
-
Increased payload size:
All file bytes are inlined directly into the message as a Base64 string. This makes every message carry the entire file contents instead of just a short reference. -
33% size inflation:
Base64 encoding adds overhead — files end up ~33% larger than their binary size, plus a smalldata:...;base64,prefix. -
Persistence:
If you want persistence of chat history and messages, you need to store the data URL in the DB somewhere. For big enough files, this obviously is not very scalable. You typically store only the reference to the file in the DB, and the actual file in a storage somewhere else, like Vercel Blob or S3.
Not really sure what the best solution would be here, perhaps some props could be exposed in <PromptInput /> where we could write our own logic for what happens when a file is added/removed? But that might introduce some heavy refactoring...
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with packages/elements/src/prompt-input.tsx around lines 300-306 and compare the current data URL handling with the FileUIPart documentation for hosted URLs. Determine an API for supplying file references or custom add/remove behavior, then confirm that PromptInput can produce hosted-URL file parts without breaking its existing data-URL behavior.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript
- Domain
- frontend
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100