DEV Community: Sandhya-Allgandhuala

Building the Login Page in React with Reusable Components

Sandhya-Allgandhuala — Sun, 05 Jul 2026 03:55:59 +0000

Introduction

Building a login page for the Smart Budget Tracker app using the reusable components we discussed in our previous post — please check that post out before following along here.
To build this component, we need two text inputs (for email/username and password), a login button, and API calls to send the authentication request and receive the authorization response.

Defining the Login Page Interface and Setting Up Required Hooks

Below is LoginForm, the required fields for the login page — both fields accept strings.

We define the states required for this form:

loginForm state with initial values as empty strings
loading state with an initial value of false
error state with an initial value of an empty string

interface LoginForm {
    email: string;
    password: string;
}

function Login() {
    const [loginForm, setloginForm] = useState<LoginForm>({
        email: '',
        password: '',
    });
    const [loading, setLoading] = useState(false);
    const [error, setError] = useState('');

Reusable Components to Build the Login Page

    return (
        <div className="flex">
            <LoginSideBar />
            <main className="w-1/2  bg-[#1a7a5e] border-r flex flex-col px-6 py-6 sticky top-0 h-screen justify-center overflow-y-auto">
                <div className='items-center justify-center text-center'>
                    <h1 className='text-xl'>Welcome Back</h1>
                    <p className='text-sm'>Sign in to your account to continue</p>
                </div>
                <form className="auth-form" onSubmit={handleSubmit}>
                    <TextInput
                        label="Email Address"
                        name="email"
                        type="email"
                        placeholder="Sample@SmartBudget.com"
                        value={loginForm.email}
                        onChange={handleChange}
                        error={error}
                        disabled={loading}
                        leftIcon={<img src={emailIcon} alt="email" width={18} height={18} />}
                    />
                    <TextInput
                        label="Password"
                        name="password"
                        type="password"
                        placeholder="********"
                        value={loginForm.password}
                        onChange={handleChange}
                        leftIcon={<img src={lockIcon} alt="lock" width={18} height={18} />}
                        rightAction="Forgot password?"
                        error={error}
                        disabled={loading}
                        maxLength={12}
                        hint="Only 12 characters are allowed"
                    />
                    <Button
                        label="Log in"
                        type="submit"
                        variant="primary"
                        fullWidth
                        loading={loading}
                    />
                </form>
                <p>Don't have an account? <Button label="Register Free" href="/Register" className="btn-base btn-ghost btn-md" /></p>
            </main>
        </div>
    );

By keeping TextInputand Buttongeneric and fully controlled through props, we avoid duplicating markup and styling logic across the form. The parent component Loginowns the state, validation, and submit logic, while the child components simply render based on the props they receive — this keeps the login page lightweight and lets us reuse the same components anywhere else a form input or button is needed

Both inputs share the same error prop, sourced from a single error state in the parent component. This means any authentication error — such as "Invalid credentials" — is displayed under both fields rather than being tied to one specific input. If you need field-level validation later (e.g., "Email is required" vs. "Password is too short"), you'd extend this into an object shape like { email: string; password: string } and pass the relevant key to each input.

Notice that Button is used two different ways in this form: once as a type="submit" trigger inside the form, and once as a navigational link (via the href prop) for the "Register Free" action. This is another example of a single reusable component adapting its behavior based on the props it's given, rather than needing separate Button and Link components for each case.

HandleChange and HandleSubmit Functions

setLoginForm({ ...loginForm, [e.target.name]: e.target.value }); This line runs every time the user types something in the email or password box.

e.target.name tells us which input the user is typing in — either "email" or "password".
e.target.value is what the user typed.
...loginForm copies the current state (both email and password) so we don't lose the other field's value.
[e.target.name]: e.target.value then updates just the one field that changed.

This way, one function can handle changes for both inputs, instead of writing separate functions for email and password.
Example: If the user types "a" in the email box, the state becomes { email: "a", password: "" } — the password stays the same, only email updates.

 const handleChange = (e: React.ChangeEvent<HTMLInputElement>) => {
        setLoginForm({ ...loginForm, [e.target.name]: e.target.value });
    };

    const handleSubmit = async (e: React.SyntheticEvent<HTMLFormElement>) => {
        e.preventDefault();
        setError('');

        if (loginForm.email.length === 0) {
            setError('Please fill out this field');
            return;
        }

         if (loginForm.password.length === 0) {
            setError('Please fill out this field');
            return;
        }

        setLoading(true);
        try {
            const result = await loginUser({ email: loginForm.email, password: loginForm.password });
            localStorage.setItem('token', result.token);
            localStorage.setItem('email', result.email);
            localStorage.setItem('userName', result.userName);
            navigate('/UserDashboard');
        } catch (err) {
            setError(err instanceof Error ? err.message : 'Login failed.');
        } finally {
            setLoading(false);
        }
    };

The handleSubmit function is responsible for five things:

Resetting the error state to an empty string and checking that both form fields have values — if not, it sets the error state.
Setting the loading state to true before sending the POST API call.
Triggering the API call and storing the result in the result variable.
Saving the returned data (token, email, and username) to local storage.
Navigating the user to the dashboard.

What's Next

In my next post, I'll cover how I built the API call for login and added Zod validation for runtime checks.

If this helped you, consider dropping a like or comment — feedback is always welcome!

How to Build a Reusable TextInput Component in React with TypeScript

Sandhya-Allgandhuala — Sat, 04 Jul 2026 10:20:04 +0000

Introduction

I was copy-pasting the same markup everywhere, tweaking a class name here, adding an error message there. In my Smart Budget Tracker app, I decided to create a reusable TextInput component that can handle different labels, error states, icons, and for the password field a show/hide toggle. now, TextInput component will rule them all at one place. This post walks through how it's structured.

Why Build a Custom TextInput?

Native elements are flexible, fine for one form, but it falls apart once more than one developer is building forms. Left unchecked, every dev styles errors differently, rebuilds the password toggle their own way. None of it is "wrong," it's just inconsistent — there's no single agreed-upon definition of how an input should behave.

Common symptoms:

Inconsistent error UI — some inputs show a red border, others just red text, others both.
Repeated password-toggle logic — rebuilt slightly differently in every form.
Accessibility gaps — aria-invalid / aria-describedby added on some forms, forgotten on others.

A shared TextInput component fixes this by becoming the one place everyone goes through — styling, error handling and accessibility are decided once and reused everywhere. Design changes become a one-line fix instead of a hunt across the codebase, and reviewers no longer need to check whether each dev remembered the details — the component already guarantees it.

Define the Props with TypeScript

I start by defining what the TextInput component accepts as props. For example, name, value, and onChange are required props that the caller must pass. The component also accepts icons, typed as React.ReactNode, meaning we can pass anything that can render

interface Props {
  name: string;
  value: string;
  onChange: (e: React.ChangeEvent<HTMLInputElement>) => void;
  label?: string;
  placeholder?: string;
  required?: boolean;
  type?: string;
  disabled?: boolean;
  maxLength?: number;
  error?: string;
  success?: boolean;
  leftIcon?: React.ReactNode;
  rightIcon?: React.ReactNode;
  rightAction?: React.ReactNode;
  size?: 'sm' | 'md' | 'lg';
  className?: string;
  hint?: string;
}

useState Hook and show /hide password

This is the first hook used in the Smart Budget Tracker app, declared at the top level inside the functional component — we never call a hook conditionally. We pass false as the initial value to the showPassword state variable. isPassword is set to true when the type prop is 'password', and the following inputType determines whether the password should be shown or hidden

  const [showPassword, setShowPassword] = useState(false); 
  const isPassword = (type === 'password');
  const inputType = isPassword
    ? showPassword ? 'text' : 'password'
    : type;

Rendering Label and action icons

We can pass JavaScript between {}, and it gets evaluated left to right. In our TextInput component, when label is passed as a prop, it checks for required and rightAction. If we pass "" or undefined, the right side of the expression won't be evaluated and nothing renders.

htmlFor links the label to the input via the id. When a user clicks the label text, the browser focuses the input.
rightAction is mainly used in places like "Forgot password?" links — it's displayed on the right side, at the same level as the label, since we're passing the class name flex justify-between items-center to position them on opposite ends of the row.

{label && (
        <div className="flex justify-between items-center">
          <label htmlFor={name} className="input-label">
            {label}
            {required && <span className="input-required">*</span>}
          </label>
          {rightAction && (
            <span className="text-xs text-black cursor-pointer hover:text-green-700">{rightAction}</span>
          )}
        </div>
      )}

Left Icons and Rendering the Text Input

Left icons — like the email and lock icons shown in the image — are rendered only when passed in as a prop. The actual element is then rendered with all the props received from the caller component.

  {leftIcon && ( 
          <span className="pl-3 text-slate-400 shrink-0 text-base">{leftIcon}</span>
        )}

        <input
          id={name}
          name={name}
          type={inputType}
          value={value}
          onChange={onChange}
          placeholder={placeholder}
          required={required}
          disabled={disabled}
          maxLength={maxLength}
          className={fieldCSSWrapperClass}
        />

id={name} reuses the name prop as the input's id — this is what lets htmlFor={name}on the label (from the previous section) correctly link to this exact input.
shrink-0 on the icon's span prevents the icon from getting squeezed or shrunk when the input's content is long or the container is narrow — it keeps the icon at a fixed size.

Show/Hide Password Handling

This is the part where we handle whether the password should be shown or hidden. The setter function is used to update the showPassword state variable. This block only renders when type is 'password'. When the button is clicked, it toggles between text and password — if the current type is text, the password is visible; otherwise, it's hidden.

   {isPassword && ( 
          <button
            type="button"
            className="input-toggle-btn"
            onClick={() => setShowPassword(!showPassword)} 
          >
            <img src={showPassword ? eyeClosed : eyeOpen} alt={showPassword ? 'hide password' : 'show password'} width={18} height={18} />
          </button>
        )}

Error Handling and Hints

  {error && <span className='input-error-msg'>{error}</span>}

      {hint && maxLength !== undefined && value.length >= maxLength && (
        <p className="input-hint-msg">{hint}</p>
      )}

As shown in the image, we can pass a validation error message to the error prop. It's rendered only when this prop is passed; otherwise, it's skipped.

We can also pass a hint — but note this one only renders when three conditions are all true: hint is passed, maxLength is defined, and the current value. Length has reached or exceeded maxLength. So the hint acts as a character-limit warning rather than a general-purpose helper text, shown only once the user hits the limit

How to use it

  <TextInput
                            label="Email Address"
                            name="email"
                            type="email"
                            placeholder="Sample@SmartBudget.com"
                            value={loginForm.email}
                            onChange={handleChange}
                            error={error}
                            disabled={loading}
                            leftIcon={<img src={emailIcon} alt="email" width={18} height={18} />}
                        />
                        <TextInput
                            label="Password"
                            name="password"
                            type="password"
                            placeholder="********"
                            value={loginForm.password}
                            onChange={handleChange}
                            leftIcon={<img src={lockIcon} alt="lock" width={18} height={18} />}
                            rightAction="Forgot password?"
                            disabled={loading}
                            maxLength={12}
                            hint="Only 12 characters are allowed"
                        />

What I Learned

Reusability isn't just about saving code — it's about consistency.
About React.ReactNode.
The Rules of Hooks matter in practice, not just in theory.
Short-circuit evaluation (&&) is doing a lot of quiet work.

What's Next

In my next post l'll cover how I built a login page using this reusable components

If this helped you, drop a like or comment any feedback is welcome!

How to Build a Reusable Button Component in React with TypeScript

Sandhya-Allgandhuala — Mon, 22 Jun 2026 17:13:28 +0000

Introduction

When I started building my Smart Budget Tracker app, I noticed I was copy-pasting button code everywhere - submit buttons, link buttons, loading buttons. Each one looked slightly different. That's when I decided to build one reusable button component to rule them all.

In this post I'll walk you through how I built it using React and TypeScript.

What We are Building

A single component that handles:

Regular click buttons
From submit buttons
Navigation link buttons
Loading state with a spinner
Disabled state
Multiple sizes and variants

Step 1 - Defines the Props Interface

The first thing I do in Typescript is define exactly what the component accepts. This gives you autocomplete and catches mistakes at compile time.

interface Props {
  label: string;
  onClick?: () => void;
  disabled?: boolean;
  loading?: boolean;
  href?: string;
  variant?: 'default' | 'primary';
  size?: 'sm' | 'md' | 'lg';
  fullWidth?: boolean;
  type?: 'submit' | 'button';
  className?: string;
}

The ? means the prop is optional, only label is required everything else has a default.

Step 2 - Set Default Values

function Button({
  label,
  onClick,
  disabled = false,
  loading = false,
  href,
  variant = 'default',
  size = 'md',
  fullWidth = false,
  type = 'button',
  className = '',
}: Props) {

Default values mean callers don't need to pass every prop, <Button label = "Save"/> just works.

Step 3 - Build the CSS class dynamically

Instead of writing if/else for every style combination, I build the class string from an array

const isDisabled = disabled || loading;

const wrapperCSSClass = [
  'btn-base',
  `btn-${variant}`,
  `btn-${size}`,
  fullWidth ? 'btn-full': '',
  isDisabled ? 'btn-disabled': '',
  className,
].filter(Boolean).join(' ');

filter(Boolean) removes any empty string so you don't get extra spaces in the class name. Adding a new variant is just one line.

Step 4 - Handle the Loading Spinner

When Loading is true, I show a spinner SVG icon and change the label text

const labelContent = (
  <>
    {loading && (
      <svg className="animate-spin h-4 w-4" ...>
        ...
      </svg>
    )}
    <span>{loading ? 'Loading...': label}</span>
  </>
);

I also added aria- busy = {loading} on the button element. This tells screen readers that the button is busy - a small but important accessibility detail.

Step 5 - Handle Link Vs Button

This was the interesting part, sometimes a button navigates to another pages like a "Registration" link that looks like a button. I handle both cases:

if (href) {
  return isDisabled
    ? <span className={wrapperCSSClass}>{labelContent}</span>
    : <Link to={href} className={wrapperCSSClass}>{labelContent}</Link>;
}

return (
  <button
    type={type}
    onClick={onClick}
    disabled={isDisabled}
    className={wrapperCSSClass}
    aria-busy={loading}
  >
    {labelContent}
  </button>
);

When href is passed, it renders a React Router <Link>. When disabled, it renders a <span> because a disabled link is semantically incorrect in HTML.

How to Use it

// Primary submit button
<Button label="Log in" type="submit" variant="primary" fullWidth loading={loading} />

// Navigation link styled as button
<Button label="Register Free" href="/Register" />

// Disabled button
<Button label="Save" disabled />

What I Learned

TypeScript interfaces makes component self-documenting - you always know what props are available
filter(Boolean) is a clean trick for building dynamic class strings
One component can handle both <button> and <Link>with a simple conditional render
Accessibility (aria-busy) is easy to add and makes a real difference

What's Next

In my next post l'll cover how I built a reusable TextInput component with error state, icons, and password toggle - also from my Smart Budget Tracker project.

If this helped you, drop a like or comment. I'm just getting started with blogging and any feedback is welcome!