Conditional styling

[axiomiety]

Hi!

On the off chance I missed this in the docs, would you consider support for conditional formatting based on a cell/renderable's value?

E.g. if I had a table with a "status" column, I may want "failed" to show up as red and "pass" to show up as green. Right now a similar effect can be achieved by specifying the style of each Text object when calling add_row, but it may make more sense to specify this when calling add_column.

In short, I'd expect that if style were a Callable type, it should take a cell's value and return the corresponding style. Happy to give this a try if you think it'll be useful.

[willmcgugan]

Not convinced this is a good idea. Rich tables deliberately don't care too much about the contents of the cells, and only needs to know how to render them. Adding this callable would require the Table class to have at least some understanding of the cell contents.

I think there may be better ways of achieving this, albeit not quite as transparently.

One option would be to create a highlighter that highlights the text "failed" and "pass" differently. See highlighters in the docs.

Another option (and my preferred option) would be to create a renderable that renders the appropriate result based on a boolean. Something like this:

class Status:
    def __init__(self, success:bool) -> None:
        self.success = success

    def __rich__(self) -> Text:
        return Text("pass", style="green") if self.success else Text("fail", style="red")

You can then add instances of Status to your table row. If you already have an object containing the status, you could add the __rich__ method to it directly.

[axiomiety]

Thanks - I appreciate the decision of keeping styles agnostic to the Renderable they are styling (whether in tables or not). I gather that's the same reason columns don't have a formatter of sorts?

Encapsulation of the data and exposing a __rich__ method is a nice alternative, though it does feel like it would need to be an additional wrapper on top of the object itself to keep rendering as a separate concern (vs something added to the object definition itself).

I took a look at Highlighter and agree the encapsulation alternative seems more in line with the original purpose - for one, comparisons can be made on the type of the object itself vs its string representation. I'll give this a shot.

Thanks for taking the time to explain!