Forem: Dong Atienza

We Almost Shipped a Security Hole. Here's How React Context and .NET 10 Razor Pages Saved Us

Dong Atienza — Thu, 16 Apr 2026 03:42:45 +0000

Part 3 of the React for C#/.NET Developers series. Part 1 covered fundamentals. Part 2 covered useEffect. This one covers something nobody warns you about until it's almost too late.

I was running a React training for a group of senior .NET developers on a .NET 10 project last month.

Smart developers. Years of experience. They'd sailed through JSX, components, useState, and useEffect without much trouble.

Then someone asked a question that stopped the entire class cold.

"Sir — if React runs in the browser, doesn't that mean our data processing happens on the client side? Isn't that a security risk?"

Silence.

Then everyone slowly turned to look at me. Because they all realized at the same moment that yes — that's exactly what was happening. And we were days away from ending the training.

That question led to one of the most frustrating — and ultimately most valuable — implementation challenges I've seen in a training class. And it completely changed how I teach React security to C# developers.

Here's the full story, and the solution we built.

The problem nobody mentions in React tutorials

Most React tutorials show you this flow:

// The tutorial approach
useEffect(() => {
    fetch('/api/transactions')           // calls your API
        .then(r => r.json())             // gets data
        .then(data => setTransactions(data)); // stores in state
}, []);

Clean. Simple. Works perfectly. Ship it.

But here's what that actually means from a security perspective:

What you think happens	What actually happens
Data is processed securely	Data is fetched and processed in the browser
Server controls data access	JavaScript in the browser controls data access
Business logic is protected	Anyone can inspect network requests and responses
Sensitive calculations are safe	All calculations happen client-side — visible to anyone

Coming from C#/.NET where your controllers, services, and business logic live safely on the server — this is a genuinely uncomfortable realization.

And for our .NET 10 project which dealt with financial transaction data, it wasn't just uncomfortable. It was unacceptable.

First — let's cover Context properly

Before I get to the security solution, I need to cover React Context — because it's central to how we solved the problem.

The prop drilling problem

Imagine you have a JWT token after login. You need it in your NavBar, your TransactionList, your AccountDetails, and your Dashboard components. Without Context you'd pass it like this:

// Without Context — prop drilling nightmare
<App token={token}>
    <Dashboard token={token}>
        <TransactionList token={token}>
            <TransactionRow token={token} />
        </TransactionList>
    </Dashboard>
</App>

// Every component needs token even if it doesn't use it
// Just passing it down to the next level — messy

Sound familiar? In C# terms this is like passing a dependency through every constructor in your call chain instead of using DI.

Context fixes this exactly the way DI fixes it in C# — register once, inject anywhere.

Context is React's dependency injection

C# Dependency Injection	React Context
`services.AddScoped<IAuthService>()`	`createContext(null)`
`services.AddScoped<AuthService>()`	`AuthProvider` component
`constructor(IAuthService auth)`	`useContext(AuthContext)`
`Program.cs` registration	`<AuthProvider>` wrapping App

// 1. Create the context
import { createContext, useContext, useState } from 'react';

const AuthContext = createContext(null);

// 2. Create the provider — like your DI registration
export function AuthProvider({ children }) {
    const [token, setToken] = useState(
        localStorage.getItem('jwt_token')
    );

    const login = (newToken) => {
        localStorage.setItem('jwt_token', newToken);
        setToken(newToken);
    };

    const logout = () => {
        localStorage.removeItem('jwt_token');
        setToken(null);
    };

    return (
        <AuthContext.Provider value={{ token, login, logout }}>
            {children}
        </AuthContext.Provider>
    );
}

// 3. Custom hook — like a typed service interface
export function useAuth() {
    return useContext(AuthContext);
}

// 4. Wrap your app once — like Program.cs
// main.jsx
root.render(
    <AuthProvider>
        <App />
    </AuthProvider>
);

