scottmatthewman / swiftcsvencoder Goto Github PK

Different applications that are capable of importing CSV files have different ways of handling some data types. Indeed, that it why CSVEncoderConfiguration exists.

But each app generally wants the same format all the time, and developers shouldn’t need to have to remember (or investigate) which date formats are needed for the most popular apps.

We could provide static instances of CSVEncoderConfiguration that have the necessary encoding strategies predefined, for example:

CSVEncoderConfiguration.excel // All the necessary config to ensure CSV files are readable by Microsoft Excel
CSVEncoderConfiguration.numbers // All the necessary config to ensure CSV files are readable by Apple Numbers

This would make the definitions more expressive while hiding the implementation detail:

let table = CSVTable<Person>(columns: [ … ], configuration: .excel)

Booleans are currently configured to output as the text strings true or false.

Add a new configuration parameter to CSVEncoderConfiguration to support different styles of encoding:

Expected work to do:

• Add BoolEncodingStrategy enum to CSVEncoderConfiguration with all options documented
• Add boolEncodingStrategy property to CSVEncoderConguration
• Update CSVEncoderConfiguration.default to use the default [^1]
• Update Bool.encode() method to amend output based on configuration strategy
• Add unit tests for each strategy
• Review and verify generated DocC documentation

Currently, Double and Int have CSVEncodable support added. Any other numeric types have to handle their own encoding within the CSVColumn configuration.

Expanding the list of support to Float, UInt, etc., could be useful.

Include a privacy manifest file indicating that SwiftCSVEncoder does not collect any data.

Currently, CSV tables are defined as in the following example:

let table = CSVTable<Person>(
  columns: [
    CSVColumn("ID", \.id),
    CSVColumn("Name", \.name),
    // etc.
  ],
  configuration: .default
)

This isn't great for situations where I might need a more dynamic approach to column inclusion. For example, only users with a certain level of access may have access to personally sensitive information and their CSVs shouldn't attempt to include those columns. Or, I may have a feature in the app that is governed by a feature flag, and columns should be omitted if that flag is not on.

Another approach would be to use a ResultBuilder-style syntax for building table definitions, say:

CSVTable(configuration: .default) {
  Column("ID", \.id)
  Column("Name", \.name)
  if currentUser.isSuperAdmin {
    Column("Address", \.postalAddress)
    Column("Tel", \.telephone)
  }
  if FeatureSet.includes(.starRatings) {
    Column("Star rating") { StarRating($0.value) }
  }
}

This might also allow for configuration to be broken up and implemented as modifiers:

CSVTable {
  Column("ID", \.id)
  Column("Date of birth", \.date)
    .dateFormat(.iso8601)
}
.fieldDelimiter(.tab)

Currently, the configuration object that governs encoding strategies for dates (and, when #2 is implemented, Booleans) is defined in the CSVTable initialiser.

However, it is only used at the export stage. And it could be argued that it only matters there: the CSVTable is a definition of the structure, and it is only when we solidify that data that we actually care what format to use. This could allow the same CSVTable structure to be encoded in slightly different ways, for example, if Excel and/or Numbers needed slightly different formats than a custom app with its own CSV importer.