tRPC boosts productivity with end-to-end type safety for full-stack projects

Async JavaScript — what actually matters beyond the basics. 🚀 📌 Promises have 3 states — and they're irreversible. Once settled, a Promise can never go back to pending. That's by design. 📌 .catch covers the entire chain above it. Any error thrown anywhere flows down automatically. Not just the last step. The whole chain. 📌 fetch doesn't throw on 404 or 500. It only throws on network failure. Always check res.ok explicitly — try/catch alone won't save you here. 📌 Four combinators. Four different jobs. ✅ Promise.all → all required, fail fast ✅ Promise.allSettled → independent optionals, handle each separately ✅ Promise.race → timeout enforcement ✅ Promise.any → multiple sources, first success wins 📌 Sequential awaits are a hidden performance trap. If two calls don't depend on each other — they should run in parallel. Every unnecessary sequential await is wasted time. 📌 Retrying immediately under failure makes things worse. All instances retrying at the same moment hammer a struggling API further. Exponential backoff + jitter staggers retries — giving the API room to recover. Small decisions in async code have large consequences at scale. 💡 #JavaScript #AsyncJS #WebPerformance #FrontendEngineering #PlatformEngineering

#One_real_production_lesson_frontend_dev_taught_me: We had a bug in production where an API was getting called twice. At first, it looked like a backend issue. But the backend logs were clean. So I started digging into the frontend 👇 The culprit? 👉 React 18 Strict Mode. In development, React intentionally runs components twice to detect side effects. But our code wasn’t written with that in mind. Here’s what we had: ❌ API call inside "useEffect" without proper safeguards ❌ No cleanup / idempotent logic ❌ Assumption: "useEffect runs only once" Result: Duplicate API calls → inconsistent data → confused users. --- ✅ Fix: - Made API calls idempotent - Added proper checks before firing requests - Avoided unnecessary side effects inside "useEffect" --- 💡 Lesson: Writing code that works is easy. Writing code that works in real-world scenarios is the real skill. React doesn’t cause bugs. Our assumptions do. --- Since then, I always ask: 👉 “What happens if this runs twice?” 👉 “Is this safe in concurrent rendering?” --- Still learning something new every day 🚀 #FrontendDevelopment #ReactJS #JavaScript #CleanCode #WebDevelopment #Debugging

💡 JavaScript Tip: Stop writing defensive code the hard way. Before optional chaining (?.), we used to write: const city = user && user.address && user.address.city; Now, it's as clean as: const city = user?.address?.city; If any part of the chain is null or undefined, it simply returns undefined — no errors, no verbose conditions. This is especially powerful when working with API responses where nested data isn't always guaranteed. Small syntax. Big impact on readability and reliability. ♻️ Repost if this helped someone on your network. #JavaScript #WebDevelopment #CleanCode #Frontend #CodingTips

Stop disabling the exhaustive-deps linter in your React Effects ⚛️. we all did the same dirty hack: // eslint-disable-next-line 👇. It is the most common frustrating scenario in React development: You write a useEffect to connect to a websocket or track an analytics event. Inside that effect, you need to read the current value of a state variable—like a shopping cart count or a UI theme. But the moment you read that state, the React linter screams at you to add it to the dependency array. If you add it, your effect re-runs every time the state changes (destroying your websocket connection!). If you don't add it, your build fails. So, we all did the same dirty hack: // eslint-disable-next-line. React finally solves this permanently with useEffectEvent. ❌ The Legacy Way (eslint-disable): Forces you to break the rules of React. Creates a massive risk for stale closures and hidden bugs. Makes your code harder to maintain and review. ✅ The Modern Way (useEffectEvent): Extracts your "event" logic cleanly out of your "lifecycle" logic! • Always Fresh: It guarantees your callback will always read the absolute latest props and state. • Non-Reactive: It is intentionally ignored by the dependency array. It will never cause your useEffect to re-run. • Clean Code: You can finally turn your linter rules back on and trust your dependencies again. The Shift: We are moving away from fighting the framework and using dedicated primitives to separate reactive synchronization from non-reactive events. #ReactJS #React19 #WebDevelopment #Frontend #JavaScript #CleanCode #SoftwareEngineering #TechTips #WebDev #WebPerf #Tips #DevTips #ReactTips #FrontendDeveloper #DeveloperTips

I thought learning more frameworks would make me a better developer. It didn’t — understanding the basics did. Day 17 of rebuilding my frontend foundations from Talha Tariq Stepping back to HTML and CSS helped me see what I was missing: • Faster debugging (I understand the “why”) • More predictable layouts • Cleaner, simpler code Frameworks are powerful — but without fundamentals, they hide gaps instead of fixing them. If you’re feeling stuck, try going back to basics. It pays off faster than you think. Are you building on strong fundamentals or just tools? 👇 #frontend #webdevelopment #buildinpublic #html #css

