marimo icon indicating copy to clipboard operation
marimo copied to clipboard

Lack of synchronization between table views leads to inconsistent selection state

Open akshayka opened this issue 1 year ago • 4 comments

Describe the bug

  • Create a ui.table and output it in two cells.
  • Access its value in a third cell.
  • Sort it by a column in one output but not the other.
  • Select a row in the first cell, and notice the selection is incorrect in the second cell.
  • Select a row in the second cell, and notice the selection is incorrect in the first cell.
  • table.value somehow picks up the selection applied to the first cell.

Possible solutions.

  1. One solution could be to synchronize sorts and filters across different instances of the same ui.table, so that selection was always correct.
  2. Another solution would remap the selected indices across instances of ui.table based on sorts/filters applied but not synchronize sorts/filters.

(1) feels more natural to me but I would be okay with either.

Screencast from 07-31-2024 11:52:47 AM.webm

cc @delennc

Environment

{
  "marimo": "0.7.14",
  "OS": "Linux",
  "OS Version": "6.5.0-41-generic",
  "Processor": "x86_64",
  "Python Version": "3.10.12",
  "Binaries": {
    "Browser": "126.0.6478.114",
    "Node": "v18.13.0"
  },
  "Requirements": {
    "click": "8.1.7",
    "importlib-resources": "6.1.0",
    "jedi": "0.19.1",
    "markdown": "3.6",
    "pymdown-extensions": "10.8.1",
    "pygments": "2.18.0",
    "tomlkit": "0.12.5",
    "uvicorn": "0.30.0",
    "starlette": "0.27.0",
    "websockets": "12.0",
    "typing-extensions": "4.12.2",
    "ruff": "0.3.5"
  }
}

Code to reproduce

import marimo

__generated_with = "0.7.14"
app = marimo.App(width="medium")


@app.cell
def __():
    import marimo as mo
    return mo,


@app.cell
def __():
    from vega_datasets import data
    return data,


@app.cell
def __(data, mo):
    table = mo.ui.table(data.cars())
    table
    return table,


@app.cell
def __(table):
    table
    return


@app.cell
def __(table):
    table.value
    return


if __name__ == "__main__":
    app.run()

akshayka avatar Jul 31 '24 19:07 akshayka

In my opinion, solution 2 is more reasonable. My consideration is, if a user outputs a table twice, and these tables are synchronized, then what's the value of outputting them twice? I think the point is, when the user outputs the table more than once, they should expect different sorts & filters on them.

ghost avatar Aug 01 '24 05:08 ghost

In my opinion, solution 2 is more reasonable.

My consideration is, if a user outputs a table twice, and these tables are synchronized, then what's the value of outputting them twice?

I think the point is, when the user outputs the table more than once, they should expect different sorts & filters on them.

I think you're right! Your reasoning makes sense to me.

akshayka avatar Aug 01 '24 05:08 akshayka

Since I've been working with tables, can I take this issue?

ghost avatar Aug 01 '24 07:08 ghost

Since I've been working with tables, can I take this issue?

From my side, you are welcome to. @mscolnick mentioned it may be a bit tricky. Maybe do a preliminary exploration to scope it out and see if it's doable without too much extra complexity?

akshayka avatar Aug 01 '24 17:08 akshayka