React .env file security risk: exposing secret keys

I'm excited to share that I've just published my first open-source npm package: `react-hook-warehouse`! It's a lightweight collection of practical, ready-to-use React hooks that solve everyday problems in modern React (and Next.js) apps. Currently includes: useToggle → clean boolean toggling (no more verbose setState callbacks) useClickOutside → perfect for modals, dropdowns, drawers, popovers useExportToCSV → one-click client-side CSV export from array of objects useLocation → simple geolocation access (with loading/error states) useIsMobile → responsive breakpoint detection via media query All hooks are: - Tiny & dependency-free (no extra bloat) - TypeScript-ready - Well-documented with clear examples - Compatible with React 18+ and Next.js App Router (client components) Installation (one line) npm install react-hook-warehouse GitHub repo (with full README + examples):   https://lnkd.in/gPwjswwG npm page:   https://lnkd.in/ggDwnHhY Why I built it I kept running into the same small-but-annoying patterns across projects — toggles, outside clicks, quick CSV exports, mobile detection, etc. Instead of copying the same 15–20 lines of code every time, I decided to bundle them properly, add types, tests, and publish so others can save time too. Would love your feedback!   - Try it in a side project   - Star the repo ⭐   - Let me know which hook you find most useful (or which one is missing) Happy coding, everyone! 💻✨ #React #ReactHooks #JavaScript #TypeScript #OpenSource #npm #Nextjs #WebDevelopment

I’ve used both Redux and Context API in my React projects… and honestly, each has its place. ⚛️ In smaller apps, Context API feels simple and quick. But as things grow, I often switch to Redux for better structure and scalability. That’s something I’ve learned over time: The right choice depends on the project, not the trend. So I’m curious. What’s your go-to for state management? Redux or Context API? #ReactJS #Redux #ContextAPI #FrontendDevelopment #JavaScript

Most React apps have a performance killer hiding in plain sight. It's unnecessary re-renders. Here's how to stop them: 1️⃣ Use React.memo() for pure components   → Skips re-render if props haven't changed 2️⃣ useMemo() for expensive calculations   → Only recalculates when dependencies change 3️⃣ useCallback() for function props   → Prevents child re-renders caused by new function references 4️⃣ Lift state only where needed   → Don't store everything in a top-level component 5️⃣ Use React DevTools Profiler   → Visualize exactly what's re-rendering and why Bonus: The React Compiler (coming to React 19) will handle much of this automatically. But understanding the problem still makes you a better engineer. Save this for your next performance audit. 🔖 #React #ReactJS #JavaScript #WebPerformance #Frontend

👻 The "Ghost Route" Bug in React 19 Spent hours debugging code that wasn't actually broken? If you’re using Vite + React Router v7, you might be chasing ghosts. 🚩 Symptom You update your routes, but the browser keeps rendering the old page. Even worse, components you "deleted" are still updating in the background. No errors, just total chaos. 🕵️ Culprit: HMR Caching When you export a static router object, Vite’s Hot Module Replacement (HMR) caches that instance. The Result: Your components live-reload, but the Router logic stays frozen in time. 🔧 60-Second Fix Stop exporting a static object. Make your router dynamic so it regenerates on every reload. ❌Buggy Way const router = createBrowserRouter([...]); exportdefault router; ✅ Pro Way // Define a function instead of a constant export const AppRouter = () => { const router = createBrowserRouter([...]); return<RouterProvider router={router} />; }; function App() { return<AppRouter />; } 🎯Takeaway When the "impossible" happens, stop looking at your logic and start looking at your tooling. Don't let a stale cache gaslight your development process. #ReactJS #WebDev #Vite #Frontend #JavaScript #CleanCode

I published my first NPM package this week. I'm 3 days into Next.js after years of Laravel, and I already missed one thing more than anything else: php artisan make:model User That one command. Clean. Intentional. Done. So instead of just adapting to the JS ecosystem, I built what I needed — Domain Driver. It's a CLI that scaffolds a full Domain-Driven feature structure in your Next.js app with one command: app/ └── feat-name/   ├── components/    │  ├── server/    │ └── client/   ├── containers/   ├── hooks/   ├── services/   ├── repositories/   ├── schemas/  └── page.tsx Server components, client components, hooks, services, repositories, and Zod schemas — all in the right place from the start. This is just v1. More artisan-style commands are coming. If you're building Next.js apps and you care about structure, give it a try. You can find it here https://lnkd.in/dhqBrusG #NextJS #NPM #OpenSource #DomainDrivenDesign #JavaScript

