Skip to content

Introduce StaticHeaders type class for CSV#757

Open
ybasket wants to merge 1 commit intomainfrom
introduce-staticheaders
Open

Introduce StaticHeaders type class for CSV#757
ybasket wants to merge 1 commit intomainfrom
introduce-staticheaders

Conversation

@ybasket
Copy link
Copy Markdown
Collaborator

@ybasket ybasket commented Apr 3, 2026

Currently, the only way to create an empty CSV with headers is by using a pipe that takes explicit headers. The more comfortable encodeUsingFirstHeaders requires the CSV to be non-empty.

This PR adds a encodeUsingStaticHeaders pipe that takes the necessary header information from a new type class StaticHeaders. To facilitate adoption, the generic derivation now derives CsvRowEncoder instances that also implement StaticHeaders.

Still missing, will add once it's clear this PR is going somewhere:

  • MiMa exclusions – it's unhappy about changes in generic because DerivedCsvRowEncoder is public. I don't think it would be a problem
  • Documentation on the website (Scaladoc is already there)

Currently, the only way to create an empty CSV with headers is by using a pipe that takes explicit headers. The more comfortable encodeUsingFirstHeaders requires the CSV to be non-empty.
This adds a encodeUsingStaticHeaders pipe that takes the necessary header information from a new type class StaticHeaders. To facilitate adoption, the generic derivation now derives CsvRowEncoder instances that also implement StaticHeaders.
@ybasket ybasket requested a review from a team as a code owner April 3, 2026 14:29
Comment thread csv/shared/src/main/scala/fs2/data/csv/RowF.scala
@@ -0,0 +1,46 @@
/*
* Copyright 2024 fs2-data Project
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I need to update that year...


/** Type class for types that have statically known headers. This is useful for encoding/decoding CSV rows
* where the headers are fixed and can be determined at compile time. */
trait StaticHeaders[T, H] {
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I really think we need to drop this parametric header type for version 2, it makes things harder to read for no real benefit. Or do we have a strong point in favor of keeping it? I don't remember why I did that choice at the time...

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I think its weight is not justified by its value. Especially as we also don't use it in the generic module (which could also be generic over the header type via the type classes instead of being hardcoded to String, but isn't). And something like a NonEmptyMap[MyEnumType, String] (roughly isomorphic to our CsvRow) can be decoded from String headers almost as easily.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants