Consider Blob.fromStream (returns a Promise<Blob>)
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 25/100
Línea de trabajo
El issue no menciona archivos del repositorio ni pruebas. Empieza comparando las API actuales de Blob, ReadableStream y Response(...).blob() descritas aquí; para darlo por terminado sería necesario contar con un diseño de API definido para Blob.fromStream, sus opciones y la cuestión relacionada con File, seguido de las especificaciones y pruebas de conformidad aplicables.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
I'm filing this as a tracking issue, although I don't think it's particularly urgent. But maybe web developers have run into this more, in which case hearing from them would be great.
Anyway, right now, to convert a ReadableStream to a Blob, you have to do
const blob = await new Response(stream).blob();
which is pretty silly. Just as blob.stream() was added to avoid the silly new Request(blob).body pattern, perhaps we should consider adding a promise-returning Blob.fromStream() so you could do
const blob = await Blob.fromStream(stream);
There is a bigger savings if we add an options parameter:
const blob1 = new Blob([await new Response(stream).blob()], options);
const blob2 = Blob.fromStream(stream, options);
Points to consider:
- We could instead make this
stream.toBlob(), but I feel the layering of keeping streams ignorant of blobs is a bit cleaner. - We may not want to introduce this because it's better if people avoid using blobs? (Or is it just blob URLs that we dislike?)
- If someone wanted a
File, we could either addFile.fromStream(stream, fileName, options)or we could have people donew File([Blob.fromStream(stream)], fileName, options). ProbablyFile.fromStream()is nicer. - This does not allow creating a blob that represents an "in progress" stream, which I've heard people have wanted in order to have self-referential blobs. That would require new concepts and infrastructure. This proposal is basically just exposing existing infrastructure in a more straightforward way.
- Lenguaje dominante
- HTML
- Estrellas
- 118
- Forks
- 52
- Merge medio
- 9 d 16 h
- PR fusionados (30 d)
- 1
Guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de w3c/FileAPI
-
TPAC 2026 Status Report AbiertoTPAC2026
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
-
Broken references in File API Abierto
Dificultad 1/5 Menos de una hora Aptitud para principiantes 62/100
-
Add accessibility section Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 30/100
Todos los issues de w3c/FileAPI
Issues similares
-
Bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
Automattic/safe-publish#593 ·
-
executions.Query — startDate and timeRange filters are sent with inverted comparison operators Abiertoarea/plugin
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
kestra-io/plugin-kestra#190 ·
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
xinnan-tech/xiaozhi-fde-talk#263 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
-
pending-maintainer-response pending-triage
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100