In Rocket.Chat, a component is a reusable piece of code that represents a single UI element. Components can be simpleor complex and visual or logical. There are various guidelines governing each component type.
These components can either live on the Application or the Fuselage library.
Application components are specific to a particular Rocket.Chat application. They are not reusable across applications.
Fuselage library components are reusable across all Rocket.Chat applications. They are the recommended way to create components for Rocket.Chat applications.
Components Rules Matrix
The components rules matrix includes the table below:
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.
Avoid using hardcoded values or magic numbers.
✅ Preferred example: Use the 'small' and 'square' props to dynamically adjust the component size.
Ensure that all possible variations are documented and showcased within the 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.
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.
describe('[Menu Component]', () => {constmenuOption=screen.queryByText('Make Admin');it('should renders without crashing', () => {render(<Simple {...Simple.args} />); });it('should open options when click',async () => {const { getByTestId } =render(<Simple {...Simple.args} />);constbutton=getByTestId('menu');userEvent.click(button);expect(awaitscreen.findByText('Make Admin')).toBeInTheDocument(); });it('should have no options when click twice',async () => {const { getByTestId } =render(<Simple {...Simple.args} />);constbutton=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(<Simple {...Simple.args} />);constbutton=getByTestId('menu');userEvent.click(button);userEvent.click(document.body);expect(menuOption).toBeNull(); });});
Avoid Box Component
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 .
Split the component in an easy to understanding way
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.
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.
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.
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.
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:
By using component states to conditionally render different complex components, you maintain a clear and organized structure in your code, enhancing readability and maintainability.
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.
Last updated
Rocket.Chat versions receive support for six months after release.