Vasim Shaikh’s Post

The useEffect mistake I still see in every code review. Developers treating it like a lifecycle method instead of a synchronization tool. Common pattern I keep finding: useEffect(() => { if (user) { fetchUserData(user.id); } }, [user]); Looks harmless. But ask yourself: What is this synchronizing with? The component renders → user changes → data fetches. Fine. But what happens when the component mounts and user already exists? Fetch runs twice. What happens when user data is stale in cache? No way to know. Better approach: Separate the "what" from the "when." const fetchDataForUser = useCallback(async (userId) => { // fetch logic here }, []); // Call it when you actually need to useEffect(() => { if (user) { fetchDataForUser(user.id); } }, [user, fetchDataForUser]); Still not perfect. But now the fetch logic is reusable and testable. Even better: Use a data fetching library (React Query, SWR) that handles caching, refetching, and race conditions so you don't have to. What I tell juniors now: useEffect is a sharp tool. Don't reach for it first. Ask: Does this need to be in an effect? Could it be derived during render? Should it be in an event handler instead? The best useEffect is sometimes the one you don't write. What React pattern took you longest to unlearn? #reactjs #javascript #frontend #coding #webdev #bestpractices

To view or add a comment, sign in

Explore content categories