// 5. Consume anywhere — no prop drilling
function NavBar() {
    const { token, logout } = useAuth();
    return (
        <nav>
            <span>{token ? 'Logged in' : 'Guest'}</span>
            <button onClick={logout}>Sign Out</button>
        </nav>
    );
}

💡 Key insight: Context is React's dependency injection. The AuthProvider is your service registration. useAuth() is your constructor injection. Once you see it that way, it stops being confusing.

Back to the security problem — and how we actually solved it

The standard approach — React fetching data directly from an API — means sensitive data processing happens in the browser. For a banking dashboard dealing with transaction data, that wasn't acceptable.

My student's question led us to a hybrid architecture that took us a frustrating day and a half to implement — but when it finally worked, the relief in the room was palpable.

The solution: Razor Pages handles all sensitive data processing server-side. React Islands consume that pre-processed data through HTML data attributes. No fetch() needed. No client-side data processing.

The architecture we built

Layer	Technology	Responsibility
Authentication	ASP.NET Core `[Authorize]`	JWT validation — server side
Data processing	Razor Pages `PageModel`	Query DB, shape data, serialize
Data delivery	HTML `data-*` attributes	Pre-processed JSON in the page
UI rendering	React Islands	Read data attributes, render UI
No client API calls	None needed	Data already in the page

The Razor Pages side — DashboardModel.cs

The [Authorize] attribute handles authentication before the page even loads — no JWT token validation happening in JavaScript:

using Microsoft.AspNetCore.Authorization;
using Microsoft.AspNetCore.Mvc.RazorPages;
using DashboardProject.Data;
using System.Text.Json;

namespace DashboardProject.Pages;

[Authorize]  // ← server-side auth — React never sees unauthenticated data
public class DashboardModel : PageModel
{
    private readonly AppDbContext _db;

    // DI injection — same pattern you know from C#
    public DashboardModel(AppDbContext db) => _db = db;

    // JSON strings written into data-* attributes in the .cshtml
    // React reads them back — no fetch() needed
    public string TransactionsJson { get; private set; } = "[]";
    public string SummaryJson      { get; private set; } = "[]";

    public void OnGet()
    {
        // Query once — reuse for both serializations
        var rows = _db.Transactions.ToList();

        // Shape matches what React expects
        var txData = rows.Select(t => new
        {
            t.Id,
            accountNumber = t.AccountNumber,
            amount = double.TryParse(t.Amount, out var a) ? a : 0d,
            type   = t.Type,
            date   = t.Date,
        });

        // Summary: group by type, sum amounts
        var summary = rows
            .GroupBy(t => t.Type)
            .Select(g => new
            {
                type  = g.Key,
                total = g.Sum(t => double.TryParse(t.Amount, out var a) ? a : 0d),
                count = g.Count(),
            });

        // camelCase so JS keys match: t.type, t.amount, s.total
        var opts = new JsonSerializerOptions
        {
            PropertyNamingPolicy = JsonNamingPolicy.CamelCase,
        };

        TransactionsJson = JsonSerializer.Serialize(txData,  opts);
        SummaryJson      = JsonSerializer.Serialize(summary, opts);
    }
}

The Razor Page — Dashboard.cshtml

The page writes the server-processed JSON directly into HTML data attributes. React never makes an API call — it reads from the DOM:

@page
@model DashboardModel

<div
    id="transactions-island"
    data-transactions="@Model.TransactionsJson"
    data-summary="@Model.SummaryJson">
</div>

<script type="module" src="~/js/dashboard.jsx"></script>

The React Island — reads from data attributes

No useEffect, no fetch(), no API call:

import { useState, useMemo } from 'react';
import { createRoot } from 'react-dom/client';

