A real spreadsheet, written by the grid

There is a moment, usually about four days after a screen goes live, when somebody in finance asks whether they can have it in Excel. Not because your screen is bad. Because the next thing they do with those numbers happens in a spreadsheet, alongside three other things that are already in spreadsheets, and no amount of dashboard is going to change that.

What they usually get is a CSV. It opens, technically. The invoice references have turned into dates, the amounts are text because one of them had a currency symbol, the header scrolls away on the first flick of the wheel, and the person who asked spends the first part of their morning making it usable before they can start the work they actually wanted to do.

Ask for the file, get the file

The grid above is a month of finance lines. Look at the rail on the left: there is a spreadsheet button and there is a download button, and nothing happens until one of them is pressed. A page that writes to your Downloads folder for turning up has taken a decision that was not its to take.

Press the spreadsheet one and you get an .xlsx. Not a CSV with the extension changed. It is a genuine workbook: the sheet carries the name you gave it, the header row and the pinned first column are frozen so they stay put when the file scrolls, your column widths came with it, and the amounts arrive as numbers rather than as text, so a sum over the column works on the first try. Ticks are real booleans. Open it and start working. There is nothing to tidy up first.

The plain download button writes a CSV, for the times a CSV is what is wanted, and it writes it properly. That matters more than it sounds, because this data has the awkward cases in it deliberately. Supplier names contain commas, because a legal suffix after a comma is what a company name looks like. Notes contain double quotes. Amounts are large enough that their formatted text carries a thousands separator, which is another comma in another place. The eye button on the rail runs the same writer with the download suppressed and prints the line it produced into the strip under the grid, so you can read the quoting rather than take our word for it.

There is also a copy button, which puts the visible rows on the clipboard in a shape a spreadsheet understands, and a print button, for the one person in every organisation who wants it on paper.

And it cost your developer nothing

This is the part that decides whether your users get it.

The workbook is assembled in the browser. The zip container, the sheet, the shared strings, the styles: all written by the grid, in the page, with no server round trip. There is nothing to deploy, no endpoint to secure, no queue for generating files, and no copy of your customers’ data taking a trip through somewhere it does not need to go. For anyone whose data is not allowed to leave the page, that last point is not a convenience, it is the difference between having the feature and not.

It also adds nothing to your bundle. No spreadsheet library, no zip library, no optional dependency to install and pin and upgrade. Lattice Grid takes no runtime dependencies at all, and Excel export is inside the same two files as everything else. A developer turns it on by naming excel in the tool panel’s actions, and the button is there:

toolPanel: { side: 'left', actions: ['export', 'excel', 'clipboard', 'print'] }

Four built-ins, in one line, and your own buttons go in the same list as objects with a name, an icon and a run. The demo above uses that to add a second Excel button that names its sheet and freezes the header explicitly, which is what a host would do to give the file a shape somebody expects.

That is the whole cost. Nobody writes a file writer, nobody maintains it, and nobody gets the ticket in March saying the export broke when a supplier changed their name to one with a comma in it.

Take an .xlsx off the demo or see how the CSV quotes itself.