docs: Add the ui.table spec
#82
Conversation
mofojed
commented
Oct 5, 2023
•
mofojed
commented
- Includes a whole bunch of method specifications and deprecations
- Closes Spec ui.table #78
- Includes a whole bunch of methods and deprecations
- Also specified that we will not be adding dropColumnFormats functionality (not sure it's necessary ... )
plugins/ui/DESIGN.md
Outdated
| ##### context_menu | ||
|
|
||
| Add custom items to the context menu. You can provide a list of actions that always appear, or a callback that can process the selected rows and send back menu items asynchronously. | ||
|
|
There was a problem hiding this comment.
Should we have an option for both row and header context menu items?
There was a problem hiding this comment.
Yea, I wasn't sure exactly how we want to structure this. With a callback, you can see what cell the user has clicked on (or header/row). I'll clarify that the CellIndex will be sent instead of just the RowIndex. Then, using a callback you can use the context to determine whether to return an action or not.
I don't know if we want to have convenience parameters for actions that will always get added to certain spots (cell_menu_items, column_header_menu_items, row_header_menu_items, etc).
| ##### quick_filter | ||
|
|
||
| Add a quick filter for the UI to apply to the table. |
There was a problem hiding this comment.
Do we want to allow applying advanced filters? Or do we want to move in a direction of just "filters" where "advanced filters" are just a builder for something you could do in the filter language that quick filters use. Or can you not do the advanced filter operations in our quick filter language?
There was a problem hiding this comment.
I intend to move the existing UI to be serialized as quick filters.
There was a problem hiding this comment.
- `search_display_mode` => `can_search`, a more concise name - `show_totals` => `aggregations`, since it's about setting aggregations and that's how we show it in the side bar
- Replace format_columns with color_column, color_row, and format instead - Rather than having one method that accepts everything, break it out into what is expected instead
|
|
||
| <!-- TODO: For ranges, such as "In Between", how should we specify that? Should we define a quick filter format for that? (e.g. `(5, 20)`, and `[5, 20]`, matching how you'd notate an interval) --> | ||
| <!-- | ||
| TODO: We also don't allow conditional formatting that sets a colour on one column depending on the value on another column; eg. `source.format_columns(["A = B > 2 ? BLUE : NO_FORMATTING"])` |
There was a problem hiding this comment.
@dsmmcken I have questions about these color_column methods if we're going this route - using this kind of API (which conforms to our current UI), we simply would not be able to do some of the kinds of formatting that are in our examples right now (e.g. colour one column based on the value in another column). Is that functionality we should build into the UI and allow more flexibility programmatically?
There was a problem hiding this comment.
Is that functionality we should build into the UI and allow more flexibility programmatically?
Probably. I wonder if there's a more raw version of the UI that makes sense in those cases. I haven't given detailed thought how to handle this, other than conceptually ui.table is intended to reflect state in the UI. Where as users may use more free-form formatting as part of queries. It is similar to where vs quick_filters in a way yes, however I don't think this would be an adequate replacement for format_columns if it was so striped down. This will be tricky.
- Have custom types defined in a common area - Add `selection_mode` API
- Change all constants to SCREAMING_SNAKE_CASE, as per PEP8 - Update `context_menu` to use it's own type instead of using `SelectionMode` so it's a little clearer
|
Add in state of partition table selection as an option on ui.table as well. |
