Skip to content

Conversation

@shahrokni
Copy link
Contributor

@shahrokni shahrokni commented Feb 4, 2026

Description 🖊️

This PR is moving the filtering section of the Table Panel (from plugin side) into the Table component (shared repo)

As previously discussed, the table and the filter should be logically integrated. Currently, they are treated as separate entities. An investigation of the Table plugin reveals that the filter section was added as a later addition on top of the existing Table component.

The PR

  • Moves the filter section into the Table component, ensuring they are fully integrated.
  • Replaces the JSX elements with the MUI

⚠️ To test this feature you need to flip filteringEnabled value

⚠️ This is not a breaking change, as there are no visual regressions. The component's props interface remains unchanged.

Subsequent Changes 🏃🏼

After the PR is merged, and the shared version is updated in the plugin

  1. The filter section from the Plugin side could be removed
  2. The optional filteringEnabled should be set to true
image image

Checklist

  • Pull request has a descriptive title and context useful to a reviewer.
  • Pull request title follows the [<catalog_entry>] <commit message> naming convention using one of the
    following catalog_entry values: FEATURE, ENHANCEMENT, BUGFIX, BREAKINGCHANGE, DOC,IGNORE.
  • All commits have DCO signoffs.

UI Changes

  • Changes that impact the UI include screenshots and/or screencasts of the relevant changes.
  • Code follows the UI guidelines.
  • E2E tests are stable and unlikely to be flaky.
    See e2e docs for more details. Common issues include:
    • Is the data inconsistent? You need to mock API requests.
    • Does the time change? You need to use consistent time values or mock time utilities.
    • Does it have loading states? You need to wait for loading to complete.

@shahrokni shahrokni force-pushed the feat/add_filter_to_table_component branch 3 times, most recently from e30243a to 6052c97 Compare February 4, 2026 13:07
@shahrokni shahrokni marked this pull request as ready for review February 4, 2026 13:10
@shahrokni shahrokni requested a review from a team as a code owner February 4, 2026 13:10
@Gladorme
Copy link
Member

Gladorme commented Feb 4, 2026

Nice to move to MUI components, it's better for the coherence.

But I think we should improve the current display too. Maybe not related to this PR, but currently the width is really small + misplaced (not located under the button).

@jgbernalp
Copy link
Contributor

jgbernalp commented Feb 4, 2026

But I think we should improve the current display too. Maybe not related to this PR, but currently the width is really small + misplaced (not located under the button).

Agree, the filter somehow does not align with the column, so there is no context of what I'm filtering.

@shahrokni
Copy link
Contributor Author

shahrokni commented Feb 4, 2026

But I think we should improve the current display too. Maybe not related to this PR, but currently the width is really small + misplaced (not located under the button).

Agree, the filter somehow does not align with the column, so there is no context of what I'm filtering.

For the misalignment I found and opened a an issue yesterday. This is not coming from this change and has been there from the beginning.

Look at this

perses/perses#3835

