Tables lose interactivity in HTML

[liquidcarbon]

Describe the bug

Looks like it's currently not possible to sort or filter mo.ui.table output.
All the data is embedded into HTML but on sorting the browser console gives

CellNotInitializedError: The cell containing this UI element has not been run yet. Please run the cell first.

Altair chart also embeds all the requisite data in a JSON; as far as I can see, at least basic interactivity like zoom/pan/tooltips works as expected.

Will you submit a PR?

• Yes

Environment

any

Code to reproduce

import marimo as mo
import duckdb
rel = duckdb.sql("FROM 'https://raw.githubusercontent.com/liquidcarbon/chembiodata/main/isotopes.csv'")
mo.ui.table(rel)

and look at HTML

[mscolnick]

All the data is embedded into HTML but on sorting the browser console gives

This is not true. We only send one page at a time for performance, so you need to be connected to a kernel in order to sort the table. I've made that clearer in this PR though (#6765)

[liquidcarbon]

mo0.html
What's the really long JSON on line 283? nevermind that's Vega's JSON :) the marimo table shows just the first 10 rows

Still...of course not all tables can or should remain interactive, but up to a certain number of data elements, why not?

[mscolnick]

I'm not sure how that is possible, especially for sorting. But open to hear how it can be done.

[liquidcarbon]

Definitely possible - jquery-based datatables.net ( #3192 ) easily handle up to ~100-500K data elements in static pages, preserving instant search and sort; the cap on data size can be set in options. There are at least two ways to pass the data - one as a regular <tr><td> HTML table (possibly deprecated by now), another as a JSON (similar to Vega).

Alas, I don't understand marimo's frontend stack... how is HTML is rendered from this?

<marimo-table data-initial-value='[]' data-data=...

https://github.com/marimo-team/marimo/blob/main/frontend/src/plugins/impl/DataTablePlugin.tsx#L232

[mscolnick]

I meant it is not possible because we don't send all the data to the frontend and you mentioned only sending part of the data.

Of course we can send all the data to the frontend, but that is something we are not interested in doing as large files would just crash the page. Also it does not seem like a good practice to embed a dataset in the page (better to host it somewhere and run it with WebAssembly)

[liquidcarbon]

I believe there are good use cases for having complete tables in HTML. Being able to send a single file to a collaborator by email, or by sharing a S3 static website link, fulfills the same function as sending an excel doc or a quarto/nbconvert printout with DataTables. The point is to have all the data, computations, and logic in one place. Hosting the data elsewhere means worrying about keeping two or more sources in sync, access considerations, etc. Yes, WASM has made big strides but still not everything is available on pyodide, and the code execution may take a while.

It makes perfect sense to only send one page at a time in live notebooks. But there could be an option for mo.ui.table to pass through all data, or up to a limit, when saving to HTML. Something like html_max_bytes or html_max_rows that is None by default - for the same behavior as now - but setting to a number would cause to write the whole thing.

Alternatively, one could disable pagination or set page size to a large number but that would interfere with readability. Or wrap in <details>?

Is it possible to convert this to discussion?

[mscolnick]

@liquidcarbon, maybe try:

client_side_table = mo.ui.table(
        many_rows,
        pagination=False,
        max_height=300,
    )

this should load all rows to the frontend and just scroll

[liquidcarbon]

Good idea, could the download / copy to clipboard button made to work though?

[mscolnick]

not currently