function TransactionsDashboard() {
    const el = document.getElementById('transactions-island');

    // Read server-processed data from data attributes
    // Data was already validated and shaped by C# on the server
    const [transactions] = useState(() =>
        JSON.parse(el.dataset.transactions)
    );
    const [summary] = useState(() =>
        JSON.parse(el.dataset.summary)
    );
    const [filter, setFilter] = useState('All');

    // useMemo from Article 2 — efficient filtering
    const displayed = useMemo(() =>
        filter === 'All'
            ? transactions
            : transactions.filter(t => t.type === filter),
        [transactions, filter]
    );

    return (
        <div>
            {/* Summary cards from server-computed data */}
            {summary.map(s => (
                <div key={s.type}>
                    <h3>{s.type}</h3>
                    <p>Total: ₱{s.total.toLocaleString()}</p>
                    <p>Count: {s.count}</p>
                </div>
            ))}

            {/* Filter buttons */}
            <button onClick={() => setFilter('All')}>All</button>
            <button onClick={() => setFilter('Deposit')}>Deposits</button>
            <button onClick={() => setFilter('Withdraw')}>Withdrawals</button>

            {/* Transaction list */}
            {displayed.map(t => (
                <div key={t.id}>
                    <span>{t.accountNumber}</span>
                    <span>{t.type}</span>
                    <span>₱{t.amount.toLocaleString()}</span>
                </div>
            ))}
        </div>
    );
}

// Mount the React Island
const el = document.getElementById('transactions-island');
if (el) createRoot(el).render(<TransactionsDashboard />);

Why this approach is more secure

Standard React SPA	Razor Pages + React Islands
Auth checked in JavaScript	Auth checked by `[Authorize]` on server
Data fetched client-side	Data processed server-side before page loads
Business logic in browser	Business logic in C# — never leaves server
API endpoints exposed	No additional API endpoints needed
JWT stored in localStorage	Session managed by ASP.NET Core

⚠️ Security note: This approach doesn't mean React SPAs are insecure — they can be built securely too. But for applications dealing with sensitive financial or personal data, keeping processing server-side adds a meaningful layer of protection that C#/.NET developers will immediately recognize and trust.

When to use which approach

This isn't an either/or decision. Here's how I guide my students:

Use React SPA when	Use Razor Pages + React Islands when
Public-facing UI with no sensitive data	Financial or personal data processing
Real-time updates needed (WebSockets)	Server-side auth is non-negotiable
Complex client-side interactions	SEO matters for your pages
Separate frontend team	Existing Razor Pages app adding React gradually
Mobile app consuming the same API	.NET 10 project with mixed page types

In our .NET 10 project we ended up using both — React Islands on sensitive dashboard pages, pure React SPA for the less sensitive reporting pages. The architecture supports both patterns cleanly.

The moment it finally worked

After a day and a half of frustration — fighting with data attribute escaping, JSON serialization options, camelCase vs PascalCase mismatches, and React hydration timing — we got it working.

The dashboard loaded. The data appeared. The filters worked. And most importantly — opening the browser network tab showed exactly zero API calls to our sensitive transaction endpoints.

The room went quiet for a second.

Then someone said: "That's actually really clean."

And they were right. Once you get past the implementation complexity the pattern is elegant — C# does what C# is good at (server-side data processing, authentication, business logic) and React does what React is good at (rendering, interactivity, state management).

Twenty years of .NET experience finally felt like an advantage in a React project rather than baggage to overcome.

What's next in this series

Article 4 will cover AG Grid for C#/.NET developers — column definitions, filtering, sorting, and the pivot table feature that makes your manager's eyes light up. All mapped to concepts you already know from working with data grids in WinForms and WPF.

If you missed the earlier articles:

Part 1 — React fundamentals mapped to C# (JSX, components, props, state)
Part 2 — useEffect finally explained for C# developers (Form_Load, INotifyPropertyChanged, IDisposable)

Want the complete 8-hour training?

Everything in this series plus JWT authentication, AG Grid with pivot tables,
Recharts dashboards, and the complete SecureBank build — packaged as an 8-hour
self-paced guide specifically for C#/.NET developers.

React for C#/.NET Developers — Complete Training Guide

