Feat: Generic Api for Kv batch get (non breaking)

[WERDXZ]

I have to do some workarounds, like marking the GetValueType public, but I hide them in the doc lol

Resolve #842

[guybedford]

Thank you for posting the PR, this is great!

The backwards compat work is impressive, but I think it is absolutely fine for Rust to treat this as an entirely separate function like batch_get, which should significantly simplify the approach and remove the generics tricks. As much as possible we should always try to give a direct translation of the JS APIs without too much magic.

Please let me know if you're able to post a follow-on further? Thanks.

[WERDXZ]

I can create a separate batch_get() function as you suggested. My concern is code duplication between GetOptionsBuilder and the potential BatchGetOptionsBuilder like cache_ttl, text/json methods, etc.

Would you prefer:

1. Complete duplication for clarity
2. Shared internal implementation (possibly using generics internally)
3. Another approach you'd recommend?"

[guybedford]

I wonder if it might make sense to make a breaking change here actually, and simply require kv::get(key, Option<options>) and kv::get_keys(keys, Option)`, removing the builder methods to avoid the generics complexity?

This would require an explicit use of KvOptionsBuilder::new() so:

let options = KvOptionsBuilder::new();
options.cache_ttl(...);
kv::get_key("foo", options.build())

I don't think that would be too unidiomatic? The closer we can get the JS, the less pain we will have maintaining these, as opposed to trying to solve complex generics...

[WERDXZ]

Just to make sure, we want to make the api similar to cloudflare/workers-sdk and we can do a breaking change.

I think the KvOptionsBuilder way is a great way tbh, and we can impl Default on it. But another question that comes out of it is how are we gonna distinguish between the return type: type: "text" | "json" | "arrayBuffer" | "stream".

We can either make the get_key and get returns some kind of fetcher and do request type on that, or do generic tricks (rust can do return type inferring)

The reason why I previously did those generic stuff is to imitate the behavior of get() in the js api that we can either pass in an array or a single string value.

[guybedford]

The reason why I previously did those generic stuff is to imitate the behavior of get() in the js api that we can either pass in an array or a single string value.

Yeah, perhaps then just a very simple generic on the type being a #[wasm_bindgen] enum imported type then? With the two functions then knowing which specific variant they use? Further thoughts welcome.