The Compound Component Pattern has become a popular approach in React for building flexible, reusable components. You'll often see it in two flavors: separate exports (<SelectTrigger />) or dot notation (<Select.Trigger />). But like any pattern, it comes with significant trade-offs. Let's explore both sides.
Recently, we had an in-depth discussion on structuring React applications using a layered architectural approach. This method aligns with fundamental software architecture principles such as the Single Responsibility Principle (SRP) and the Single Source of Truth (SSoT). It shares similarities with Clean Architecture and Layered Architecture and, interestingly, shows parallels with the Model-View-Controller (MVC) pattern in some respects. We are also applying Dependency Inversion principle (DIP), depending on abstractions rather than concrete implementations of lower-level modules.
When working in a React application with API calls, handling redirects in the middle of the request chain can be tricky.
When you make an API call from your frontend code to your server, and the server then makes another request that returns a redirect.
The Dependency Inversion Principle (DIP) is one of the five SOLID principles, and it plays an essential role in achieving maintainable and flexible code. It can be applied to frontend development, particularly when using technologies like React and Redux.
The usage of React.FC or React.FunctionComponent has been a subject of debate within the React community. Both approaches—using it or not—have their pros and cons.
React.FCIMHO, do not use React.FC or React.FunctionComponent in your codebase, only if you know you are using children props.
SSR stands for Server-Side Rendering. It's a technique used in web development where the content of a web page is generated on the server instead of in the user's browser.
SSR stands for Server-Side Rendering. It's a technique used in web development where the content of a web page is generated on the server instead of in the user's browser. This differs from client-side rendering (CSR), where JavaScript runs in the browser to produce the page's content dynamically.
The rationale behind creating a component like the ImagePlaceholder in React, especially in a web application that handles a significant amount of images, centers on improving user experience and performance.