Derived columns with Table?
Currently Table requires that data is an iterable of objects, and pulls out named properties for each field in each row:
https://github.com/observablehq/inputs/blob/ec971827bb39ce09462a5dc7047d8f93f9101a6e/src/table.js#L87-L90
While it’s true that data can be a lazy iterator, there could be an easier way to express a derived column without needing to resort to array.map and greedily materializing all the objects. And while it’s true that a format function could return a derived value (leaving d[column] as undefined), that’s not recommended because it will break sorting.
So, what if there were a map option that let you override the definition of a column:
Table(data, {map: {foo: d => d.bar}})
But how would this interact with the columns option? Maybe the map keys would get implicitly added to the default columns value?
(Also, it might be nice to use per-column iterators internally, and per-column arrays when materializing. This would be particularly nice in conjunction with column-based data structures such as Arquero.)
I’m going to leave this as a question because I think more thought is required to figure out how this would work and if we want it.
derivedColumns? That still doesn’t cover how they should be rendered — perhaps at the end by default, or you could specify their names in the column list?
Also, I think this is unnecessary for the case of simply labeling columns in a user friendly manner. For that, there could be an option with the TypeScript type { [rowKey: string]: string | Node } where the value of a given key would be turned into a text mode (if necessary) and used in the header of the table instead of the key name by itself.