Flexibility for developers

Oct 13, 2025 by wbrum.org 142 views

Use Case

The current implementation of TreeView in the Event Catalog automatically expands domains, services, and channels. While this makes sense for domains, it can have a negative impact on the user experience when a domain contains a large number of services. This is because the automatic expansion of services can make it harder for users to view and access other components within that domain. This can lead to a cluttered and overwhelming interface, making it difficult for users to navigate and find the information they need.

For example, imagine a domain with 20 services. When the TreeView is expanded, all 20 services will be displayed, making it hard to see the other components within that domain. This can be frustrating for users who need to access specific services or view the overall structure of the domain. By not auto-expanding services, we can provide a more organized and user-friendly interface.

Proposed Solution

There are several ways to approach this issue:

1. Remove Service from Auto-Expansion List

One possible solution is to remove services from the auto-expansion list. This would mean that services would only be expanded when the user explicitly clicks on them. This would provide more control to the user and allow them to view the services they need without cluttering the interface.

2. Only Auto-Expand if There Are Less Than X Services

Another possible solution is to only auto-expand services if there are less than X services. For example, we could auto-expand services if there are less than 5 services. This would provide a balance between user control and the need to view services.

3. Make the List Configurable via eventcatalog.config.js

A third possible solution is to make the list of auto-expanded items configurable via eventcatalog.config.js. This would allow developers to customize the behavior of the TreeView to meet their specific needs. This would provide more flexibility and control to developers.

Implementation Notes

The implementation of this change would involve modifying the getTreeView function in the SideNav/TreeView component. We would need to remove services from the auto-expansion list or add a condition to only auto-expand services if there are less than X services. We would also need to update the eventcatalog.config.js file to allow developers to configure the behavior of the TreeView.

Community Notes

Please vote by adding a 👍 reaction to the issue to help us prioritize.
If you are interested to work on this issue, please leave a comment.
If this issue is labeled needs-discussion, it means the spec has not been finalized yet. Please reach out in the EventCatalog Discord.

Benefits of the Proposed Solution

The proposed solution would provide several benefits, including:

Improved user experience: By not auto-expanding services, we can provide a more organized and user-friendly interface.
More control for users: Users would have more control over the behavior of the TreeView and would be able to view the services they need without cluttering the interface.
Flexibility for developers: Developers would have more flexibility and control over the behavior of the TreeView, allowing them to customize it to meet their specific needs.

Conclusion

Q: Why is the current implementation of TreeView auto-expanding services?

A: The current implementation of TreeView is auto-expanding services because it makes sense for domains. However, when a domain contains a large number of services, it can become overwhelming and difficult to navigate. By auto-expanding services, we can provide a more organized and user-friendly interface.

Q: What are the benefits of not auto-expanding services?

A: The benefits of not auto-expanding services include:

Improved user experience: By not auto-expanding services, we can provide a more organized and user-friendly interface.
More control for users: Users would have more control over the behavior of the TreeView and would be able to view the services they need without cluttering the interface.
Flexibility for developers: Developers would have more flexibility and control over the behavior of the TreeView, allowing them to customize it to meet their specific needs.

Q: How would you implement the proposed solution?

A: The implementation of the proposed solution would involve modifying the getTreeView function in the SideNav/TreeView component. We would need to remove services from the auto-expansion list or add a condition to only auto-expand services if there are less than X services. We would also need to update the eventcatalog.config.js file to allow developers to configure the behavior of the TreeView.

Q: What are the potential drawbacks of not auto-expanding services?

A: The potential drawbacks of not auto-expanding services include:

Increased user effort: Users would need to explicitly click on services to view them, which could be more effort than auto-expanding services.
Potential for user confusion: If users are not used to not auto-expanding services, they may become confused or frustrated with the new behavior.

Q: How would you address the potential drawbacks?

A: To address the potential drawbacks, we could:

Provide clear documentation: We would need to provide clear documentation on how to use the new behavior of the TreeView.
Offer user support: We would need to offer user support to help users understand and navigate the new behavior of the TreeView.
Gather user feedback: We would need to gather user feedback to understand how the new behavior is affecting users and make any necessary adjustments.

Q: What are the next steps in implementing the proposed solution?

A: The next steps in implementing the proposed solution would be:

Modify the getTreeView function: We would need to modify the getTreeView function in the SideNav/TreeView component to remove services from the auto-expansion list or add a condition to only auto-expand services if there are less than X services.
Update the eventcatalog.config.js file: We would need to update the eventcatalog.config.js file to allow developers to configure the behavior of the TreeView.
Test and deploy the changes: We would need to test and deploy the changes to ensure that they are working as expected.

Q: How would you measure the success of the proposed solution?

A: To measure the success of the proposed solution, we would need to:

Track user engagement: We would need to track user engagement metrics, such as the number of users who are using the new behavior of the TreeView.
Gather user feedback: We would need to gather user feedback to understand how the new behavior is affecting users.
Monitor user satisfaction: We would need to monitor user satisfaction metrics, such as the number of users who are satisfied with the new behavior of the TreeView.

Q: What are the potential long-term benefits of the proposed solution?

A: The potential long-term benefits of the proposed solution include:

Improved user experience: By providing a more organized and user-friendly interface, we can improve the overall user experience.
Increased user adoption: By making it easier for users to navigate and find the information they need, we can increase user adoption.
Better user retention: By providing a more organized and user-friendly interface, we can improve user retention and reduce the likelihood of users abandoning the application.