Has your team hit the same security concern with React? How did you solve it? Drop it in the comments — I'd genuinely love to know if others took a different approach. 👇

Why useEffect Confuses Every C# Developer (And How to Finally Think About It)

Dong Atienza — Sun, 12 Apr 2026 02:07:35 +0000

This is Part 2 of the React for C#/.NET Developers
series. Read Part 1 here

If you read my last article about React concepts mapped to C#, you probably nodded along to most of it.

Arrow functions? Same as lambdas. Got it. .map() is just .Select()? Makes sense. useState is like INotifyPropertyChanged? Okay, I can work with that.

And then you hit useEffect. And everything fell apart.

Don't worry — it's not you. useEffect is the one React concept that genuinely has no clean C# equivalent. It trips up every experienced developer coming from a server-side background, and the reason is simple:

It requires you to think about code execution in a completely different way.

This article is going to fix that. For good.

First, let's understand WHY it's confusing

In C#, you control exactly when code runs. You call a method, it executes, it returns. You know the order. You trust the sequence.

// C# — you are in control

public void LoadData()

{

var data = _repository.GetTransactions(); // runs now 

DisplayData(data);                         // runs after 

UpdateStatus("Done");                      // runs last

}

React doesn't work like that. React's job is to render UI — and it will re-render your component whenever it feels like it needs to. State changes, parent re-renders, context updates — React decides when your component runs, not you.

So the question becomes: how do you run code at a specific moment if you're not in control of when your component renders?

The answer is useEffect.

What useEffect actually is

Forget the word "effect" for a moment. It's a terrible name that means nothing to a C# developer.

Think of useEffect as a "run this code when something specific happens" hook. You tell React two things:

What code to run

When to run it

That's it. That's useEffect.

useEffect(() => {

// 1. What to run 

console.log("This ran!");

}, []); // 2. When — [] means once, on mount

The dependency array — the part everyone gets wrong

The second argument to useEffect — the [] — is called the dependency array. This is where most C# developers get confused because there's nothing like it in C#.

Here's the simplest way to understand it:

Dependency array

When useEffect runs

C# equivalent

[] empty

Once — when component first appears

Form_Load / OnInitialized

[value]

On mount + every time value changes

INotifyPropertyChanged

nothing (no [])

After every single render

No direct equivalent

Pattern 1: Run once on mount — fetch your data

This is what you'll write 80% of the time. Fetch data from your API when the component first loads — exactly like Form_Load in WinForms or OnInitialized in Blazor.

useEffect(() => {

// Runs ONCE when component first appears 

fetch("/api/transactions", { 

    headers: { 

        Authorization: `Bearer ${localStorage.getItem("jwt_token")}` 

    } 

}) 

.then(response => response.json()) 

.then(data => { 

    setTransactions(data); 

    setIsLoading(false); 

});

}, []); // ← empty array = run once

C# mental model:

// Closest C# equivalent

protected override async Task OnInitializedAsync()

{

transactions = await _api.GetTransactionsAsync(); 

isLoading = false;

}

Pattern 2: Run when a value changes — reactive fetching

Re-fetch data whenever a filter or ID changes — without writing a bunch of event handlers.

function TransactionDetail({ accountId }) {

const [account, setAccount] = useState(null); 



useEffect(() => { 

    // Runs on mount AND every time accountId changes 

    fetch(`/api/accounts/${accountId}`) 

        .then(r => r.json()) 

        .then(setAccount); 

}, [accountId]); // ← re-run when accountId changes 



if (!account) return <p>Loading...</p>; 

return <h2>{account.accountNumber}</h2>;

}

Pattern 3: The cleanup function — often forgotten, always important

useEffect can return a function. That function runs when the component is removed from the screen. It's your cleanup code.

useEffect(() => {

// Setup 

const timer = setInterval(() => { 

    console.log("Checking for new transactions..."); 

}, 5000); 



// Cleanup — runs when component unmounts 

return () => { 

    clearInterval(timer); 

};

}, []);