I am not really sure, what would be the best way to keep them aligned in case the table scrolls.
The filter section has no clue about the scrolled table. :(

I don't want to spend too much time over UI improvements in this task. So, could we think about the misalignment issue later?

@jgbernalp
Copy link
Contributor

Yes it was suggested already by @Gladorme. We agree there is an issue, but we know is not part of these changes, it existed before.

@shahrokni shahrokni force-pushed the feat/add_filter_to_table_component branch 2 times, most recently from 561a827 to 3c55b41 Compare February 4, 2026 17:36
Signed-off-by: Mahmoud Shahrokni <seyedmahmoud.shahrokni@amadeus.com>

Signed-off-by: Mahmoud Shahrokni <seyedmahmoud.shahrokni@amadeus.com>

Signed-off-by: Mahmoud Shahrokni <seyedmahmoud.shahrokni@amadeus.com>

Signed-off-by: Mahmoud Shahrokni <seyedmahmoud.shahrokni@amadeus.com>

Signed-off-by: Mahmoud Shahrokni <seyedmahmoud.shahrokni@amadeus.com>

Signed-off-by: Mahmoud Shahrokni <seyedmahmoud.shahrokni@amadeus.com>

Signed-off-by: Mahmoud Shahrokni <seyedmahmoud.shahrokni@amadeus.com>
@shahrokni shahrokni force-pushed the feat/add_filter_to_table_component branch from 3c55b41 to 9aed6a8 Compare February 5, 2026 09:24
@shahrokni
Copy link
Contributor Author

shahrokni commented Feb 5, 2026

Yes it was suggested already by @Gladorme. We agree there is an issue, but we know is not part of these changes, it existed before.

I improved the size, so it fits the filter header. It has been demonstrated in the screenshots attached to description. There is still an old issue with the hidden dropdown when it gets lengthy. This should be addressed with a separate PR.

image

It would be great if you could review now.

const values = [...new Set(allValues)].filter((v) => v !== null).sort();

if (!values.length) {
return (
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should render this dropdown inside a Portal, this will avoid the clipping. The table plugin uses it's own implementation which also has this issue. But fixing it here will make it consistent for both logs and table plugins.

position: 'absolute',
top: '100%',
left: 0,
zIndex: 9999,
Copy link
Contributor

@jgbernalp jgbernalp Feb 5, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
zIndex: 9999,
zIndex: 1000,

This will make it above other elements but below the sticky header, when using the Portal

Copy link
Contributor Author

@shahrokni shahrokni Feb 6, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

const [filterAnchorEl, setFilterAnchorEl] = useState<{ [key: string]: HTMLElement | undefined }>({});

I was checking your comment when I realized there is no usage of this sate in the code. This is coming from the original code. Even in the original code this line has no usage! Am I mistaken, is there any usage that I am missing?! filterAnchorEl is never used for any kind of calculations. I think, the dropdown used to be a popover. Later changed, and this line became obsolete. I am not sure though.

Update

OK, a bit of this a bit of that! I guess the original idea was to use an anchor and MUI popover.
Looks nice!

⚠️ IMPORTANRT: Popover is a kind of modal. It covers the entire page, so elements beneath the Popover could not be reached as long as the Popover is not closed.

image

Signed-off-by: Mahmoud Shahrokni <seyedmahmoud.shahrokni@amadeus.com>
@shahrokni shahrokni requested a review from jgbernalp February 6, 2026 12:12
@Gladorme
Copy link
Member

Gladorme commented Feb 6, 2026

There is an issue when there is a lot of columns, you can scroll content (horizontal scroll). But you can't scroll filtering. And like it's not linked, it will hard to tell which button is sorting what :/

I guess it will not be easy 😅 I like how MUI is doing it the filtering (display icon if filtering enabled next to header + setup taking all place necessary), but I don't know if we can/want do the same here

image image image

Example, I have more than 10 columns and you can only see ~6 filters
image
image

@jgbernalp
Copy link
Contributor

Yes this just uncovered a big issue with our current table, we probably should migrate and use a DataGrid instead which already has all these features.

@shahrokni
Copy link
Contributor Author

Yes this just uncovered a big issue with our current table, we probably should migrate and use a DataGrid instead which already has all these features.

The issue that you mentioned (misalignment of the table and filtering row) already exists, and there is even an open issue for it. I would like to suggest that we should avoid going deep into existing UI/UX issues with the table component at the moment. The main idea behind this change was to be able to use the Transforms for the logs (which were missing so far) as well which brings a huge value. If you allow me, we can continue with what we have today, and address that issue with its own ticket.
What do you think?

@Gladorme
Copy link
Member

Gladorme commented Feb 9, 2026

Ah yes, I did not see issue: perses/perses#3835. I don't understand how it's blocking Transform refactor. It's should not be related. Currently only Table plugin is impacted by this filtering feature, I don't think it's a good idea to increase its scope, if it's not working well.

@jgbernalp
Copy link
Contributor

I understand we want to proceed and I don't want to block any progress. But I believe a better use of our time would be to migrate to the DataGrid, this way we won't have to patch something that we will throw away in the next release. Any thoughts @AntoineThebaud @Nexucis ?

@shahrokni
Copy link
Contributor Author

@jgbernalp

The official MUI data grid component.

Virtualization, sorting, and filtering are built-in for the free "Community" version.
Advanced features like Excel export or row grouping require a Pro/Premium license.

Are we ok with the advanced feature licening?

@shahrokni
Copy link
Contributor Author

shahrokni commented Feb 9, 2026

I understand we want to proceed and I don't want to block any progress. But I believe a better use of our time would be to migrate to the DataGrid, this way we won't have to patch something that we will throw away in the next release. Any thoughts @AntoineThebaud @Nexucis ?

Never got blocked by you so far. Received 99.99% constructive comments 😄

Just keep an eye on this as well, makes me a bit nervous
#55 (comment)

@jgbernalp
Copy link
Contributor

Yeah that's not the only one there: https://www.ag-grid.com/

@Gladorme
Copy link
Member

Gladorme commented Feb 9, 2026

Yeah, moving to DataGrid may be a better idea for Table plugin. I think, we still want to keep Perses "Table" component for basic stuff (example usage in TimeSeriesChart legend)?

The advanced features can be implemented on our side. The only thing I fear is theming/customization when we will move to the new UI (perses/perses#3570) depending on the one used 😅

@shahrokni
Copy link
Contributor Author

Yeah that's not the only one there: https://www.ag-grid.com/

OK, I am ready to takeover the table replacement task. I just need a final approval.

Are we good to go?

@andreasgerstmayr
Copy link

Are we good to go?

I'm in favor of switching to a table component which includes basic functionality like filtering etc., I also think implementing this basic functionality on our own is not a good use of our time :)

fyi, here's the old issue about which table library to use: perses/perses#1143

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

Successfully merging this pull request may close these issues.

4 participants