This content originally appeared on DEV Community and was authored by Eduardo Henrique Gris
Introduction
Portuguese version: Biblioteca de componentes React e typescript, parte 7: encerramento
We've reached the final part of the series! The goal of this article is to wrap things up by explaining the motivation behind creating the series, where the topics covered came from and sharing some possible/suggested next steps for improvement.
Motivation
Throughout my time working in development, I had the opportunity to work on projects for different clients using React with Typescript. As I dove deeper, I came across several things that caught my attention like pre-commit hooks, code auto-generation with hygen, among others, which sparked my curiosity about how to configure each of them, define their rules and use them effectively. I was also curious about how to create a component lib and publish it to make it available to others.
With those goals in mind, I started a personal learning project called rjs-components, where I began by configuring the lib with rollup, making the component lib available and gradually adding libs I wanted to learn how to configure and use.
After spending some time developing the lib, I realized I didn’t want to keep what I learned to myself. Instead, I wanted to share it with others, hoping it might help them in their own learning journey as well. That idea sparked the beginning of this series, and now, here we are at its conclusion.
Possible/suggested improvements
Throughout the series, I covered almost everything I used in the component library I’ve been building for study purposes. However, as the number of components continues to grow and deeper changes are made to the codebase, it's worth paying attention to some areas that could be improved.
- CHANGELOG.md documentation
Throughout the series, every change made in each version of the library was documented. However, there may be situations where it's not just about adding new features, as was the case in most of this series, but also about removing props, changing component behavior, or introducing other breaking changes.
Because of that, it's important to clearly communicate the type of change introduced in a new version. Below, I’ll share a suggestion based on an example from the study lib I mentioned in the motivation:
## 0.9.0
_May. 15, 2025_
### Breaking Changes
- remove textWeight Button property, but is possible to use textFontWeight
- remove textWeight IconButton property, but is possible to use textFontWeight
- remove textWeight Tag property, but is possible to use textFontWeight
- remove textWeight IconTag property, but is possible to use textFontWeight
### Major Changes
- update general Button default properties: sizes behavior, colors behavior, format behavior, border behavior
### General Changes
- update storybook and dependencies
- add focusColor props to Button
- add activeColor props to Button
- add disabledOpacity props to Button
- add border props to Button
- add hoverBorder props to Button
- add focusBorder props to Button
- add activeBorder props to Button
- update Button tests
- update Button docs
In the Breaking Changes section, it refers to modifications that can break the usage of components that worked in previous versions. For example, some props were removed from components, so if someone was using those props, they’ll need to switch to different ones in the new version to maintain the expected behavior.
The Major Changes section refers to significant updates that do not break the component’s usage but represent large changes that impact the default properties of the component.
The General Changes section includes updates that do not affect existing component usage but add new props to customize the components further.
- Similar types between components
As more components are created in the lib, some will share a large number of types. Instead of defining those types separately within each component’s file, it’s possible to create a single file that contains types shared across multiple components. For example, in the study lib I mentioned earlier, there is a file called Common.types.ts which holds types that are common to more than one component. One such example is the relationship between the Button component and the Tag component:
Common.types.ts
// ...
export interface CommonButtonTagProps {
text: string;
textColor?: string;
textFontWeight?: number;
textFontSize?: string;
textFontFamily?: string;
backgroundColor?: string;
format?: "square" | "semiRounded" | "rounded";
borderRadius?: string;
size?: "small" | "medium" | "large";
padding?: string;
border?: string;
icon?: React.ReactNode;
iconPlacement?: "right" | "left";
spacing?: string;
}
export interface StyledCommonButtonTagProps {
$textColor?: string;
$textFontWeight?: number;
$textFontSize?: string;
$textFontFamily?: string;
$backgroundColor?: string;
$format?: "square" | "semiRounded" | "rounded";
$borderRadius?: string;
$size?: "small" | "medium" | "large";
$padding?: string;
$border?: string;
}
And within each component, these shared interface definitions are imported and then extended with the properties that are unique to that specific component.
Tag.tsx
// ...
import {
CommonButtonTagProps,
StyledCommonButtonTagProps,
} from "../Common.types";
export interface TagProps extends CommonButtonTagProps {
type?: "default" | "success" | "alert" | "error";
}
export interface StyledTagProps extends StyledCommonButtonTagProps {
$type?: "default" | "success" | "alert" | "error";
}
// ...
Button.tsx
// ...
import {
CommonButtonTagProps,
StyledCommonButtonTagProps,
} from "../Common.types";
export interface ButtonProps extends CommonButtonTagProps {
type?: "primary" | "secondary";
hoverColor?: string;
focusColor?: string;
activeColor?: string;
disabled?: boolean;
disabledOpacity?: number;
hoverBorder?: string;
focusBorder?: string;
activeBorder?: string;
onClick?: MouseEventHandler<HTMLButtonElement>;
}
export interface StyledButtonProps extends StyledCommonButtonTagProps {
$type?: "primary" | "secondary";
$hoverColor?: string;
$focusColor?: string;
$activeColor?: string;
$disabledOpacity?: number;
$hoverBorder?: string;
$focusBorder?: string;
$activeBorder?: string;
}
// ...
- husky beyond pre-commit
Besides using pre-commit, husky allows you to use other types of git hooks, such as pre-push, post-commit, and others. To do this, inside the .husky/_ folder, you move the specific git hook file you want to use out of the _ folder but keep it inside .husky.
For those who use commit conventions, one option is to configure a library like commitlint by moving the commit-msg file from .husky/_ to .husky and then setting that file to run commitlint. This way, every time a commit is made, it will validate whether the commit message follows the defined conventions and will allow or block the commit accordingly.
- lib versioning
During the development of the lib in this series, we always updated the second version number with each change, going from 0.1.0 to 0.2.0, and so on.
The initial zero indicates that the lib is in an early stage of development, and its definitions may change at any time. It is not yet considered a stable release.
Once the library reaches a sufficient level of maturity and stability, the version is updated to 1.0.0, indicating that it is consolidated and ready for production use.
For a better understanding of semantic versioning, I highly recommend visiting https://semver.org/, which explains everything in detail.
Conclusion
The idea of this final article was to be brief, presenting the motivation behind the series and highlighting things to watch out for as the library grows. I want to thank everyone who followed along until now, I hope it has been helpful to you all.
This content originally appeared on DEV Community and was authored by Eduardo Henrique Gris
Eduardo Henrique Gris | Sciencx (2025-07-28T21:39:48+00:00) React and typescript components lib, part 7: conclusion. Retrieved from https://www.scien.cx/2025/07/28/react-and-typescript-components-lib-part-7-conclusion/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.