Feat: Generic Api for Kv batch get (non breaking)
I have to do some workarounds, like marking the GetValueType public, but I hide them in the doc lol
Resolve #842
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:
- Complete duplication for clarity
- Shared internal implementation (possibly using generics internally)
- Another approach you'd recommend?"
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
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...
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.
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.