C# equivalent — think IDisposable:

public void Dispose()

{

_timer?.Stop(); 

_timer?.Dispose();

}

The mistake every C# developer makes at least once

WARNING

This useEffect looks perfectly reasonable and will cause you hours of debugging pain.

// WRONG — infinite loop!

useEffect(() => {

fetch("/api/data") 

    .then(r => r.json()) 

    .then(result => setData(result)); // updates state

}, [data]); // ← data is the dependency

// What happens:

// 1. Renders → useEffect runs → fetches data

// 2. setData updates state → triggers re-render

// 3. Re-render → useEffect runs again (data changed!)

// 4. Fetch again → setData → re-render → infinite loop 🔥

The fix:

// CORRECT — run once, don't watch data

useEffect(() => {

fetch("/api/data") 

    .then(r => r.json()) 

    .then(result => setData(result));

}, []); // ← empty array, runs once

GOLDEN RULE

Never put state in the dependency array if that same useEffect updates that state. You will create an infinite loop.

Putting it all together — a real component

Here's a complete TransactionDashboard component that uses every pattern we covered — plus concepts from the first article:

function TransactionDashboard({ accountId }) {

const [transactions, setTransactions] = useState([]); 

const [isLoading, setIsLoading] = useState(true); 

const [filter, setFilter] = useState("All"); 



// Fetch when accountId changes + cleanup 

useEffect(() => { 

    setIsLoading(true); 

    const controller = new AbortController(); 



    fetch(`/api/accounts/${accountId}/transactions`, { 

        headers: { Authorization: `Bearer ${localStorage.getItem("jwt_token")}` }, 

        signal: controller.signal 

    }) 

    .then(r => r.json()) 

    .then(data => { setTransactions(data); setIsLoading(false); }) 

    .catch(err => { if (err.name !== "AbortError") setIsLoading(false); }); 



    return () => controller.abort(); // cleanup 

}, [accountId]); 



// useMemo — from Article 1 

const totals = useMemo(() => ({ 

    deposits: transactions.filter(t => t.type === "Deposit") 

                          .reduce((sum, t) => sum + t.amount, 0), 

    withdrawals: transactions.filter(t => t.type === "Withdraw") 

                             .reduce((sum, t) => sum + t.amount, 0), 

}), [transactions]); 



// .filter() — from Article 1 

const displayed = filter === "All" 

    ? transactions 

    : transactions.filter(t => t.type === filter); 



if (isLoading) return <p>Loading...</p>; 



return ( 

    <div> 

        <p>Deposits: ₱{totals.deposits.toLocaleString()}</p> 

        <p>Withdrawals: ₱{totals.withdrawals.toLocaleString()}</p> 

        <button onClick={() => setFilter("All")}>All</button> 

        <button onClick={() => setFilter("Deposit")}>Deposits</button> 

        <button onClick={() => setFilter("Withdraw")}>Withdrawals</button> 

        <ul> 

            {displayed.map(t => ( 

                <li key={t.id}>{t.accountNumber} — {t.type} — ₱{t.amount.toLocaleString()}</li> 

            ))} 

        </ul> 

    </div> 

);

}

The mental model that finally makes it click

Stop thinking about when code runs and start thinking about what your component depends on.

C# developer thinks

React developer thinks

I need to call this method when X happens

My component needs Y data when Z changes

I control the execution order

I declare dependencies, React handles timing

Methods run when I call them

Effects run when their dependencies change

Once you internalize that shift, useEffect stops being confusing and starts feeling like the cleanest reactive system you've ever worked with.

Quick reference — useEffect cheat sheet

// 1. Run once on mount (most common — data fetching)

useEffect(() => { fetchData(); }, []);

// 2. Run when value changes (reactive)

useEffect(() => { fetchAccountData(accountId); }, [accountId]);

// 3. Run with cleanup (timers, subscriptions)

