The argument sheet_type to create_a11ytable() can be cover, contents, notes or tables (one per sheet). This information dictates how generate_workbook() will apply styles and structure to a given sheet.
At present, the package is constrained to these four types and the code of generate_workbook() is not particularly elegant or easily expanded for new potential sheet types.
Would it be better if sheet types used OOP under the hood? A parent class could apply style and structure to common elements like the sheet title. Child classes could have methods specific to each sheet type.
The opinionated set of current sheet types helps keep things simple and generic, but maybe the options should be expanded. OOP might make it easier on the dev side.
The argument
sheet_type
tocreate_a11ytable()
can becover
,contents
,notes
ortables
(one per sheet). This information dictates howgenerate_workbook()
will apply styles and structure to a given sheet.At present, the package is constrained to these four types and the code of
generate_workbook()
is not particularly elegant or easily expanded for new potential sheet types.Would it be better if sheet types used OOP under the hood? A parent class could apply style and structure to common elements like the sheet title. Child classes could have methods specific to each sheet type.
The opinionated set of current sheet types helps keep things simple and generic, but maybe the options should be expanded. OOP might make it easier on the dev side.