Introducing SuperForm – A TypeScript-First Form Validation Library for React I am excited to announce the initial public release of SuperForm, a lightweight, TypeScript-first validation and form state management library for React. SuperForm is designed to make form handling fast, intuitive, and fully typed. Key Features: - TypeScript-First: Full type inference from your schemas, no manual types required. - Zod-Like Syntax: Intuitive, chainable schema builder. - Comprehensive Validation: Strings, numbers, booleans, objects, and arrays. - Async Validation: Built-in support for async rules (e.g., checking if a username is taken). - React Integration: Lightweight hooks (useForm, useField) for effortless form state management. - Zero Dependencies: Optimized for performance. Installation: - npm install @silentcoderhi/superform - or - yarn add @silentcoderhi/superform Try it out: Define schemas, validate forms, and manage state effortlessly in React projects. This library is open-source and contributions are welcome! Check it out on npm: https://lnkd.in/dxPkZtxN #React #TypeScript #OpenSource #WebDevelopment #npm #FormValidation #SuperForm #Frontend #JavaScript

🚀 𝗨𝗻𝗱𝗲𝗿𝘀𝘁𝗮𝗻𝗱𝗶𝗻𝗴 𝗝𝗮𝘃𝗮𝗦𝗰𝗿𝗶𝗽𝘁 𝗖𝗹𝗼𝘀𝘂𝗿𝗲𝘀 (The Secret Locker Story 😂) Ever felt like JavaScript remembers things even after they’re gone? 👀 Well… it actually does 😎 Let me explain 𝗖𝗹𝗼𝘀𝘂𝗿𝗲𝘀 in the simplest (and funniest) way 👇 🔐 1. Create a Locker with a Secret /* JavaScript * / function createLocker() { let secret = "💰 1 Crore Password"; return function() { console.log(secret); }; } JS be like: “Okay… I’ll keep this secret safe 🤫” 🎁 𝗧𝗮𝗸𝗲 𝘁𝗵𝗲 𝗟𝗼𝗰𝗸𝗲𝗿 𝗞𝗲𝘆 /* JavaScript * / const myLocker = createLocker(); Now the outer function is gone… finished… bye bye 👋 😳 𝗦𝗲𝗰𝗿𝗲𝘁 𝗔𝗯𝗵𝗶 𝗕𝗵𝗶 𝗟𝗶𝘃𝗲 𝗛𝗮𝗶 /* JavaScript * / myLocker(); // 💰 1 Crore Password JS says: “Function gaya toh kya hua… memory toh mere paas hai 😎” 🧠 𝗪𝗵𝗮𝘁 𝗷𝘂𝘀𝘁 𝗵𝗮𝗽𝗽𝗲𝗻𝗲𝗱? 👉 Inner function remembers outer function’s variables 👉 Even after outer function is finished 👉 This is called a Closure 😂 𝗥𝗲𝗮𝗹-𝗟𝗶𝗳𝗲 𝗔𝗻𝗮𝗹𝗼𝗴𝘆 It’s like: 👩 Mom hides sweets in a locker 🍫 🔑 Gives you the key 🏠 Leaves the house And you’re like: “अब तो मज़े ही मज़े 😎” ⚠️ 𝗜𝗺𝗽𝗼𝗿𝘁𝗮𝗻𝘁 𝗣𝗼𝗶𝗻𝘁 /* JavaScript * / const locker1 = createLocker(); const locker2 = createLocker(); 👉 Both lockers have their own secret (No sharing bro ❌😆) 💼 𝗜𝗻𝘁𝗲𝗿𝘃𝗶𝗲𝘄 𝗢𝗻𝗲-𝗟𝗶𝗻𝗲𝗿 Closure = A function that remembers variables from its outer scope even after the outer function has executed. 🔥 𝗡𝗼𝘄 𝘆𝗼𝘂𝗿 𝘁𝘂𝗿𝗻! Can you think of real use cases of closures? Drop in comments 👇👇 #JavaScript #WebDevelopment #Frontend #Coding #Programming #Developers #LearnToCode #Tech #SoftwareEngineering #ReactJS #100DaysOfCode #CodingLife

Why do we specifically pass 'props' into 'super(props)' in a React component constructor? It is one of those things many developers do out of habit without realizing the actual mechanism behind it. While calling 'super()' is a JavaScript requirement to initialize the 'this' keyword, passing 'props' is a very specific React requirement for the constructor phase. The reason is simple: visibility. When you call 'super(props)', you are telling the parent 'React.Component' class to initialize 'this.props' for you immediately. If you only call 'super()' without the argument, 'this.props' will be undefined inside the constructor. React eventually assigns props to the instance anyway, but that happens after the constructor has finished running. If your logic requires you to access a property or compute a state based on a prop right inside the constructor, forgetting the 'props' argument will crash your logic. You would be trying to read from a variable that hasn't been wired up to the instance yet. Even though modern React code bases have shifted to Functional Components where this ceremony is gone, the underlying logic of when data becomes available to an instance is a core part of the library’s history. It is a small detail that perfectly illustrates how React works under the hood. #ReactJS #Javascript #SoftwareEngineering #FrontendDevelopment #WebDev #CodingTips

Interesting comparison between HTMX and React while implementing the same feature 👀 The article shows how a relatively simple UI feature took 3 days in React but only 3 hours using HTMX ⏱️ It’s a good reminder that technology choices can significantly affect complexity and development time. Sometimes a simpler approach can solve the problem more efficiently than adding additional abstraction layers. It also raises interesting questions about when complexity is actually necessary in system design. Curious to see how approaches like HTMX evolve alongside traditional frontend frameworks. 💡 Always interesting to see how different tools approach the same problem. #webdevelopment #softwareengineering #javascript #frontend #backend https://lnkd.in/ecpfhWgW