useEffect(() => {

const timer = setInterval(checkForUpdates, 5000); 

return () => clearInterval(timer);

}, []);

// 4. NEVER do this unless you know exactly why

useEffect(() => { /* runs after every render */ });

What's next

In the next article we'll cover Context and the JWT authentication flow — how to store your token once after login and make it available to every component in your app without prop drilling.

If you missed Article 1 where we covered arrow functions, .map(), useState and components — go back and read that first, then come back here.

Want to go deeper?

I put together a complete 8-hour React training guide built specifically for C#/.NET developers — JWT auth, AG Grid, Recharts, and a full SecureBank dashboard build with exercises and solutions included.

React for C#/.NET Developers — Complete Training Guide

What's the React concept still tripping you up? Drop it in the comments — your question might become the next article in this series.

I've Been Writing C# for Years. Here's What Nobody Told Me About React.

Dong Atienza — Fri, 10 Apr 2026 00:04:14 +0000

_When my team said we were adding a React frontend to our .NET API, I did what any self-respecting senior developer does.

I Googled it. Watched a YouTube tutorial for 20 minutes. Closed the tab. Opened a new tab. Googled "React for C# developers." Got results that assumed I was either a complete beginner who didn't know what a variable was, or a JavaScript wizard who already knew what a closure was._

I was neither. I was a C# developer. I knew exactly what I was doing — just not in this language.

So I figured it out the hard way. And now I'm going to save you the weeks I wasted by mapping every React concept directly to what you already know in C#.

No "what is a variable" explanations. No JavaScript history lessons. Just: here's what you know, here's what it's called in React, here's why it works the same way.

First, the mindset shift

In C#, the server does the work. Your controller fetches data, builds a model, passes it to a Razor view, and the browser gets back finished HTML. The browser is basically a dumb terminal receiving rendered output.

React flips this completely. You ship JavaScript to the browser, and the browser builds the UI itself. Your .NET API becomes just a data supplier — it hands over JSON and React figures out the rest.

C#/.NET world: Browser → Server → Server renders HTML → Browser displays it
React world: Browser → Server → Server returns JSON → Browser renders it

That's the whole paradigm shift. Everything else is just syntax.

Variables: You already know this

This one's genuinely easy. JavaScript has three ways to declare variables and they map almost perfectly to what you already know.

JavaScript	C# Equivalent	When to use
`const name = "John"`	`readonly string name = "John"`	Value won't change — use this by default
`let count = 0`	`int count = 0`	Value will change (loop counters, etc.)
`var name = "John"`	`var name = "John"`	Old style — avoid in modern JS

The mental model: use const for everything until you need to reassign it, then use let. Forget var exists. Seriously.

// JavaScript
const apiUrl = "https://api.myapp.com";   // won't change
let currentPage = 1;                       // will change as user navigates

// Compare to C#
readonly string apiUrl = "https://api.myapp.com";
int currentPage = 1;

Arrow Functions: You've already been writing these

Here's something that'll make you smile. You've been writing arrow functions in C# for years. You just called them lambdas.

// C# lambda
var double = (int x) => x * 2;
double(5); // returns 10

// JavaScript arrow function — almost identical!
const double = (x) => x * 2;
double(5); // returns 10

The syntax is nearly the same. The behavior is nearly the same. The only real difference is types — JavaScript doesn't have them (unless you use TypeScript, which is a conversation for another day).

Multi-line works the same way too:

// Single line — implicit return, no braces needed
const add = (a, b) => a + b;

// Multi-line — use braces, explicit return required
const getTotal = (transactions) => {
    const sum = transactions.reduce((acc, t) => acc + t.amount, 0);
    return sum;
};

Array Methods: LINQ with different names

This is where C# developers get an instant superpower in JavaScript. You already know how to think in LINQ. JavaScript's array methods are the same operations with different names.

