Call a React Component with TypeScript and Zod: A Step-by-Step, Production-Ready Pattern

The fastest way to call a component in React is to render it via JSX and pass strictly typed props. This article shows how to call a component in React with TypeScript and Zod so you get compile-time and runtime safety, clear state management, and production-ready patterns.

The Problem

Developers often "call" (render) a component without strict typing or validation, leading to runtime bugs, unclear state, and hard-to-test UI.

Prerequisites

Node.js 20+, pnpm or npm, React 19, TypeScript 5+, Zod 3+, a modern browser. Ensure tsconfig has strict: true.

The Solution (Step-by-Step)

Step 1: Bootstrap a minimal TypeScript + React app

// package.json (excerpt) - ensures React 19 and strict TS
{
  "name": "react-call-component-ts",
  "private": true,
  "type": "module",
  "scripts": {
    "dev": "vite",
    "build": "tsc -b && vite build",
    "preview": "vite preview"
  },
  "dependencies": {
    "react": "^19.0.0",
    "react-dom": "^19.0.0",
    "zod": "^3.22.0"
  },
  "devDependencies": {
    "typescript": "^5.6.0",
    "vite": "^5.0.0",
    "@types/react": "^18.3.0",
    "@types/react-dom": "^18.3.0"
  }
}

// tsconfig.json - strict mode enabled for maximum safety
{
  "compilerOptions": {
    "target": "ES2022",
    "lib": ["ES2022", "DOM"],
    "jsx": "react-jsx",
    "module": "ESNext",
    "moduleResolution": "Bundler",
    "strict": true,
    "noFallthroughCasesInSwitch": true,
    "noUncheckedIndexedAccess": true,
    "skipLibCheck": true
  },
  "include": ["src"]
}

Step 2: Create a strictly typed child component with runtime validation

// src/components/Greeting.tsx
import React, { memo } from "react";
import { z } from "zod";

// 1) Define compile-time props shape via TypeScript
export type GreetingProps = {
  name: string;                 // Required user name
  mode: "friendly" | "formal";  // Discriminated literal union for behavior
};

// 2) Define runtime schema using Zod for additional safety in production
const greetingPropsSchema = z.object({
  name: z.string().min(1, "name is required"),
  mode: z.union([z.literal("friendly"), z.literal("formal")])
});

// 3) React.memo to avoid unnecessary re-renders when props are stable
export const Greeting = memo(function Greeting(props: GreetingProps) {
  // Validate props at runtime to fail fast in dev and log issues in prod
  const result = greetingPropsSchema.safeParse(props);
  if (!result.success) {
    // Render a small fallback and log schema errors for debugging
    console.error("Greeting props invalid:", result.error.format());
    return Invalid greeting config;
  }

  // Safe, parsed props
  const { name, mode } = result.data;

  // Render based on discriminated union value
  if (mode === "friendly") {
    return 
Hi, {name}! Welcome back.
;
  }
  return 
Hello, {name}. It is good to see you.
;
});

Explanation: We "call" a component in React by placing it in JSX like <Greeting name="Sam" mode="friendly" />. The TypeScript type enforces correct usage at compile time; Zod enforces it at runtime.

Step 3: Manage parent state with discriminated unions and render the child

// src/App.tsx
import React, { useEffect, useState } from "react";
import { Greeting } from "./components/Greeting";

// Discriminated union for page state: guarantees exhaustive checks
type PageState =
  | { kind: "loading" }
  | { kind: "ready"; userName: string }
  | { kind: "error"; message: string };

export function App() {
  const [state, setState] = useState({ kind: "loading" });

  // Simulate fetching the current user, then set ready state
  useEffect(() => {
    const timer = setTimeout(() => {
      // In a real app, replace with a fetch call and proper error handling
      setState({ kind: "ready", userName: "Sam" });
    }, 300);
    return () => clearTimeout(timer);
  }, []);

  // Render different UI based on discriminated union state
  if (state.kind === "loading") {
    return 
Loading…
;
  }
  if (state.kind === "error") {
    return 
Error: {state.message}
;
  }

  // Key line: this is how you "call" (render) the component with props
  return (
    

      
Dashboard
      

      {/* Rendering a list of components safely */}
      {(["Ada", "Linus", "Grace"] as const).map((n) => (
        
      ))}
    
  );
}

Step 4: Mount the app

// src/main.tsx
import React from "react";
import { createRoot } from "react-dom/client";
import { App } from "./App";

const container = document.getElementById("root");
if (!container) throw new Error("Root container missing");

createRoot(container).render(
  // StrictMode helps surface potential issues
  
    
  
);

Best Practices & Security

Pro-Tip: Use React.memo for presentational components to avoid unnecessary re-renders.

Pro-Tip: Use discriminated unions for UI state to guarantee exhaustive handling and safer refactors.

Pro-Tip: Validate at runtime with Zod for boundary inputs (API responses, query params, environment-driven config).

Pro-Tip: Prefer useCallback and stable prop shapes when passing callbacks to memoized children.

Pro-Tip: Keep components pure; avoid hidden side effects inside render logic.

