Non-scalable tab system

Ask the community
, ,
1

In our dashboard, we allow users to interact with various tabs, such as “Order overview,” to access specific data like recent orders. Users can view one tab at a time, add, delete, or reorder them.

Our data model includes:

Tab: This represents the tab itself, with attributes like name, tab_index, and sorting_order.
Company-Tab: Links a company to a tab.
Employee-Tab: Connects an employee to a tab, with additional attributes like sorting_order and tab_index.
In the UI, the tab_index corresponds to a container within a visibility group that displays the tab’s content. The sorting_order, an integer, lets users rearrange tabs but isn’t tied to the visibility group.

Currently, our system faces scalability issues, particularly when managing tab consistency across the Admin portal and main system. Each tab in the main system has a corresponding container within a visibility group, linked by the tab index. This setup leads to inconsistencies when tabs are added or deleted, as it requires manual updates to both the tab and its associated container.

We are seeking advice on improving this system within the Appfarm framework, looking for a more efficient way to manage tabs that ensures consistency and scalability.

2

Hi!

I have done something similar once. I understand you represent each tab as a container inside a visibility group. In my case, no visibility groups were used. Instead: A repeating container was used, repeating “Tabs” horizontally. Inside the repeating container you have access to “Context Parameter” with the iteration number, allowing you to access the tab number that was clicked in the “On Click” event of the tab-container, and you may have visibility rules or conditional styles based on the same context parameters.

1 Like