Broker Topic Hierarchy UI

[cstns]

Description

• add the mqtt broker page under the unified-namespace namespace
• add the new topic hierarchy page under the same namespace
• addressed the permissions composable reactivity problem which bit me sooner than expected

Was not able to re-use the existing accordion component because it was toggling the visibility of it's children which caused problems when rendering high numbers of topics. Ended up creating simpler a TopicSegment component which improved DOM rendering due to it not inserting the node in the dom only when acted upon.

Was able to render 1500 topic entries with 100 nested topics with ease.

Related Issue(s)

closes #4752

Checklist

• I have read the contribution guidelines
• Suitable unit/system level tests have been added and they pass
• Documentation has been updated
  • Upgrade instructions
  • Configuration details
  • Concepts
• Changes flowforge.yml?
  • Issue/PR raised on FlowFuse/helm to update ConfigMap Template
  • Issue/PR raised on FlowFuse/CloudProject to update values for Staging/Production

Labels

• Includes a DB migration? -> add the area:migration label

[hardillb]

Does this want to target the other PR branch first?

[cstns]

yes, my bad! Thank you for pointing it out!

I'll need a couple of hours to solve the e2e tests though

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 78.72%. Comparing base (5475a81) to head (c27a4f5).
Report is 30 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #4790   +/-   ##
=======================================
  Coverage   78.72%   78.72%           
=======================================
  Files         314      314           
  Lines       15053    15053           
  Branches     3457     3457           
=======================================
  Hits        11851    11851           
  Misses       3202     3202           

Flag	Coverage Δ
backend	78.72% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

---

🚨 Try these New Features:

• Flaky Tests Detection - Detect and resolve failed and flaky tests
• JS Bundle Analysis - Avoid shipping oversized bundles

[hardillb]

Totally first impressions, just thinking out loud

• I think the entry on the left should still be "Broker" not "UNS"
• Need to decide what order the Clients, Hierarchy tabs need to be in
• Need to think about the topic count on each row, showing 1 for test/ feels wrong when bill/ has 2

Otherwise looks good

[hardillb]

Just asking to see how hard it would be, to remember expanded levels (only for while the page is currently open).

e.g. currently if I fully expand a topic tree, but then collapse the first element, when I re-expand that element again all the children have been collapsed, might be useful to be able to keep state for the lower elements

[hardillb]

The counts and the order we can iterate on afterwards

[cstns]

We are also restricting the use of the mqtt broker for self-hosted installations, are we keeping it in place this release?

[joepavitt]

@cstns you have a merge conflict

[knolleary]

Tidies up some language in the UI

In terms of usability of the Topic Hierarchy - the key missing piece is it's actually quite hard to then get the full topic being used in a way I can copy/paste elsewhere.

Here I have published to the topic p1/line/factory/foo/p2/foo - and whilst I can see that in the hierarchy, if I want to use that value elsewhere, I have to still manually type it out.
A quick win would be to add a 'copy topic' button on the 'leaf' nodes of the tree that copies the fully formed topic string to my clipboard.

[cstns]

In terms of usability of the Topic Hierarchy - the key missing piece is it's actually quite hard to then get the full topic being used in a way I can copy/paste elsewhere.

I wouldn't call it a missing piece, I don't remember it being mentioned before and it wasn't part of the requirements. It would be a nice addition but not in the format that I'm parsing the API response at the moment.

It can be easily implemented when tackling the topics count and remembering which topics were opened features @hardillb requested

[knolleary]

I wouldn't call it a missing piece, I don't remember it being mentioned before and it wasn't part of the requirements.

To clarify - I acknowledge this was not in the original design, so I'm not say you missed anything that had been previously suggested.

I will raise a separate item for it as we don't need to block this for release - however I strongly feel we should iterate on it quickly.