getAttachment() and putAttachment() currently use Blob | Buffer in the StackAdapter interface:
putAttachment(data: Blob | Buffer, mimeType: string): Promise<FileId>;
getAttachment(fileId: FileId): Promise<Blob | Buffer>;
This union is awkward for callers — Blob and Buffer have incompletely overlapping APIs, and code that handles both needs branching logic (as seen in the SQLite adapter tests). In practice the SQLite adapter always returns a Buffer, while a browser-targeted adapter would return a Blob.
Options:
Uint8Array — works in both Node and browsers, universally understood, no branching needed. Would require callers to wrap in Buffer.from() or new Blob([...]) if they need those specifically.ArrayBuffer — similar story, slightly less ergonomic.- Keep the union but provide a helper — e.g.
toUint8Array(data: Blob | Buffer) in @haverstack/core. Avoids a breaking change to the interface but doesn't eliminate the awkwardness.
Uint8Array is probably the right call — it's the standard cross-runtime binary type and both Buffer and Blob are constructible from it.
getAttachment()andputAttachment()currently useBlob | Bufferin theStackAdapterinterface:This union is awkward for callers —
BlobandBufferhave incompletely overlapping APIs, and code that handles both needs branching logic (as seen in the SQLite adapter tests). In practice the SQLite adapter always returns aBuffer, while a browser-targeted adapter would return aBlob.Options:
Uint8Array— works in both Node and browsers, universally understood, no branching needed. Would require callers to wrap inBuffer.from()ornew Blob([...])if they need those specifically.ArrayBuffer— similar story, slightly less ergonomic.toUint8Array(data: Blob | Buffer)in@haverstack/core. Avoids a breaking change to the interface but doesn't eliminate the awkwardness.Uint8Arrayis probably the right call — it's the standard cross-runtime binary type and bothBufferandBlobare constructible from it.