Security note (front-end): Do not embed secrets in the client. If you integrate with Azure or any backend, call a secured API instead of accessing resources directly from the browser.

Security note (Azure backend integration): Use Managed Identity and DefaultAzureCredential in the server/API, not the frontend. Grant the server's managed identity least-privilege RBAC roles only. Example: for Azure Storage reads, assign Storage Blob Data Reader to the API identity at the specific container scope.

Security note (data flow): Validate user input and API responses at the edge (API) with Zod or similar, then keep the front-end strictly typed.

Summary

• You call a component in React by rendering it in JSX with strictly typed, validated props.

• Discriminated unions make UI state predictable, and React.memo boosts performance.

• For real backends, keep secrets server-side, use Managed Identity with least-privilege RBAC, and validate at the edge.

Testing Quickstart

Test a component render with React Testing Library

// src/components/Greeting.test.tsx
import React from "react";
import { render, screen } from "@testing-library/react";
import "@testing-library/jest-dom";
import { Greeting } from "./Greeting";

test("renders friendly greeting", () => {
  render(<Greeting name="Sam" mode="friendly" />);
  expect(screen.getByText(/Hi, Sam!/)).toBeInTheDocument();
});

test("renders formal greeting", () => {
  render(<Greeting name="Ada" mode="formal" />);
  expect(screen.getByText(/Hello, Ada\./)).toBeInTheDocument();
});

This test verifies the component is "called" with valid props and renders deterministic output. For invalid props, assert that the fallback appears and console error is triggered.

Const vs readonly in C#: Practical Rules, .NET 8 Examples, and When to Use Each

Const vs readonly in C#: use const for compile-time literals that never change and readonly for runtime-initialized values that should not change after construction. This article shows clear rules, .NET 8 examples with Dependency Injection, and production considerations so you pick the right tool every time.

The Problem

Mixing const and readonly without intent leads to brittle releases, hidden performance costs, and binary-compatibility breaks. You need a simple, reliable decision framework and copy-paste-ready code that works in modern .NET 8 Minimal APIs with DI.

Prerequisites

• .NET 8 SDK: Needed to compile and run the Minimal API and C# 12 features.
• An editor (Visual Studio Code or Visual Studio 2022+): For building and debugging the examples.
• Azure CLI (optional): If you apply the security section with Managed Identity and RBAC for external configuration.

The Solution (Step-by-Step)

1) What const means

• const is a compile-time constant. The value is inlined at call sites during compilation.
• Only allowed for types with compile-time constants (primitive numeric types, char, bool, string, and enum).
• Changing a public const value in a library can break consumers until they recompile, because callers hold the old inlined value.

// File: AppConstants.cs
namespace MyApp;

// Static class is acceptable here because it only holds constants and does not manage state or dependencies.
public static class AppConstants
{
    // Compile-time literals. Safe to inline and extremely fast to read.
    public const string AppName = "OrdersService";    // Inlined at compile-time
    public const int DefaultPageSize = 50;             // Only use if truly invariant
}

2) What readonly means

• readonly fields are assigned exactly once at runtime: either at the declaration or in a constructor.
• Use readonly when the value is not known at compile-time (e.g., injected through DI, environment-based, or computed) but must not change after creation.
• static readonly is runtime-initialized once per type and is not inlined by callers, preserving binary compatibility across versions.

// File: Slug.cs
namespace MyApp;

// Simple immutable value object using readonly field.
public sealed class Slug
{
    public readonly string Value; // Assigned once; immutable thereafter.

    public Slug(string value)
    {
        // Validate then assign. Once assigned, cannot change.
        Value = string.IsNullOrWhiteSpace(value)
            ? throw new ArgumentException("Slug cannot be empty")
            : value.Trim().ToLowerInvariant();
    }
}

3) Prefer static readonly for non-literal shared values

• Use static readonly for objects like Regex, TimeSpan, Uri, or configuration-derived values that are constant for the process lifetime.

// File: Parsing.cs
using System.Text.RegularExpressions;

namespace MyApp;

public static class Parsing
{
    // Compiled Regex cached for reuse. Not a compile-time literal, so static readonly, not const.
    public static readonly Regex SlugPattern = new(
        pattern: "^[a-z0-9-]+$",
        options: RegexOptions.Compiled | RegexOptions.CultureInvariant
    );
}

4) Minimal API (.NET 8) with DI using readonly

// File: Program.cs
using Microsoft.AspNetCore.Builder;
using Microsoft.AspNetCore.Http;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;
using Microsoft.Extensions.Options;

namespace MyApp;

// Options record for settings that may vary by environment.
public sealed record PaginationOptions(int DefaultPageSize, int MaxPageSize);

// Service depending on options. Primary constructor for clarity.
public sealed class ProductService(IOptions<PaginationOptions> options)
{
    private readonly int _defaultPageSize = options.Value.DefaultPageSize; // readonly: set once from DI

