-
Notifications
You must be signed in to change notification settings - Fork 83
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
XLSX file attachments #215
Conversation
export class XlsxWorkbook { | ||
constructor(workbook) { | ||
Object.defineProperties(this, { | ||
_: {value: workbook} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It'd be nice to expose the XLSX object or XLSX.utils somewhere so people can easily use those functions like sheet_to_html or sheet_to_formulae. Or for modifying and writing back out to xlsx.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, I commented on why I didn’t do this: there are two versions of XLSX (mini and full), and we only want the mini one to parse XLSX files, but I think we’d want the full one (or both, somehow) in standard library.
I suppose I could hide it in the XlsxWorkbook class I made, but I figured it would be better to expose a minimal API that is easier for us to improve over time. (In my opinion, the design of SheetJs is not a little weird… I’m not sure why it favors global static functions over methods.)
I guess I could add both XLSX (mini) and XLS (full) to the standard library, but I think I’d prefer to wrap SheetJs rather than expose it directly so we can design a more elegant interface. That said once we have standard library versioning we can always change our minds.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok, let's start conservatively and see if we need to add more. there's also always the workaround of notebook-space requiring xlsx/sheetjs explicitly and using it if you need to.
I think |
This is blocked on deciding what to do with dates and times and specifically time zones. We want to translate dates and times to JavaScript Date objects. SheetJS and XLSX both specify "dates and times are in your local time zone." While that might make sense from a "single file on someone's computer" perspective, it leads to a lot of inconsistency in a web environment. |
What happens with csv attachments for dates and times? Does that have the same issue? |
By default all fields are strings and no dates are parsed. But if you use d3.autoType dates are assumed to be UTC. |
Superseded by #248. |
This adds support for XLSX file attachments via SheetJS. Similar to SQLiteDatabaseClient, I also chose to wrap the SheetJS API with a more convenient, minimal abstraction.
I chose not to expose SheetJS as a recommended library (for now). This step is not immediately needed to support XLSX file attachments, and there are multiple versions of SheetJS: we only need the “mini” version for XLSX, but we’d need the much bigger “full” version for XLS.