uibeats.com Paid content

TypeScript is a typed superset of JavaScript: every valid JavaScript program is also valid TypeScript, but TypeScript adds optional static types that a compiler checks before your code ever runs. You use it by installing the typescript package, writing .ts files, and compiling them to plain .js with the tsc command. It fits best when a codebase grows past a few files or several people, where catching type errors at build time is cheaper than debugging them at runtime. For a throwaway script, plain JavaScript is usually faster to write.

What TypeScript actually adds

TypeScript does not change how JavaScript runs. Browsers and Node.js still execute JavaScript, so the types are erased during compilation. What you gain is a checking pass:

• Static type checking — the compiler reads your annotations and flags mismatches before execution.
• Earlier error detection — mistakes like calling a method that does not exist surface in your editor or in tsc, not in production.
• Better tooling — editors use the type information for autocomplete, inline documentation, and safe rename/refactor operations.
• Self-documenting interfaces — function signatures and object shapes describe intent without extra comments.

The trade-off is a build step and some annotation overhead. Types are optional, so you can adopt them gradually.

The basic workflow

1. Install the compiler

npm install --save-dev typescript

This adds tsc to your project. You can also install it globally, but a local dev dependency keeps the version consistent across machines and CI.

2. Write a .ts file

function greet(name: string): string {
  return `Hello, ${name}`;
}

console.log(greet("Ada"));

The : string annotations tell the compiler what name and the return value must be. If you call greet(42), tsc reports an error instead of letting it fail silently at runtime.

3. Compile

npx tsc greet.ts

Expected result: a greet.js file next to the source, containing the same logic with the type annotations removed. That .js file is what Node.js or the browser runs.

4. Add a config file

For anything beyond one file, create a tsconfig.json so you do not repeat flags:

{
  "compilerOptions": {
    "target": "ES2020",
    "module": "ESNext",
    "strict": true,
    "outDir": "dist"
  },
  "include": ["src"]
}

Then just run npx tsc. strict: true turns on the stricter checks, including strictNullChecks, which is where most real-world type safety comes from. Turning it on later in a large project is painful, so enable it early.

Key features with examples

Type annotations

let count: number = 0;
let names: string[] = ["Ada", "Grace"];

Annotations can be omitted when TypeScript can infer the type, which it does for most assignments.

Interfaces

interface User {
  id: number;
  email: string;
  nickname?: string; // optional
}

function sendWelcome(user: User) {
  console.log(`Welcome, ${user.nickname ?? user.email}`);
}

An interface describes the shape an object must have. Passing an object missing id or email is a compile error.

Generics

function first<T>(items: T[]): T | undefined {
  return items[0];
}

const n = first([1, 2, 3]);      // n: number | undefined
const s = first(["a", "b"]);     // s: string | undefined

Generics let one function work across types while keeping the relationship between input and output. T is a placeholder filled in at the call site.

Using TypeScript in an existing JavaScript project

You do not have to convert everything at once:

1. Add typescript and a tsconfig.json with "allowJs": true so .js files are included.
2. Rename files to .ts one at a time, starting with the most central modules.
3. Add types to function boundaries first — parameters and return values — and let inference handle the internals.
4. Turn on strict once the obvious errors are cleared.

Most build tools and bundlers accept TypeScript through a loader or plugin, so you rarely need to run tsc by hand in a modern setup. In monorepos, tools like Lerna manage multiple JavaScript/TypeScript packages from one repository, and each package can carry its own tsconfig.json while sharing a base config. That is a common reason teams introduce TypeScript: a shared type contract between packages catches breaking changes at build time rather than at integration.

Common sticking points

• any everywhere — annotating everything as any disables the checks you installed TypeScript for. Prefer unknown and narrow it.
• Ignoring strictNullChecks — most runtime crashes come from null/undefined, which this flag catches.
• Types at runtime — TypeScript types do not exist after compilation, so you still need runtime validation for data from APIs, files, or user input.
• Build configuration drift — mismatched target/module settings between tsconfig.json and your bundler cause confusing errors; keep them aligned.

If your goal is safer JavaScript in a growing codebase, start with a tsconfig.json, enable strict, and convert files incrementally. If you are writing a small script that will not be maintained, plain JavaScript remains the simpler choice.

A React component is a reusable piece of UI defined as a JavaScript function (or, historically, a class) that returns markup. You build an interface by composing many small components, passing data in through props and tracking change with state. If you're starting a project or adding to one, you'll usually write your own components for app-specific logic and pull in prebuilt ones from a library or registry for common UI like buttons, heroes, and cards. The sections below cover how components work, when to use which style, and how to add one and confirm it renders.

