--- title: "Rocket Chat Componentisation Guide" slug: "componentization" description: "Learn about componentisation in Rocket Chat. Build modular, secure components to enhance collaboration tools." updated: 2026-02-19T12:12:54Z published: 2026-02-19T16:07:39Z canonical: "developer.rocket.chat/componentization" --- > ## Documentation Index > Fetch the complete documentation index at: https://developer.rocket.chat/llms.txt > Use this file to discover all available pages before exploring further. # Componentization In Rocket.Chat, a component is a reusable piece of code that represents a single UI element. Components can be [simple](/v1/docs/componentization#simple-components) or [complex](/v1/docs/componentization#complex-components) and [visual](/v1/docs/componentization#visual-components) or [logical](/v1/docs/componentization#logical-components). There are various guidelines governing each component type. Components can be defined either at the **Application level** or within the **Fuselage library**. - **Application components** are specific to a particular Rocket.Chat application. They may include product-specific logic or behavior and are not intended to be reused across different applications. - **Fuselage library components** are reusable across all Rocket.Chat applications. They implement shared UI patterns and primitives and should be used whenever possible to ensure consistency and maintainability across the ecosystem. ## Components rules matrix The following matrix defines where each type of component should live: | **Combination** | **Fuselage level** | **Application level** | | --- | --- | --- | | Simple & Visual | ✅ | ❌ | | Complex & Visual | ✅ | ✅ | | Simple & Logical | ❌ | ❌ | | Complex & Logical | ❌ | **✅** | ## Simple components These are the lowest level of components. They represent a single, atomic UI element in the interface, such as a `button` component or a text field. ### Variation over styles Use prop names that suggest the variation of a component, rather than using style-based prop names. For example, instead of using a prop name like `color` with a value of `blue`, you could use a prop name like `variation` with a value of `primary`. This makes the code more readable and maintainable, and it also makes it easier to create consistent and reusable components. ![](https://cdn.us.document360.io/27ca1fd4-36d7-4cde-b4eb-97fc1652954c/Images/Documentation/image(88).png) ### Avoid using hardcoded values or magic numbers ✅ **Preferred example**: Use the 'small' and 'square' props to dynamically adjust the component size. ```xml ``` ❌ **Not recommended**: Defining component size using specific numeric values. ```xml ``` ### Opt for customization via CSS variables Avoid the use of random CSS values and instead prioritize customization by using CSS variables. ```css $modal-margin: theme('modal-margin', auto); .rcx-modal {     position: static;     display: flex;     width: 100%;     max-height: 100%;     margin: $modal-margin; } ``` ### Document and display all variations in Storybook Ensure that all possible variations are documented and showcased within Storybook. This enables developers and designers to explore the full range of available options. Additionally, include descriptive explanations for variations that might not be self-explanatory. ![](https://cdn.us.document360.io/27ca1fd4-36d7-4cde-b4eb-97fc1652954c/Images/Documentation/image(89).png) ### Unit testing for all possible component behaviors Ensure comprehensive coverage of all intended component behaviors through unit tests. It's crucial to highlight the importance of writing unit tests that cover all possible scenarios and functionalities of the component. This practice helps ensure the reliability and correctness of the codebase. ```typescript describe('[Menu Component]', () => {   const menuOption = screen.queryByText('Make Admin');   it('should renders without crashing', () => {     render();   });   it('should open options when click', async () => {     const { getByTestId } = render();     const button = getByTestId('menu');     userEvent.click(button);     expect(await screen.findByText('Make Admin')).toBeInTheDocument();   });   it('should have no options when click twice', async () => {     const { getByTestId } = render(); const button = getByTestId('menu');     userEvent.click(button);     userEvent.click(button);     expect(menuOption).toBeNull();   });   it('should have no options when click on menu and then elsewhere', async () => {     const { getByTestId } = render();     const button = getByTestId('menu');     userEvent.click(button);     userEvent.click(document.body);     expect(menuOption).toBeNull();   }); }); ``` ### Avoid box components The usage of `Box` is recommended for Simple or Complex Components mainly (save the cases when we need to quickly prototype a component) on the Application level as it's a wildcard component, for simple components, we suggest avoiding it and building the component using HTML tags ## Complex components Complex components are made up of multiple simple components. They can be used to create more complex UI elements, such as a modal or a table. ### Only visual, no logic Concentrate solely on the user interface design, ensuring it is poised to incorporate the required logic seamlessly. ![](https://cdn.us.document360.io/27ca1fd4-36d7-4cde-b4eb-97fc1652954c/Images/Documentation/image(90).png) ### Split the component in an easy to understanding way ```typescript export const Default = () => {                                         Modal Header                                         Modal Body                                                                         }; ``` ### Initiate your development process by adopting Storybook This facilitates the separation of logic from the user interface. ```typescript export const CallingDM: ComponentStory = () => (                                        Calling...                              Join             Waiting for answer               ); export const CallEndedDM: ComponentStory = () => (                                        Call ended                               Call Back             Call was not answered               ); ``` ### Child Components can't be used outside of the scope ❌ Incorrect example of component composition: ```typescript export const MyComponent: ComponentStory = () => (            
            Call ended        
   
); ``` ✅ Correct example of component composition: ```typescript export const MyComponent: ComponentStory = () => (            
                                                Call ended                                    
   
); ``` ### HTML elements, box, and box props should be encapsulated Encapsulation is a valuable software design principle that enhances code quality. By defining clear responsibilities for components, it improves understanding, maintenance, and testing. In the context of HTML elements, Box components, and Box props, encapsulation means accessing them solely through the Box component's API. This prevents unintended modifications to the Box component's internal state, ensuring predictable behavior and streamlined debugging. ❌ Incorrect example of component composition: ```typescript export const VideoConfMessage: ComponentStory = () => (                                    
My Text
       
   
); ``` ✅ Correct example of component composition: ```typescript const VideoConfMessage = ({ ...props }): ReactElement => (     ); ``` ### Provide hooks as helpers In the following example, the **useVideoConfControllers** hook is provided as a helper to manage the state of the popup's controllers. ```typescript export const useVideoConfControllers = (     initialPreferences: controllersConfigProps = { mic: true, cam: false }, ): { controllersConfig: controllersConfigProps; handleToggleMic: () => void; handleToggleCam: () => void } => {     const [controllersConfig, setControllersConfig] = useState(initialPreferences); const handleToggleMic = useCallback((): void => {         setControllersConfig((prevState) => ({ ...prevState, mic: !prevState.mic }));     }, []);     const handleToggleCam = useCallback((): void => {         setControllersConfig((prevState) => ({ ...prevState, cam: !prevState.cam }));     }, []);     return {         controllersConfig,         handleToggleMic,         handleToggleCam,     }; }; ``` ```typescript const { controllersConfig } = useVideoConfControllers(); return (                                                                                                      ); ``` ### Understanding the component and defining the scope New components typically emerge from requirements put forth by the Product Design Team. The front-end engineer holds the responsibility of assessing the genuine necessity of such components. Due to the substantial effort involved in creating a new component, it is prudent to collaborate with product managers and designers. It is advisable to explore the feasibility of employing Complex Components as an MVP to validate concepts and user flows. Subsequent to successful validation, the progression to developing a new Fuselage level component can be considered. How do I know my component should be part of the Fuselage library? Consider the `VerticalBar` component as a clear example. It began as a Complex Component for a single application but has now advanced to the Fuselage level. This shift is driven by its usefulness in multiple applications, like Rocket.Chat and Cloud Portal. This case demonstrates how components can grow from specific solutions to versatile tools with broader applications. ## Logical Components ### Use the child components to compose a logical complex component Leverage the integration of child components to construct a unified and logical complex component. ```typescript const OutgoingPopup = ({ room, onClose, id }: OutgoingPopupProps): ReactElement => {     const t = useTranslation();     const videoConfPreferences = useVideoConfPreferences();     const { controllersConfig } = useVideoConfControllers();          return (                                                                                                                                              ); } ``` ### Customization through the variations Provide users with the ability to customize a component's appearance or behavior by selecting from predefined variations or options. This approach enhances user experience and flexibility in adapting components to specific requirements. ```typescript ``` ```typescript const VideoConfController = ({ icon, active, secondary, disabled, small = true, ...props }: VideoConfControllerProps): ReactElement => {     const id = useUniqueId();    return (              ); }; ``` ### Avoid direct styles Refrain from applying direct styles to components. By avoiding inline styling, the code maintains a cleaner structure and promotes better separation of concerns, enhancing maintainability and readability. ```typescript                                                                                                  ``` ### Don't write CSS styles in JS files This approach separates your component's logic from styling, promoting better code organization and maintainability while avoiding inline CSS-in-JS styling. Define your custom styling in an external CSS file: ```css /* styles.css */ .customClass {     border: 1px solid black;     padding: 1.5rem; } ``` Then, apply the class to your component: ```typescript import './styles.css'; return (                                                                                       );             ``` ### Use the states of the component By using component states to conditionally render different complex components, you maintain a clear and organized structure in your code, enhancing readability and maintainability. ```typescript if (isReceiving) {     return ``` Each state should render the proper Complex Component: ```typescript const OutgoingPopup = ({ room, onClose, id }: OutgoingPopupProps): ReactElement => {     const t = useTranslation();     const videoConfPreferences = useVideoConfPreferences();     const { controllersConfig } = useVideoConfControllers();          return (                                                                                                                                                 ); } ``` ## Visual components **Visual components** are responsible for the appearance of a UI element. They define the element's style, layout, and other visual properties. Adhering to guidelines in the Fuselage's componentization offers the value of modular, reusable, and maintainable UI components. This approach enables efficient development, ensures consistent behavior, and supports the evolution of solutions from specific contexts to broader applications. By encapsulating logic, avoiding direct styles, and leveraging API-driven customization, developers can create a streamlined and user-centered experience.