JavaScript	LINQ Equivalent	What it does
`.map(fn)`	`.Select(fn)`	Transforms each item — returns new array
`.filter(fn)`	`.Where(fn)`	Returns items matching a condition
`.reduce(fn, init)`	`.Aggregate(init, fn)`	Reduces to a single value (totals, sums)
`.find(fn)`	`.FirstOrDefault(fn)`	Returns first match or undefined
`.some(fn)`	`.Any(fn)`	Returns true if any item matches
`.every(fn)`	`.All(fn)`	Returns true if all items match

👉 React for C#/.NET Developers — Complete Training Guide

// C# LINQ
var amounts = transactions.Select(t => t.Amount).ToList();
var deposits = transactions.Where(t => t.Type == "Deposit").ToList();
var total = transactions.Aggregate(0m, (sum, t) => sum + t.Amount);

// JavaScript — same logic, different syntax
const amounts = transactions.map(t => t.amount);
const deposits = transactions.filter(t => t.type === "Deposit");
const total = transactions.reduce((sum, t) => sum + t.amount, 0);

Why this matters for React: .map() is how you render lists. Instead of returning transformed values, you return JSX elements. This single pattern is responsible for roughly 40% of the React code you'll ever write.

// Rendering a list in React — it's just .map() returning JSX
return (
    <ul>
        {transactions.map(t => (
            <li key={t.id}>{t.accountNumber}: ${t.amount}</li>
        ))}
    </ul>
);

Components: Partial Views with superpowers

A React component is a JavaScript function that returns HTML-like syntax (called JSX). Think of it as a Razor Partial View that also contains its own controller logic.

// C# — ViewComponent (closest equivalent)
public class TransactionCardViewComponent : ViewComponent
{
    public IViewComponentResult Invoke(string accountNumber, decimal amount, string type)
    {
        return View(new TransactionCardViewModel { ... });
    }
}

// React — same idea, dramatically less ceremony
function TransactionCard({ accountNumber, amount, type }) {
    const color = type === "Deposit" ? "green" : "red";

    return (
        <div>
            <h3>{accountNumber}</h3>
            <p style={{ color }}>₱{amount.toLocaleString()}</p>
        </div>
    );
}

// Use it like a custom HTML tag anywhere in your app
<TransactionCard accountNumber="ACC-001" amount={5000} type="Deposit" />

The JSX syntax looks weird at first — HTML inside JavaScript? — but you get used to it within a day. The key rules:

class becomes className (because class is a reserved word in JavaScript)
for becomes htmlFor on labels
Every tag must be closed — <br /> not <br>
Curly braces {} embed JavaScript expressions, exactly like @() in Razor

Props: Method parameters, but for components

Props are how you pass data into a component. They work exactly like parameters to a C# method — the caller provides values, the component uses them, and they're read-only inside the component.

// C# method — you pass parameters
public string FormatTransaction(string accountNumber, decimal amount)
{
    return $"{accountNumber}: ₱{amount:N0}";
}

// React component — you pass props (same idea)
function TransactionRow({ accountNumber, amount }) {
    return <p>{accountNumber}: ₱{amount.toLocaleString()}</p>;
}

// Calling it — like calling a method, but in JSX
<TransactionRow accountNumber="ACC-001" amount={5000} />

The destructuring syntax { accountNumber, amount } in the function parameter is just JavaScript's way of pulling named properties out of an object. It's sugar for props.accountNumber, props.amount.

State: The concept that makes React click

This is where React gets genuinely different from anything in server-side C# — and once it clicks, everything makes sense.

State is data that belongs to a component and can change over time. When state changes, React automatically re-renders the component with the new value. No manual DOM manipulation, no page reload. The UI just updates.

import { useState } from "react";

function TransactionFilter() {
    // const [currentValue, setterFunction] = useState(initialValue)
    const [filter, setFilter] = useState("All");

    return (
        <div>
            <button onClick={() => setFilter("All")}>All</button>
            <button onClick={() => setFilter("Deposit")}>Deposits</button>
            <button onClick={() => setFilter("Withdraw")}>Withdrawals</button>

            <p>Currently showing: {filter}</p>
        </div>
    );
}

