Skip to content

feat(metrics): implement ability to hide internal topics in charts#2297

Merged
hemahg merged 5 commits intomainfrom
add_internal_topic_switch
Feb 12, 2026
Merged

feat(metrics): implement ability to hide internal topics in charts#2297
hemahg merged 5 commits intomainfrom
add_internal_topic_switch

Conversation

@hemahg
Copy link
Contributor

@hemahg hemahg commented Feb 6, 2026

feat(metrics): implement ability to hide internal topics in charts

Screenshot 2026-02-10 at 11 15 44 AM

@hemahg hemahg marked this pull request as draft February 9, 2026 11:15
@hemahg hemahg marked this pull request as ready for review February 10, 2026 09:52
@hemahg hemahg requested a review from MikeEdgar February 10, 2026 10:15
Comment on lines 60 to 64
const isInternalTopic = (topic: TopicOption) => topic.name.startsWith('__')

const filteredTopicList = showInternal
? topicList
: topicList.filter((t) => !isInternalTopic(t))
Copy link
Member

Choose a reason for hiding this comment

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

The topics should have already been filtered by the API right? I'm not sure this is needed, and I think it's different from the topic list page where only the API filters hidden ones.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Initially I was using the includeHidden query param in the URL so the API would filter topics.
But toggling the switch updated the URL each time, which caused the whole page (server components) to re-render.
That felt unnecessarily heavy just for showing/hiding internal topics.

So instead, I fetch all topics once (including hidden ones), and then handle the internal topic filtering on the client using:

const isInternalTopic = (topic: TopicOption) =>
  topic.name.startsWith('__')

This way, toggling the switch only affects local state and doesn’t trigger a full page re-render.

It keeps the UI more responsive while avoiding extra API calls.

Copy link
Member

Choose a reason for hiding this comment

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

I see your point and I don't disagree with the concept, but the issue is that topics aren't identified by leading __ alone. There is a separate flag for internal within Kafka. I.e., I can name a topic with __ as the prefix and it would still not be internal. If you fetch all of the topics regardless or visibility, you can look at the attributes.internal value instead of filtering based on name.

Copy link
Contributor Author

@hemahg hemahg Feb 10, 2026

Choose a reason for hiding this comment

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

The popover mentions that internal topics are prefixed with __, so I initially used startsWith('__') based on that convention. But I agree it’s better to rely on attributes.internal from the API, so I’ll update it accordingly.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I have updated to show the topics based on visibility attribute

@MikeEdgar MikeEdgar added this to the 0.11.1 milestone Feb 10, 2026
Signed-off-by: hemahg <hhg@redhat.com>
@hemahg hemahg force-pushed the add_internal_topic_switch branch from 16b45dd to c57bad5 Compare February 12, 2026 13:30
@sonarqubecloud
Copy link

@hemahg hemahg merged commit 9653dc6 into main Feb 12, 2026
11 checks passed
@hemahg hemahg deleted the add_internal_topic_switch branch February 12, 2026 14:45
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.

2 participants