![]() ![]() ![]() Don't be afraid to repeat yourself multiple times before a pattern emerges. Avoid creating components early on (i.e.Conclusionīuilding reusable components isn’t easy but following a few rules and principles can save you a lot of time in the future. This way, you can always change how the component should be rendered based on props and updating all instances can be done in one single isolated change. Something like variant: "default" | "withBorder" is more resilient since you can add more options later without breaking the API. Adding a boolean prop like withBorder might feel sufficient now but it can lead to a bloated API and impossible states in the future. The simplest solution is to eliminate the BigComponent completely by inlining the child components directly: īe careful when modeling props interface and consider how the pattern can evolve in the future. Now letʼs assume you are doing this on purpose because you want the layout of the BigComponent look differently under different circumstances. No matter where you going to render BigComponent, all its children are going to be contained in the div element. ![]() This change might look like an unnecessary one (we introducing an additional DOM nesting □) but it prevents this sort of issues. Recently, during code reviews, I noticed developers would return a React.Fragment from a component like this: export function BigComponent ( ) This is well explained in “ Margins and Composability in CSS” by and “ Margins considered harmful” by Components should not implicitly rely on their context. Components should not have an effect outside of their boundaries. And reusable components don't make assumptions about where they will be used.ġ. ![]()
0 Comments
Leave a Reply. |