I am leading the development of an enterprise-level Angular application and integrating Storybook for isolated component development. Our designs are specified in Figma, ensuring consistency across our UI components. Given the complexity and the numerous UI permutations influenced by different states and data, I am evaluating two different approaches to managing our component architecture effectively:

Direct HTML Manipulation: Involves creating all UI elements directly within the HTML of smart components using helper functions and Angular’s conditional directives (*ngIf, *ngFor). This approach has been straightforward in implementation, but I have concerns about its scalability and maintainability as the complexity of the project increases.

Configuration Object Approach: This method develops a system that generates a configuration object for each smart component, which is subsequently utilized by ‘dumb’ components to render the UI. It aims to reduce the complexity within smart component templates and delegate most of the rendering logic to reusable dumb components.

Considering our use of a structured design system with components pre-designed in Figma and prototyped in Storybook, which of these approaches would be more scalable and maintainable? I am particularly interested in insights from your experiences or any relevant studies or documentation you might share.

Thanks

What I Tried:

I’ve begun prototyping with two different architectural strategies for our Angular-based enterprise application. Initially, I implemented several smart components with extensive logic within the HTML using Angular’s built-in directives for conditional rendering and loops. Concurrently, I explored an alternative where I created a configuration object for each component that dictates the rendering of both smart and dumb components.

What I Expected:
For the direct HTML manipulation approach, I expected a straightforward implementation but was concerned about potential scalability issues as the application grows. With the configuration object approach, my expectation was to achieve a more modular and maintainable system, albeit with a possibly steeper learning curve for the team.

What Actually Happened:
The direct HTML manipulation was indeed quicker to implement but started to get cumbersome as the complexity of the application increased. The configuration object approach seemed promising in terms of organization and scalability, but some team members found it challenging to grasp, and it introduced an initial overhead in development time.