Custom Hooks

What you should be able to do

Before you start

• Complete the previous lesson in React — TaskFlow Lite Application or demonstrate equivalent skill.
• Start from a healthy project/checkpoint.

Understand the boundary before the syntax

This lesson is about Custom Hooks. Keep the idea practical: in the React TaskFlow Lite application, the worked example should show that the hook packages reusable state/effect logic while each component calling it still owns its own hook state. Once you can explain why that happens, the name is much easier to remember.

Now place it in TaskFlow. This lesson belongs to the React version of TaskFlow Lite and the rules for state, rendering, effects, and component ownership. Ask four questions while you work: what enters this boundary, who owns the decision, what dependency does it use, and what evidence proves the result?

Keep the change small. Predict what you should see before you run anything, then compare the prediction with the real terminal, browser, HTTP, database, test, container, or CI evidence. If they differ, debug the first mismatch instead of editing several places at random.

The goal is not to remember the exact snippet below. The goal is to be able to explain Custom Hooks in your own words, rebuild the core behavior, and adapt it when the requirement changes.

Know where you are before changing code

You are working inside the React — TaskFlow Lite Application track. The project is healthy before this lesson, and the learner has completed the preceding checkpoint.

1. 01

   Open the project root in VS Code and a terminal.

2. 02

   Confirm you are on the intended Git branch and have no unrelated uncommitted changes.

3. 03

   Run the previous checkpoint verification before changing code.

4. 04

   Keep browser DevTools, API client, database console, or Docker logs visible when they are relevant to the boundary.

Build it in small pieces you can explain

1. 01

   State the requirement for Custom Hooks in one observable sentence. Avoid implementation words at first; describe what a user, caller, compiler, database, or deployment should observe.

2. 02

   Confirm the baseline is healthy. Run the narrowest existing verification and record the result so a new failure can be attributed to this lesson rather than an earlier problem.

3. 03

   Inspect the current boundary relevant to Custom Hooks. Identify the input, owner, dependency, output, and failure mode before adding code.

4. 04

   Read the working example below without running it. Predict the exact output, HTTP status, compiler result, database state, UI state, or deployment evidence.

5. 05

   Type the smallest working slice yourself. Do not paste a finished subsystem. Keep the diff small enough that every new line can be explained.

6. 06

   Run the narrowest command or interaction that proves the slice. Compare the observed evidence with the prediction and write down any mismatch.

7. 07

   Extend the slice one step toward TaskFlow. Preserve the same ownership rule while replacing toy data with the real project boundary used by Custom Hooks.

8. 08

   Introduce the controlled failure described below. Capture the first useful error line, request/response, query plan, browser state, test failure, container log, or CI job evidence before editing anything.

9. 09

   Locate the first boundary where expected and actual evidence diverge. Change only the root cause, then rerun exactly the same verification.

10. 10

    Add a repeatable regression check when practical: a test, type assertion, SQL constraint, health check, CI gate, security test, or documented smoke-test step.

11. 11

    Close the lesson and rebuild the core behavior from memory. If you cannot explain one step, reopen only that section rather than copying the whole solution.

function useOnlineStatus() {
  const [online, setOnline] = useState(() => navigator.onLine);
  useEffect(() => {
    const sync = () => setOnline(navigator.onLine);
    addEventListener("online", sync); addEventListener("offline", sync);
    return () => { removeEventListener("online", sync); removeEventListener("offline", sync); };
  }, []);
  return online;
}

Prove that it works

Controlled failure lab

Break the exact assumption this lesson depends on. For **Custom Hooks**, change one input, configuration, ordering rule, permission, state transition, or dependency so the example can no longer satisfy its contract. Before running it, write down the failure you expect. Then run the same verification, capture the first useful symptom, and repair only the root cause.

Things that usually confuse learners

Follow → modify → debug → build → defend

Answer in your own words before opening the answer

What changes in a real application

In production, Custom Hooks must have an observable failure mode. Decide what should be logged, measured, tested, constrained, or surfaced without leaking sensitive data.

Prefer explicit contracts over conventions that only one developer understands. The next engineer should be able to locate the owner of this behavior from the project structure and tests.

Do not add abstraction merely because the course mentions it. Introduce additional layers only when they isolate a real volatility, boundary, policy, or testability problem.

Before you leave this page

• You should now be able to describe Custom Hooks simply.
• You should know how it fits into the React version of TaskFlow Lite and the rules for state, rendering, effects, and component ownership.
• You should have one working example, one deliberate failure, and one independent variation.

Continue only when these feel true