-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: UI table formatting #950
Conversation
@mattrunyon Perhaps this could tie into the work for #549 (setting |
|
||
> [!NOTE] | ||
> The `where` property is a Deephaven query expression evaluated in the engine. You can think of it like adding a new boolean column using [`update_view`](https://deephaven.io/core/docs/reference/table-operations/select/update-view/) | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we add a sections for each formatter? Helps both SEO and shows a functional example of how to accomplish each task
#### Formatting table background colors
#### Formatting table decimals
#### Formatting table dates
...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it would make more sense to do Formatting Colors
and Formatting Values
unless you want each of those sections to be 1 or 2 sentences. That feels like overkill to me to show someone what "changing the background color to red" does or "changing text alignment to left".
I think formatting colors would explain what kind of color values you can use and what values can take colors.
Formatting values would link out to appropriate docs about value format strings (I think they're Java formatting strings, but need to verify)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Formatting colors and Formatting values sound reasonable in terms of avoiding super short sections; however, if a user is likely to search "Formatting table dates" and similar, it might be worth it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I ended up adding Formatting Colors
as an h3 to describe you can (and should) use theme colors. Then text/background color as h4.
For values I added an h3 for numeric and datetime
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, a couple of minor fixes/notes. Would be nice if we could pass in a column name for the column or format value as well (with those taking precedent; e.g. if you have a column named RED
, that value would take precedent over the colour RED
).
I also tested with a large number of columns to make sure weren't getting caught with stuff out of the viewport, and it seems to work correctly:
from deephaven import empty_table, ui
colors=["RED", "GREEN", "BLUE"]
cols = [f"C_{i}=i" for i in range(1, 100)]
t = empty_table(1000).update([*cols, "x=i", "c=`` + colors[i%3]", "RED=`` + colors[(i + 1)%3]"])
ut = ui.table(t, formatting=[ui.TableFormat(where="C_3%2==0", color="RED")])
|
||
> [!NOTE] | ||
> The `where` property is a Deephaven query expression evaluated in the engine. You can think of it like adding a new boolean column using [`update_view`](https://deephaven.io/core/docs/reference/table-operations/select/update-view/) | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Formatting colors and Formatting values sound reasonable in terms of avoiding super short sections; however, if a user is likely to search "Formatting table dates" and similar, it might be worth it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me. Curious what @dsmmcken thinks of using if_
and format_
I kinda hate it. I assume that's because those are both keywords in python? Did I miss a discussion somewhere? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approving docs, not a fan of if_ or format_ but I defer to you guys. Pending accepting @margaretkennedy changes.
I wouldn't hate cond=
Fixes #596. Adds UI table formatting based on the spec.
Features
cols
parameter applies formatting to specific columns. Theif_
parameter provides further filtering for rowsMissing
if_
is bad. Other potential error points we might want to addFollow-ups
Example Code