Codec type for WebStorage, FetchStream, etc.

[raquo]

Currently, FetchStream and WebStorage offer withCodec(encodeFn, decodeFn) builders.

See if we can offer a Codec[A, B] typeclass that users could automatically derive from their existing JSON codecs (once per JSON lib, not once per type).

Our APIs should require (Encoder[A, B], Decoder[A, B]) for maximum flexibility

Note that FetchStream needs some weird types, but we should be able to wrangle them into Encoder & Decoder

Consider all applications of these codecs across Airstream and Laminar – where do we want to use them? Do we have decode return a Try, or throw instead? Should encode or decode be allowed to throw?

Ideally we should keep the current withCodec et al APIs because I think for many cases this would work just as well, without requiring the concept of typeclasses.

[yurique]

I think in cases like this, we should not fret too much about typeclasses :), especially now that they are first class citizens in Scala 3.

A more substantial question I have is - why two type parameters? (I might be missing the idea here)
Also, if we make it Codec instead of Encoder + Decoder - I'm pretty sure it will have to be invariant, right? (which can be annoying in some cases)

[yurique]

Circe has all three (encoders, decoders, codecs) and they can be automatically derived both ways: encoder+decoder <-> codec (and codec is just a convenience)

[raquo]

Yes, encoders and decoders will be separate. Codec would just be a bundle of both that the user may choose to provide as a single instance, as is usual in json libs.

WebStorageVar needs to encode/decode values between A and String, which aligns well with a single-param Codec[A], but FetchStream is more complicated. It needs to encode data from your Input to type dom.BodyInit = Blob | BufferSource | FormData | String | ReadableStream[Uint8Array] | URLSearchParams, and needs to decode data from dom.Response into your EventStream[Output] (allowing for a streaming codec to read the response.body stream).

So... I'm not yet sure if FetchStream would be able to use json-style codecs that can only encode/decode into String – those aren't enough to describe its entire functionality. But... maybe I'll just make the new Codec-based API more limited, intended for simple, non-streaming JSON codecs. And if someone needs to e.g. implement a streaming codec to parse the response, or submit FormData instead of a String, they could use the existing non-typeclass methods.