The core idea: a function that returns UI

A component takes an input object called props and returns what should appear on screen. State is data a component owns and can change over time; when it changes, React re-renders that component.

function Greeting({ name }) {
  return <h1>Hello, {name}</h1>;
}

// Used like an HTML tag:
<Greeting name="Ada" />

Two rules matter in practice:

• Props flow down, events flow up. A parent passes data to a child via props; the child signals change by calling a function the parent handed it.
• Components must be pure with respect to their inputs. Given the same props and state, they should render the same output. Side effects (fetching, subscriptions) belong in hooks like useEffect.

Function components vs. class components

Modern React uses function components with hooks. Class components still appear in older codebases and some libraries, so you should recognize them even if you don't write them.

If you're starting fresh, use function components. Reach for a class only when maintaining existing code or integrating a library that requires it.

Composition: build big UI from small pieces

The main way you scale a React app is by splitting UI into small components and combining them. Three patterns cover most cases:

• Passing children lets a wrapper render whatever you nest inside it:

  function Card({ children }) {
    return <div className="card">{children}</div>;
  }
  <Card><Greeting name="Ada" /></Card>
  

• Lifting state up means moving shared state to the closest common parent so two siblings can stay in sync, rather than duplicating it in each.
• Keeping components focused — one component, one job — makes them easier to reuse and test.

Where prebuilt components come from

You rarely build everything yourself. Two distribution models dominate:

• Package libraries ship compiled code you import from node_modules. You get updates by bumping a version, but you don't own or edit the source.
• Registries and copy-in source give you the actual component file, which lands in your repo and becomes yours to edit. This is the model behind shadcn/ui conventions, where components are React + Tailwind source rather than an opaque dependency.

21st is a registry in the second category. Its library lists 12,000+ crafted React components, templates, and shadcn themes, organized into categories such as 2,000+ marketing blocks (animated heroes, shaders, backgrounds, footers) and 2,100+ UI components (buttons, AI chats, cards and grids, navigation, sign-ins). Components are attributed to named authors, and the site states they ship as prompts you can copy into your tooling — its examples show the same prompt producing a diff in Codex, a file in Claude Code, and a live preview in Lovable. The site also reports 25,431 installs in a week for one component and a builder count of 3,819,076, which gives a rough sense of activity rather than a quality guarantee.

Because these components are source you place in your project, the trade-off is the reverse of a package library: you can edit anything, but you also own maintenance and updates.

Adding a component to your project and verifying it

The exact command depends on the registry, but the shape of the task is consistent. Using a copy-in component as the example:

1. Confirm prerequisites. You need a React project with Tailwind and the cn utility (a class-merging helper) available, since registry components typically import from @/lib/utils.
2. Get the source. Either run the registry's install command or paste the component's prompt into your AI tool so it writes the file into your components directory. Expect a new file such as components/ui/shimmer-button.tsx.
3. Import and render it. Add the import to a page and place the component in the tree.
4. Verify. Run your dev server and check that the component appears and responds to interaction. If the registry ships a preview, compare against it.

A minimal check after install:

import { ShimmerButton } from "@/components/ui/shimmer-button";

export default function Page() {
  return <ShimmerButton>Get started →</ShimmerButton>;
}

If it renders and the hover/interaction behavior matches the preview, the install succeeded.

Troubleshooting common problems

• Missing imports or unresolved @/ paths. The @ alias must be configured in your bundler or tsconfig. If the component imports @/lib/utils and that file doesn't exist, create it or fix the alias.
• Prop type errors. If the component expects a required prop and you omit it, you'll get a warning or a crash. Check the component's signature and pass what it declares.
• Styling looks wrong. Registry components assume Tailwind is set up and that your theme tokens (colors, radii) exist. Missing Tailwind config or theme variables produce unstyled output rather than an error.
• Excessive re-renders. A component re-rendering on every keystroke or parent update usually means state lives too high or a new object/function is created each render. Move state closer to where it's used, or memoize with useMemo/useCallback when profiling shows it matters.
• "Hooks can only be called inside a component." You called a hook at the top level of a module or inside a condition. Hooks must run unconditionally at the top of a component or custom hook.

Choosing between writing and installing

Write your own component when the logic is specific to your app, when you need tight control over behavior, or when a library's abstraction would fight your design. Install from a registry when the UI is generic (buttons, heroes, cards), when you want to read and edit the source, and when you're comfortable owning updates. Use a package library instead when you'd rather receive fixes automatically and don't need to modify internals. The right choice depends on how much control versus maintenance you want — not on which option is universally better.