programatically select rows

[dnalor]

First of all, thanks for releasing this - very useful.

I'd like to programatically

• set the highlighted row
• selected / unselected rows
  without rebuilding the table.

I tried:

for _, r := range m.archTable.SelectedRows() {
	r.Selected( false)
}

which doesn't work (presumably b/c the method returns values and not references?)

Am I missing something, or is this not possible?

[Evertras]

The rows returned by SelectedRows are just copies, so changing anything will not reflect back into the table. It's a little misleading now that I'm double checking the docs. Let me play with creating an example and potentially making some updates as well to make this easier/clearer.

[dnalor]

Interesting, I wasn't aware of that.
Then it may not be worth your effort just for some corner cases.

[Evertras]

Gotcha... if there's something that's really a pain to do I'm always happy to figure out if there's some nice helper function we could add, like WithAllRowsDeselected. Feel free to open an issue if you have any ideas for more. 🤘

[timcolson]

After starting with a simple table, I came here to ask how to update data for a selected row...

I found this Q&A and read the following:

...modifying an existing table is forbidden as Bubble Tea relies on all models being immutable

Ahhhh. Thx @Evertras! That helped Elm click for me!

I've been struggling with changes not showing up in a List of items.
Apparently, the LLM assistant I'm using is similarly confused about immutability. lol

TL;DR - To update one row, rebuild the model data for all the rows?

[Evertras]

Basically, don't think of the table as an object. Think of the table as a function that takes some input of raw data and produces some output that's the actual terminal characters that visually represents a table. Configuring the table is just modifying the function itself (colors, spacing, etc.). The function that then produces the table is pure: the same input produces the same output.

The model you're supplying is the input for the function. When you want to give a different input, you have to give a different input; this means resupplying all the model data at once, because that's the input. Whether this is changing a single value or otherwise doing a more expensive rebuild is outside the table's care. It just cares that you're giving it a new input, so it'll give a new output.

The optimizations of how it does this quickly are hidden away from whatever's using this function: this is why you can't modify the data 'inside' the table, because there's conceptually not data 'inside' the table, and these optimizations only work because we know the user isn't modifying those hidden caches.

I'm not sure if that made things more or less clear. :)

[timcolson]

Thanks for the additional info, @Evertras. I'm working on some experiments to solidify it in my brain. 👍