Muhammod Ajibade’s Post

𝐘𝐨𝐮𝐫 𝐮𝐬𝐞𝐌𝐞𝐦𝐨 𝐡𝐨𝐨𝐤 𝐦𝐢𝐠𝐡𝐭 𝐛𝐞 𝐝𝐨𝐢𝐧𝐠 𝐦𝐨𝐫𝐞 𝐡𝐚𝐫𝐦 𝐭𝐡𝐚𝐧 𝐠𝐨𝐨𝐝 𝐢𝐧 𝐑𝐞𝐚𝐜𝐭. I often see teams wrapping entire components or complex JSX trees in `useMemo` thinking it's a magic bullet to prevent re-renders. While `useMemo` can optimize expensive calculations, it's not designed to prevent component re-renders. That's `React.memo`'s job. Here's the distinction: - **`useMemo`**: Memoizes a value. If its dependencies haven't changed, it returns the previously computed value without re-running the function. This is great for heavy computations or preparing data. - **`React.memo`**: Memoizes a component. It performs a shallow comparison of props and only re-renders the component if those props have changed. Misusing `useMemo` for components can lead to: 1. **Overhead**: `useMemo` itself has a cost. If the memoized value isn't computationally expensive, the overhead of memoization might outweigh the benefits. 2. **False sense of security**: Your component might still re-render if its parent re-renders, unless the component itself is wrapped in `React.memo` (and its props are stable). **When to use what:** - Use `useMemo` for expensive calculations inside a component (e.g., filtering large arrays, complex data transformations). - Use `React.memo` to prevent unnecessary re-renders of child components when their props are stable across parent renders. Combine with `useCallback` for memoizing function props. Understanding this subtle difference can significantly impact your app's performance and prevent common optimization pitfalls. What's your biggest React performance gotcha you've had to debug? #React #FrontendDevelopment #WebDevelopment #JavaScript #Performance

Dynamic forms let users add/remove fields on the fly — useful for things like multiple users, skills, or credentials. 🔹 Start with state Use useState to store an array of objects (each object = one form row). 🔹 Handle input changes Update specific fields using index + computed property names: Keeps state immutable and predictable. 🔹 Add fields Clone the array and insert a new empty object (unshift or push). 🔹 Remove fields Filter out the selected index, with a guard to keep at least one field. 🔹 Render dynamically Use .map() to generate inputs and bind each to its index. 💡 Key idea: Treat form fields as data, not UI. Once your state is structured well, the UI becomes easy. #React #Frontend #WebDevelopment #MERN #JavaScript

