Scalable React Components
In my time as a react developer, I’d get critical feedback during my code reviews. Sometimes I wouldn’t separate my concerns when creating a component and that led me to playing a game called ‘is it reusable’?
Now I know I’ve built components that are tied to a specific feature or page of the platform but I always get interview questions on creating scalable components. Components that can be used in multiple parts of the platform and can be updated in various ways. Let’s think about a success toast.
When developing it, I’ll first start on the page that I’d like to see the success toast like maybe the login/sign up page. When a user validates themselves, they should see an success or error toast. So I’d create a component like what you see below.
import React from "react";
const Toast = ({ user, type, children }) => {
const backgroundColor = type == "success" ? "#21D375" : "#ff7f7f";
if (!user || user.registrationStatus == "unverified") return null;
return (
<div style={{ backgroundColor }}>
{children}
</div>
);
};
export default Toast;
There’s nothing wrong with this code to be honest. It’s acceptable code but you lost the game of ‘is it reusable’ because what if your UI/UX designer implements another feature that uses the success toast? Another question that should be asked is why is this Toast Component tied to user verification? I know that sometimes we code to address a specific usage but these are some question you should be asking yourself to grow as a developer. Let’s make a quick add and you’ll see the difference.
import React from "react";
const Toast = ({type, children }) => {
const backgroundColor = type == "success" ? "#21D375" : "#ff7f7f";
return (
<div className="Toast" style={{ backgroundColor }}>
{children}
</div>
);
};
export default Toast;
const VerificationToast = ({user, type, children}) => {
if (!user || user.registrationStatus == "unverified") return null;
return <Toast type={type} childredn={children} />
}
Feels like a small change but it makes a world of difference becuase it’s now scalable. Instead of using the Toast Component in my login/signup page, I can use the VerificationToast. What makes it scalable is that even if you needed a new toast, you could develop it using the Toast Component as a foundation. Some other components that you can practice this thought with are banners and maybe modals.
Anyways, I hope this helps you grasp the idea of separating concerns and programming with scalability in mind. Happy Coding!