Routing, Frameworks, and Next Steps

Client and server thinking

Separate browser UI from trusted server work.

8 minutes - Intermediate to advanced

What this means

Client code runs in the user's browser. Server code runs on your infrastructure. UI interactions can happen on the client, but secrets, permissions, and database writes belong on the server.

In beginner terms, this topic answers one practical question: "What should I write, and why does React care about it?" Do not try to memorize the syntax first. First understand the idea, then connect the syntax to that idea.

Why it matters

Modern React frameworks often mix client and server ideas. The security rule stays simple: never trust the browser with secrets or authority.

When you build real React screens, this idea helps you decide where data should live, what the user should see, and what should happen after an interaction. That is why this lesson is part of the main path instead of being an optional detail.

Step by step

1. Notice the UI problem this topic solves. 2. Look at the smallest possible example. 3. Change one value and predict what should appear. 4. Run the example and compare the result with your prediction. 5. Use the practice task before moving on.

Small example

Client: button click
Server: validate and save

Common mistake

Do not put API keys, database credentials, or role checks only in client components.

Practice task

Decide whether login validation, button animation, and database save belong on client or server.

Remember this

The browser is interactive, but the server is trusted.

try.it

Examples

Try it: Client and server thinking

Edit this focused React example and run it in the browser preview.

Preview runs React in a sandboxed browser frame, never on the server.

react

editor

preview

Preparing preview...

practice.next

Practice before moving on

check.understanding

Lesson quiz

Login to save progress

You can read lessons without an account, but progress requires login.

Login