The closest C# mental model: think of useState like INotifyPropertyChanged — when the value changes, something automatically updates in response. Except React handles the "update the UI" part for you automatically.

The golden rule that trips up every C# developer at least once:

// WRONG — this does nothing to the UI
filter = "Deposit";

// CORRECT — this triggers a re-render
setFilter("Deposit");

React only knows to re-render the component when you use the setter function. Direct assignment is invisible to React. Burn this into your brain on day one.

useEffect: The Form_Load event you always wanted

useEffect is how you run code at specific moments in a component's life — most commonly to fetch data when the component first appears on screen.

import { useState, useEffect } from "react";

function TransactionList() {
    const [transactions, setTransactions] = useState([]);
    const [isLoading, setIsLoading] = useState(true);

    useEffect(() => {
        // This runs once when the component first renders
        fetch("/api/transactions", {
            headers: { Authorization: `Bearer ${localStorage.getItem("jwt_token")}` }
        })
        .then(r => r.json())
        .then(data => {
            setTransactions(data);
            setIsLoading(false);
        });
    }, []); // ← the empty [] means "run once on mount"

    if (isLoading) return <p>Loading...</p>;

    return (
        <ul>
            {transactions.map(t => <li key={t.id}>{t.accountNumber}</li>)}
        </ul>
    );
}

The second argument to useEffect is the dependency array:

Syntax	When it runs	C# equivalent
`useEffect(() => {}, [])`	Once on mount	`Form_Load`
`useEffect(() => {}, [id])`	On mount + every time `id` changes	`INotifyPropertyChanged`
`useEffect(() => {})`	After every render	No direct equivalent

Context: Dependency Injection without the ceremony

If you've ever needed to pass a value (like a JWT token or the current user) through five levels of components, you've hit "prop drilling" — passing props down through components that don't even need them just to get them to a component that does.

Context solves this exactly the way DI solves it in C# — register it once, consume it anywhere.

// 1. Create the context (like registering in DI container)
const AuthContext = createContext(null);

export function AuthProvider({ children }) {
    const [token, setToken] = useState(localStorage.getItem("jwt_token"));

    return (
        <AuthContext.Provider value={{ token, setToken }}>
            {children}
        </AuthContext.Provider>
    );
}

// 2. Wrap your app — once
<AuthProvider>
    <App />
</AuthProvider>

// 3. Consume anywhere — no prop drilling needed
function NavBar() {
    const { token } = useContext(AuthContext);
    return <p>Logged in: {token ? "Yes" : "No"}</p>;
}

// C# equivalent mindset
// 1. Register in DI: services.AddScoped<IAuthService, AuthService>();
// 2. Inject anywhere: public NavController(IAuthService auth) { }

Same problem, same solution, different syntax.

The one thing that takes the longest to unlearn

Coming from C#, your instinct is to think about when things happen. You're used to sequential execution — line 1 runs, then line 2, then line 3.

React is declarative. You describe what the UI should look like given the current state, and React figures out when and how to make it happen. You stop thinking "do this when the user clicks" and start thinking "the UI looks like X when the filter is Y."

This is the shift that takes a few days to internalize. Be patient with yourself on this one. It's not a syntax problem — it's a mindset problem. And once it clicks, you'll wonder how you ever thought the other way.

Where to go from here

If this mapped well to how you think, I put together a complete 8-hour React training guide built specifically for C#/.NET developers — every concept extended further than this article, with hands-on exercises, full solutions, and a complete SecureBank dashboard build using JWT auth, AG Grid, and Recharts.

👉 React for C#/.NET Developers — Complete Training Guide

It's the guide I wish existed when I started. Hope it saves you the weeks it took me to figure this out.

Got questions? Drop them in the comments — especially if something here didn't map the way you expected. Those are usually the most interesting discussions.