Do not store what you can derive
If a value can be calculated from props or existing state during render, storing it separately creates a synchronization problem. Derived state bugs are quiet because the UI can look correct until one update path is missed.
// Usually avoid:
const [fullName, setFullName] = useState("");
// Prefer:
const fullName = firstName + " " + lastName;useEffect is not a general-purpose state machine
Effects are for synchronizing with external systems. If an effect only updates state based on other state, ask whether the value should be derived, calculated in an event handler, or handled by a reducer.
Try the idea
Full name is derived during render, so it cannot fall out of sync with first or last name.
Keep state close to where it changes
Global state feels convenient until every feature can accidentally depend on it. Prefer local state first, lifted state when siblings need it, reducer state for complex transitions, and server/cache state for data owned by the backend.
Production notes for React apps
React code becomes fragile when boundaries are vague. Before adding state, effects, or client components, decide what owns the data and what actually needs to run in the browser.
A production-ready React feature should be readable from the data boundary down to the interaction boundary. If every component knows everything, future changes become expensive.
Conclusion
Maintainable React state starts by deleting state you did not need to store.