Today I hit an issue where my React app(served via django) wouldn't even render index.html(entry point for react application) At first, it looked like a frontend problem,then I noticed styles weren't loading either. But the real issue was deeper. Console error "Mark cross-site cookies as Secure to allow setting them in cross-site contexts" Root cause:The browser was blocking authentication cookies due to modern security policies. SameSite = None - Required Secure = True - Required for cross-site cookies Because the cookie was blocked: -User session failed -Backend response broke -Index.html didn't properly render -Static assets(CSS/JS) didn't load Key takeaway: Not all issues are frontend problems.Sometimes its the browser enforcing security at the HTTP layer. This is why understanding fullstack(Browser <-> HTTP <-> Backend) matters #SoftwareEngineering #Debugging #LearnSomethingNew

Next.js 15 is out — and it changes more than you think. ⚡ I've been digging into everything that shipped. Here's what actually matters for your day-to-day development: ① Turbopack is finally stable The Rust-based bundler is now production-ready. Local dev server is up to 5x faster than Webpack. Cold starts? Almost instant. This alone is worth upgrading for. ② Async Request APIs — breaking change alert cookies(), headers(), and route params are now async. You must await them. If you're upgrading an existing app, audit every usage. It's a small change with a big blast radius. ③ Partial Prerendering (PPR) The most exciting architectural feature in years. Static HTML shell renders instantly. Dynamic content streams in behind it. You get the speed of static AND the freshness of dynamic — in one page. ④ next/after — post-response logic Ever wanted to run analytics or cleanup AFTER sending a response? next/after makes this a first-class feature. No more hacks, no more background job workarounds. ⑤ React 19 ships built-in Actions, use(), useOptimistic, and the React Compiler — all supported out of the box. Next.js 15 + React 19 together is the most powerful the stack has ever been. ⑥ Caching is now explicit fetch() responses are no longer cached by default. This was one of the most confusing parts of Next.js 13/14. Now you opt into caching intentionally. Your app does exactly what you tell it to. The theme across all of it? Next.js 15 removes the magic and gives you control. Less surprises. More predictability. Faster iteration. If you haven't upgraded yet — start with a new project. The DX difference is immediately noticeable. 💬 Have you tried Next.js 15 yet? What feature are you most excited about? #NextJS15 #NextJS #React #Frontend #WebDevelopment #JavaScript #Programming #WebDev #SoftwareEngineering #TechTips

Today I explored some important concepts in React that make apps more scalable and dynamic. 🔹 Learned Context API to manage global state 🔹 Worked with React Router DOM for navigation 🔹 Implemented routing using RouterProvider and createBrowserRouter 🔹 Built multiple pages: Home, About, Contact 🔹 Learned how to navigate between pages smoothly 🔹 Extracted dynamic parameters (like id) from URL 🔹 Fetched real data from GitHub API (followers) 🔗 GitHub Profile: https://lnkd.in/gMurynAg 📌 Key takeaway: Understanding routing + global state is a big step toward building real-world React applications. #React #WebDevelopment #JavaScript #Frontend #LearningInPublic #100DaysOfCode

Stop exposing your secrets. How to properly secure .env in React.js A lot of developers still make these mistakes. Here's what you need to know: The #1 thing most people miss: React apps run in the browser. Anything in your .env file prefixed with REACT_APP_ gets bundled into your JavaScript and is publicly visible. Yes anyone can open DevTools and find it. Best practices to follow: 1- Never store secrets in .env for frontend React API keys, database credentials, payment secrets keep these server-side only. 2- Always add .env to .gitignore Commit .env.example (with empty values) and never push real values to GitHub. 3- Use environment variables only for public config Things like your API base URL or feature flags are fine — not your private keys. 4- Move sensitive logic to a backend (Node.js, Express, etc.) Let your backend handle API calls that need secret keys, then expose safe endpoints to your React app. 5- Validate your .env on startup Use a library like zod or envalid to catch missing variables early. 6- Use secrets managers in production AWS Secrets Manager, Vercel env vars, or Doppler are far safer than relying on flat files. #ReactJS #WebDevelopment #JavaScript #Security #Frontend #DevTips #SoftwareEngineering

Here's how I would approach performance debugging in React. When something feels slow, the first thing I would open is the network tab. Because before forming any opinion, I want to see what’s actually being sent to the browser. - How much is loading. - What’s blocking the page. - What’s there that probably shouldn’t be. That’s usually where the obvious stuff shows up. For example, locale files for regions nobody uses. Modules loading upfront for routes the user hasn’t even visited yet etc. Once I have a rough picture, I would run Lighthouse. Not for the score, but to have a baseline I can track. Then comes the bundle analyser. It tells me which packages are heavy. Are there any duplicate packages I can get rid of? What could be lazy loaded but isn’t? If the load looks fine but the app still feels slow, I would open React DevTools Profiler. It can help with checking if any components are re-rendering when it shouldn’t. The order matters more than the tools. Most performance problems I’ve seen aren’t complicated. They’re just unmeasured. #React #Frontend #WebPerformance #JavaScript #TypeScript