I spent 3 hours debugging a “simple” frontend issue… and it turned out to be one line. The problem? An API was getting called on every keystroke. Network tab = chaos 👀 Dozens of API calls for a single search. 👉 The issue: No debouncing. Here’s what the code looked like before: useEffect(() => { if (!query) return; fetch(`https://lnkd.in/eNE6UBeq) .then(res => res.json()) .then(data => setData(data)); }, [query]); Every keypress → API call ❌ Here’s the fix (debouncing): useEffect(() => { if (!query) return; const timer = setTimeout(() => { fetch(`https://lnkd.in/eNE6UBeq) .then(res => res.json()) .then(data => setData(data)); }, 300); return () => clearTimeout(timer); }, [query]); ✅ API calls reduced by ~70% ✅ Smoother UI ✅ Better user experience Lesson: Frontend performance isn’t just about what you render… It’s about when you trigger things. Small change. Big impact. Have you used debouncing or throttling in your apps? Where did it make the biggest difference? #frontend #reactjs #javascript #webperformance #softwareengineering

Every useEffect that sets up a subscription, timer, or event listener must clean up after itself. ```js // Memory leak — listener accumulates on every render useEffect(() => { window.addEventListener('resize', handleResize); // No cleanup — listener is never removed }); // Correct — cleanup runs before next effect and on unmount useEffect(() => { window.addEventListener('resize', handleResize); return () => window.removeEventListener('resize', handleResize); }, []); ``` Other effects that require cleanup: ```js // Timers const timer = setTimeout(callback, 1000); return () => clearTimeout(timer); // Fetch abort const controller = new AbortController(); fetch(url, { signal: controller.signal }); return () => controller.abort(); // Subscriptions const sub = observable.subscribe(handler); return () => sub.unsubscribe(); ``` Memory leaks accumulate silently. Clean up your effects — every time. #ReactJS #JavaScript #Frontend #WebDevelopment

useDebounce vs debounce() I got this wrong for months. Working on user forms and search where, every keystroke was triggering an API call. I reached for debounce() first. Big mistake. Here’s what I learned: Wrong - debounce() in render body // Re-creates a new debounced fn on EVERY render const handleSearch = debounce((val) => fetchResults(val), 300); Better - but needs careful handling // Stable across renders, but you manage the fn ref const handleSearch = useRef( debounce((val) => fetchResults(val), 300) ).current; Cleanest - useDebounce hook const [query, setQuery] = useState(''); const debouncedQuery = useDebounce(query, 300); useEffect(() => { if (debouncedQuery) fetchResults(debouncedQuery); }, [debouncedQuery]); // fires only after user stops typing The core difference: debounce(fn) → delays a function call. Lives outside React. Needs useRef to stay stable. useDebounce(value) → delays a state value. React-native, auto-cleanup via useEffect. No ref juggling. My rule now: → Input-driven API calls? useDebounce → Click/scroll/resize handlers? debounce() inside useRef This one pattern alone cut our unnecessary API calls by ~80% on the search feature. What’s your go-to approach? Drop it below 👇 #React #ReactHooks #FrontendEngineering #JavaScript #WebPerformance #ReactDeepDive #SeniorEngineer

Recently built a Financial Dashboard to track balances, transactions, and spending insights. Live demo :- https://lnkd.in/dVD-CPeC The goal was to design a clean, data-driven UI while keeping state management simple and scalable. Tech stack: React (Vite), JavaScript, Tailwind CSS, Zustand Key features: Balance, income, and expense tracking Spending breakdown and trend visualization Savings rate calculation Export options (CSV/JSON) Responsive, component-driven UI Focus areas: Structured state management using Zustand Reusable and maintainable component design Clear data visualization for better decision-making This project helped reinforce building production-style dashboards with a focus on performance and clarity. #React #Frontend #JavaScript #WebDevelopment #TailwindCSS

Who really owns your form data? In a standard HTML input, the DOM is the boss. It holds the value in its own internal memory, and you only "ask" for it when the user hits submit. But in React, we don't like hidden state. We want every piece of data to be explicit and predictable. This is where Controlled Components come in. In this pattern, the React state is the single source of truth. The input doesn't maintain its own value. Instead, you tell the input exactly what to display using the 'value' prop, and you update that value through an 'onChange' handler that modifies the state. The input is "controlled" because its behavior is entirely driven by the React component. Why go through this extra boilerplate? It gives you total coordination over the UI. Since the data lives in your state, you can perform instant field validation, disable the submit button based on specific criteria, or even format the user's input in real-time. There is no "syncing" issue between the DOM and your logic because they are never out of alignment. Of course, controlling every single character stroke in a massive form can feel like overkill. For simple, high-performance scenarios where you just need the data at the end, Uncontrolled Components using 'refs' might be faster. But for most applications, the predictability of a controlled flow far outweighs the cost of a few extra lines of code. It ensures that what the user sees is exactly what your application "knows". #ReactJS #SoftwareEngineering #WebDevelopment #FrontendArchitecture #CodingTips #Javascript

A well-intentioned optimisation broke my component silently. Here's what happened. 🧵 I built a component that read a URL param and rendered based on it. It worked perfectly. Later, while optimising, the callback was wrapped in useCallback with all state dependencies correctly added. But one thing was missing. The URL param — fetched via useSearchParams — wasn’t in the dependency array. Reports came in: the component wasn’t updating when the URL changed. Tracing through the code, the issue was clear. The callback captured the initial param value and never updated. The UI changed, but the logic was stuck with stale data. The fix? One line: add the param to the dependency array. But the interesting part isn’t the fix. It’s why this was easy to miss. When we think “what does this depend on?”, we think props and state. Router values don’t feel like dependencies — but they are. 👉 This becomes even more subtle with useSearchParams vs useParams. Path params usually change during navigation, making bugs visible. Query params can change without navigation — the UI updates, but callbacks may still hold stale values. The lesson: → Optimisations should never change behaviour → Router values belong in dependency arrays → eslint-plugin-react-hooks (exhaustive-deps) catches this — use it Have you hit a stale closure bug in useCallback or useMemo? Drop it below 👇 (Detailed breakdown with code examples in comments) #React #JavaScript #Frontend #WebDevelopment #ReactHooks #SoftwareEngineering

Most developers know map, filter and reduce exist. Fewer know when to use which one. Here is how I think about it: map() — when you need to transform every element Same number of items in, same number out. Just different shape. filter() — when you need to remove some elements Same data, fewer items. Nothing is transformed. reduce() — when you need one value from the whole array Total, average, grouped object, flat list — anything single. The real power comes from chaining them: devs  .filter(d => d.active)  .map(d => d.name)  .sort() Three operations. One clean chain. No loops. No temporary variables. And the ones people forget: find() — returns one element, not an array some() — true if at least one matches every() — true only if all match flatMap() — map + flatten in one step Save this for your next code review. Which array method do you reach for most often? #JavaScript #WebDevelopment #Frontend #CleanCode #SoftwareEngineering

⚛️ 𝗜𝗺𝗽𝗿𝗼𝘃𝗶𝗻𝗴 𝗥𝗲𝗮𝗰𝘁 𝗣𝗲𝗿𝗳𝗼𝗿𝗺𝗮𝗻𝗰𝗲 — 𝗨𝘀𝗶𝗻𝗴 𝗖𝗼𝗱𝗲 𝗦𝗽𝗹𝗶𝘁𝘁𝗶𝗻𝗴 As React applications grow, bundle size increases — which directly impacts initial load time. Common problem: • large JS bundle • slow first load • unnecessary code loaded upfront A better production approach is 𝗖𝗼𝗱𝗲 𝗦𝗽𝗹𝗶𝘁𝘁𝗶𝗻𝗴. ❌ 𝗪𝗶𝘁𝗵𝗼𝘂𝘁 𝗖𝗼𝗱𝗲 𝗦𝗽𝗹𝗶𝘁𝘁𝗶𝗻𝗴 𝘪𝘮𝘱𝘰𝘳𝘵 𝘋𝘢𝘴𝘩𝘣𝘰𝘢𝘳𝘥 𝘧𝘳𝘰𝘮 "./𝘋𝘢𝘴𝘩𝘣𝘰𝘢𝘳𝘥"; 𝘪𝘮𝘱𝘰𝘳𝘵 𝘙𝘦𝘱𝘰𝘳𝘵𝘴 𝘧𝘳𝘰𝘮 "./𝘙𝘦𝘱𝘰𝘳𝘵𝘴"; 𝘪𝘮𝘱𝘰𝘳𝘵 𝘚𝘦𝘵𝘵𝘪𝘯𝘨𝘴 𝘧𝘳𝘰𝘮 "./𝘚𝘦𝘵𝘵𝘪𝘯𝘨𝘴"; All components load upfront — even if not used immediately. ❌ 𝗪𝗶𝘁𝗵𝗼𝘂𝘁 𝗖𝗼𝗱𝗲 𝗦𝗽𝗹𝗶𝘁𝘁𝗶𝗻𝗴 𝘪𝘮𝘱𝘰𝘳𝘵 { 𝘭𝘢𝘻𝘺, 𝘚𝘶𝘴𝘱𝘦𝘯𝘴𝘦 } 𝘧𝘳𝘰𝘮 "𝘳𝘦𝘢𝘤𝘵"; 𝘤𝘰𝘯𝘴𝘵 𝘋𝘢𝘴𝘩𝘣𝘰𝘢𝘳𝘥 = 𝘭𝘢𝘻𝘺(() => 𝘪𝘮𝘱𝘰𝘳𝘵("./𝘋𝘢𝘴𝘩𝘣𝘰𝘢𝘳𝘥")); 𝘤𝘰𝘯𝘴𝘵 𝘙𝘦𝘱𝘰𝘳𝘵𝘴 = 𝘭𝘢𝘻𝘺(() => 𝘪𝘮𝘱𝘰𝘳𝘵("./𝘙𝘦𝘱𝘰𝘳𝘵𝘴")); 𝘧𝘶𝘯𝘤𝘵𝘪𝘰𝘯 𝘈𝘱𝘱() {   𝘳𝘦𝘵𝘶𝘳𝘯 (     <𝘚𝘶𝘴𝘱𝘦𝘯𝘴𝘦 𝘧𝘢𝘭𝘭𝘣𝘢𝘤𝘬={<𝘱>𝘓𝘰𝘢𝘥𝘪𝘯𝘨...</𝘱>}>       <𝘋𝘢𝘴𝘩𝘣𝘰𝘢𝘳𝘥 />       <𝘙𝘦𝘱𝘰𝘳𝘵𝘴 />     </𝘚𝘶𝘴𝘱𝘦𝘯𝘴𝘦>   ); } Now components load 𝗼𝗻𝗹𝘆 𝘄𝗵𝗲𝗻 𝗻𝗲𝗲𝗱𝗲𝗱. 📌 Where this helps most: • large dashboards • admin panels • multi-page apps • heavy third-party libraries 📌 𝗣𝗿𝗼𝗱𝘂𝗰𝘁𝗶𝗼𝗻 𝗕𝗲𝗻𝗲𝗳𝗶𝘁𝘀: • faster initial load • reduced bundle size • better performance • improved user experience 📌 𝗕𝗲𝘀𝘁 𝗣𝗿𝗮𝗰𝘁𝗶𝗰𝗲𝘀: • split at route level • avoid over-splitting • use meaningful fallbacks • monitor bundle size Loading everything at once works — but splitting wisely improves performance significantly. 💬 Curious — do you apply code splitting at route level or component level? #ReactJS #CodeSplitting #Performance #FrontendDevelopment #JavaScript #WebDevelopment #SoftwareEngineering #Optimization