Skip to content
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

Edit and save column width values #1366

Open
dcnadler opened this issue Jan 6, 2025 · 3 comments
Open

Edit and save column width values #1366

dcnadler opened this issue Jan 6, 2025 · 3 comments

Comments

@dcnadler
Copy link

dcnadler commented Jan 6, 2025

Describe the problem to be solved

I found one reference to this feature in the Community: https://community.getgrist.com/t/how-to-precisely-control-column-width/3770

Currently, column widths can only be control by drag-and-drop. This is very cumbersome for tables with many columns (and summary tables based on those, which don't inherit column widths from the source table).

Additionally, if you hide a column and then unhide it, the previous column width that was set via drag-and-drop is lost (resets to default width).

Describe the solution you would like

Solutions, roughly in order of priority (imho)

  1. Save column width even when column is hidden/un-hidden
  2. Expose column width value setting in the UI and API
  3. Option to reset column width in a table to default value (both individual columns or entire table)
  4. Option to minimize column width based on content width (both individual columns or entire table)
  5. Propagate column widths from source table to new Summary tables (nice to have - much less important if number 2 above is added)
@dsagal
Copy link
Member

dsagal commented Jan 6, 2025

Since the same table can be present in multiple views (different pages or even different widgets within the same page), the same column can also be present in multiple views. I think it would be unexpected if resizing a column in one widget automatically resized it in all others, no? How do you envision exposing it via the API? Does it need to be per-widget, or do you feel a column setting (one across all widgets) is sufficient?

@dcnadler
Copy link
Author

dcnadler commented Jan 7, 2025

@dsagal, good question. I tend to not have more than one view of my tables so did not think of that.

It looks like other column styling is not currently accessible via API. Those (e.g. column visible/hidden, header style, etc.) would face the same per-widget question.

Based on that, and how the current styling can be "common" or "separate" for tables with multiple views, I would argue the column width property should follow the same flow as column stylings (set in the Column Right-Hand Panel, can be common or separate). If those styling options are added to the API, then column width can be added, as well.

Another approach is to keep the column-width properties in the Table Right-Hand panel where columns are ordered/hidden. Those are always unique to each widget, so any time you create a new table widget view the widths would all be default (just as all columns are unhidden and ordering follows the raw-data column order). Again, if those properties (column order/hidden) are ever exposed to the API, column width could be added with them.

I would argue for the first approach, since the width of the cell contents is not going to change between views so I would guess most of the time people would want the same column size for a given column (but you could choose "separate" in the rare cases when that doesn't hold).

Let me know what you think, thanks!

@dsagal
Copy link
Member

dsagal commented Jan 14, 2025

That makes sense. I am not sure the default should be "common" (again because I'd find it surprising if resizing a column in one page were to resize it in others), but I agree that the "common" setting is useful, and sometimes better.

Until this exists, there is actually an undocumented way to get at reading and setting this data via API. Here's a recipe:

  1. Find the widget of interest, and find its "section ID" by getting an anchor link to one of its cells. The Command-A shortcut (if on Mac) copies it to clipboard. E.g. a cell in top left widget in https://templates.getgrist.com/doc/lightweight-crm/p/1 would produce an anchor link like https://templates.getgrist.com/doc/lightweight-crm/p/1#a1.s1.r20.c2. The .s1. portion near the end identifies the widget (or section) -- its ID is 1.
  2. Now in the API, query the table _grist_Views_section_field with filter {"parentId": [1]} (the number is the value from the first step). For example, for the Lightweight CRM document, it would be the API call https://templates.getgrist.com/api/docs/pxbVqx6vtbx6GbdhDNpsFy/tables/_grist_Views_section_field/records?filter=%7B%22parentId%22%3A%20%5B1%5D%7D
  3. This returns a list of all "fields" (i.e. visible columns) in this section. Their "width" property is the width of the field in pixels.
  4. You can update width by making PATCH request to that same endpoint, using the field IDs.
  5. Each field refers to a column, identifying it using its colRef property, and which can be fetched using the /columns API endpoints if you want to know their names or types.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants