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
Persist search page column width #27
Comments
If this is something we want to fix, I'd like to work on this as well :) |
This is a good point! I think it'd be nice to persist column widths. I think a few gotchas to answer would be:
I think we can introduce a reset button in the log table when the widths are customize/persisted, there might be a "smart" way to do it automatically, but I can't think of a good action to auto-reset the widths.
I think for now the easiest way is to simply only persist the column widths on the search page, maybe the LogTable component can take a flag for whether column widths should be persisted locally. An alternative is that each LogTable get assigned some unique/persistent id, and in local storage each LogTable id has its own corresponding set of custom sizes. This seems more complicated (LogTables don't have persistent ids today) and likely a good v2 of this issue.
Today they're custom columns are ephemeral and in the future they may be DB persisted, I don't think this matters as the message column will "soak up" any excess column widths, but I guess there might be an edge case where if you add too many columns, it'll make the LogTable wonky/break when it's trying to restore persisted column widths. Anyways those issues aside, would love to have you take this on if you'd like! You can use the |
@MikeShi42 Thank you for the notes above, I have a draft PR ready for review.
I have added option in header next to "Show Log Patterns" as "Reset Column Sizes"
Column sizes require "tableId" prop for column sizes to work, the ID is used for storage. the ID prop ideally is unique per table. I did debate on taking the URL path into consideration when saving to storage, as that would mean the column sizes are unique per URL and per table. but I didn't want to over complicate it for now. I can add that if we want to go that route.
I haven't really found an elegant solution to this, looking for any feedback here. I have used "any" ts type, I haven't found a way to get around it, any help appreciated here as well. |
Current scenario:
Could maybe leverage local storage to store column width and persist that locally on the browser.
The text was updated successfully, but these errors were encountered: