gnieh/fs2-data

Support magnolia-based instance derivation

Daenyth opened this issue · 2 comments

Magnolia instance derivation is preferable to shapeless induction for a few reasons:

  • It's designed for this use case, so the api is more directly applicable than shapeless' very general one
  • It compiles a lot faster, which is beneficial to projects with a lot of data mappings
  • The debugging when instances fail to derive is friendly, informative, and actionable (https://magnolia.work/opensource/magnolia#debugging)

Adding this kind of derivation in a new submodule would be a great win for making the library more beginner-friendly and useful to fs2+typelevel-stack newcomers

I looked into this and I'm afraid Magnolia isn't a good fit (at least for CSV encoding/decoding). The reason is that it expects the same type class to be available for every member of a product (read: case class) it derives an instance for and doesn't allow to require instances of a different type class instead. So while we could implement Magnolia derivation for CellDecoder/CellEncoder for coproduces of objects and unary products, I don't see a (good) way to implement derivation for rows (RowDecoder/RowEncoder and CsvRowDecoder/CsvRowEncoder) as Magnolia would require every cell to have an instance of the derived type class instead of the actual necessary CellDecoder/CellEncoder. Due to this difference to other file formats like JSON, which are recursive and by that fitting Magnolia's expectations way better, CSV with Magnolia seems to be a won't do.

I do like the aim for faster and easier to debug derivation though! Options I currently see are scalaz-deriving (unfortunately comes with a Scalaz dependency), custom macros (doable, but not so easy to get the details right) or waiting for dotty's generic derivation (which we might get "for free" using shapeless 3).

I will close this ticket for now, since it doesn't look like it's doable. If you disagree, let me know, we can discuss and reopen it.