Make it easy to convert strings to blobs

[inverted-capital]

Here is a little playground repro: https://dash.deno.com/playground/lazy-bat-30

If I set a blob using a string, I do not get an error:

await set(kv, ["hello"], 'data');

but if I remove this data, then request the meta of that key:

const meta = await getMeta(kv, ["hello"])

I get back something that looks valid, when I should be getting back null:

{
  "key": [
    "hello",
    "__kv_toolbox_meta__"
  ],
  "value": {
    "kind": "buffer"
  },
  "versionstamp": "0100000000e04de50000"
}

I would expect that, if I submitted a string, I should get an error thrown, or if set accepts strings, I should be able to delete them.

Ideally I should be able to set a string as a type, and have the metadata reflect that, since it is easy to have a string that is over the blob size. Pretty please can we store some arbitrary length strings ? 🙏 😁

[Kitson Kelly]

If I set a blob using a string, I do not get an error:

await set(kv, ["hello"], 'data');

You don't get a runtime error, but there is a type error. I generally not in favour of implementing runtime type checking when there are totally valid types and appropriate documentation telling you that the behaviour is undefined.

I will think about storing arbitrarily lengthed strings... It does strike me as counter intuitive to what blob typically means (binary large object) and typically with data stores means raw binary data. Large strings can be easily encoded to Uint8Arrays or Blob for storage. In fact new Blob([someLargeString], { type: "text/plain" }); would be the best way to store a large string in fact.

[inverted-capital]

My apologies - the type error does not appear when using the deno deploy playground, but that is totally fair enough to expect a type error to be sufficient.

With strings, it takes a modicum of skill to encode it into an array without wasting cpu, and then also to convert it back. As an often incompetent user, it would be nice if the library did the smart thing for me under the hood.

Furthermore, strings can be stored in DenoKV's native types, which may possibly skip an encode / decode step, but the main benefit for me, is that when using kview to look at my database (thanks for that app btw !) if I store a string, I can't actually see its contents - I have to write some code rather than just browse around and read the strings directly in kview.

[Kitson Kelly]

My apologies - the type error does not appear when using the deno deploy playground, but that is totally fair enough to expect a type error to be sufficient.

Sadly, type checking is not part of the dash playground at the moment. I don't know if they will ever add it.

The argument though that it should be low friction to throw a big string at it and have it "just work" is compelling. I meant to add the ability to view text/* content types to kview to make it easier to view arbitrary text content. I guess the question of where that "magic" should occur. Like you can upload a .txt file at the moment with the latest version of kview, it is just lacking the ability to display it.

I could see adding a little helper of asBlob(string, type = "text/plain") to make it easy to convert arbitrary strings to blobs for storage to make adding them in code a little easier, but still otherwise handle them as binary data. That sort of appeals to my sense of keeping blobs to being raw/binary data.

[Kitson Kelly]

Ok, I added toBlob() which makes it trivial to add blob values. I will be adding the display to kview in a little while.

[Kitson Kelly]

Ok, v0.13.0 of kview has some major improvements to viewing blobs of media types like text/plain, html, pdfs and other "web" like files.

[inverted-capital]

nice one !