    public IResult List(int? pageSize)
    {
        // Enforce immutable default from DI; callers can't mutate _defaultPageSize
        var size = pageSize is > 0 ? pageSize.Value : _defaultPageSize;
        return Results.Ok(new { PageSize = size, Source = "DI/readonly" });
    }
}

var builder = WebApplication.CreateBuilder(args);

// Bind options from configuration once. Keep them immutable after construction.
builder.Services.Configure<PaginationOptions>(builder.Configuration.GetSection("Pagination"));

// Register ProductService for DI.
builder.Services.AddSingleton<ProductService>();

var app = builder.Build();

// Use const for literal routes and tags: truly invariant strings.
app.MapGet("/products", (ProductService svc, int? pageSize) => svc.List(pageSize))
   .WithTags(AppConstants.AppName);

app.Run();

5) When to use which (decision rules)

• Use const when: the value is a true literal that will never change across versions, and you accept inlining (e.g., mathematical constants, semantic tags, fixed route segments).
• Use readonly when: the value is computed, injected, environment-specific, or may change across versions without forcing consumer recompilation.
• Use static readonly for: reference types (Regex, TimeSpan, Uri) or structs not representable as compile-time constants, shared across the app.
• Avoid public const in libraries for values that might change; prefer public static readonly to avoid binary-compat issues.

6) Performance and threading

• const reads are effectively free due to inlining.
• static readonly reads are a single memory read; their initialization is thread-safe under the CLR type initializer semantics.
• RegexOptions.Compiled with static readonly avoids repeated parsing and allocation under load.

7) Advanced: readonly struct for immutable value types

• Use readonly struct to guarantee all instance members do not mutate state and to enable defensive copies avoidance by the compiler.
• Prefer struct only for small, immutable value types to avoid copying overhead.

// File: Money.cs
namespace MyApp;

public readonly struct Money
{
    public decimal Amount { get; }
    public string Currency { get; }

    public Money(decimal amount, string currency)
    {
        Amount = amount;
        Currency = currency;
    }

    // Methods cannot mutate fields because the struct is readonly.
    public Money Convert(decimal rate) => new(Amount * rate, Currency);
}

8) Binary compatibility and versioning

• Public const values are inlined into consuming assemblies. If you change the const and do not recompile consumers, they keep the old value. This is a breaking behavior.
• Public static readonly values are not inlined. Changing them in your library updates behavior without requiring consumer recompilation.
• Guideline: For public libraries, avoid public const except for values guaranteed to never change (e.g., mathematical constants or protocol IDs defined as forever-stable).

9) Testing and static analysis

• Roslyn analyzers: Enable CA1802 (use const) to suggest const when fields can be made const; enable IDE0044 to suggest readonly for fields assigned only in constructor.
• CI/CD: Treat analyzer warnings as errors for categories Design, Performance, and Style to enforce immutability usage consistently.
• Unit tests: Assert immutability by verifying no public setters exist and by attempting to mutate through reflection only in dedicated tests if necessary.

10) Cross-language note: TypeScript immutability parallel

If your stack includes TypeScript, mirror the C# intent with readonly and schema validation.

// File: settings.ts
// Strict typing; no 'any'. Enforce immutability on config and validate with Zod.
import { z } from "zod";

// Zod schema for runtime validation
export const ConfigSchema = z.object({
  apiBaseUrl: z.string().url(),
  defaultPageSize: z.number().int().positive(),
}).strict();

export type Config = Readonly<{
  apiBaseUrl: string;           // readonly by type
  defaultPageSize: number;      // readonly by type
}>;

export function loadConfig(env: NodeJS.ProcessEnv): Config {
  // Validate at runtime, then freeze object to mimic readonly semantics
  const parsed = ConfigSchema.parse({
    apiBaseUrl: env.API_BASE_URL,
    defaultPageSize: Number(env.DEFAULT_PAGE_SIZE ?? 50),
  });
  return Object.freeze(parsed) as Config;
}

Best Practices & Security

• Best Practice: Use const only for literals that are guaranteed stable across versions. For anything configuration-related, prefer readonly or static readonly loaded via DI.
• Best Practice: Static classes holding only const or static readonly are acceptable because they do not manage state or dependencies.
• Security: If loading values from Azure services (e.g., Azure App Configuration or Key Vault), use Managed Identity instead of connection strings. Grant the minimal RBAC roles required: for Azure App Configuration, assign App Configuration Data Reader to the managed identity; for Key Vault, assign Key Vault Secrets User; for reading resource metadata, the Reader role is sufficient. Do not embed secrets in const or readonly fields.
• Operational Safety: Avoid public const for values that may change; use public static readonly to prevent consumer inlining issues and to reduce breaking changes.
• Observability: Expose configuration values carefully in logs; never log secrets. If you must log, redact or hash values and keep them in readonly fields populated via DI.

Summary

• Use const for true compile-time literals that never change; prefer static readonly for public values to avoid consumer recompilation.
• Use readonly (and static readonly) for runtime-initialized, immutable values, especially when sourced via DI or environment configuration.
• Harden production: enforce analyzers in CI, adopt Managed Identity with least-privilege RBAC, and avoid embedding secrets or changeable values in const.