Code and file structure in frontend

🏆 How GreatFrontEnd's code base is structured 🏆 Some practices we use on a semi-large code base like greatfrontend.com → Typesafety: We use TypeScript. Code with types eliminate an entire class of bugs and is easier to read and maintain → Linting and formatting: We use Prettier and ESLint with a set of opinionated lint rules. Our lint rules enforce import order, object keys order, enable fix + format on save in IDE → Monorepo: We use Turborepo with a few packages – app, questions, guidebooks, lint rules, etc. → Package management: We use pnpm, which is a great package manager → UI components: A11y is hard, so we use headless components (Radix UI) that come with built-in behavior and a11y and customize styling. Alternatives include Headless UI, Ark UI and Base UI → Routing: Next.js is our choice of meta frameworks. The `/app` directory is for routing only. All UI code and data fetching code are in separate directories. That way we can move/rename routes easily without affecting downstream files → Data fetching: We use tRPC as a typesafe data fetching approach → Statically generated atomic CSS: The easiest way to have a scalable CSS file size in large code bases. Use libraries like Tailwind and StyleX → Z-index list: Z-index wars is the most commonly fought war in front end development. We defined a list of z-indices and use them for global-level elements like dialogs, popovers, tooltips, etc. This is a tricky topic so I might go deeper into it another day. → Content: All content lives in the repository and not in an external CMS. That way we can ensure the same content across development, staging, and production environments. → Util libs: We standardized on utility libraries like Lodash, date-fns, hooks (usehooks-ts) → Separate product code vs common code: We have clear separation of common code vs product-specific code. Design system components should not embed business logic. → Presentation vs Business: Split components according to presentational vs business logic (frequently called small vs dumb but I don't like the word "dumb). That way it's easier to test them → File organization: Modularize and co-locate code by products/features/verticals. All code related to auth, marketing, purchases, blog, etc. are in their own directories → State management: For most apps, most state is server-fetched data, which Tanstack Query does an excellent job in managing. For local state, reach for context before using 3rd party libs like Redux, Zustand, Jotai → Performance: Optimize when you encounter perf problems. No need for useMemo, useCallback yet. The React compiler will help with this in future anyway #react #nextjs #tailwindcss #javascript #typescript #supabase #prisma #eslint

🚀 React Folder Structure for Real-World Projects ⚛️📂 When you're building a serious React app (not just a side project), your folder structure matters more than you think. A clean, scalable structure boosts teamwork, speeds up onboarding, and keeps your codebase maintainable as your app grows. ✅ Why This Structure Works Scalable for large apps & teams Easy to navigate and manage Keeps logic, UI, and data organized Ideal for long-term projects 📁 Recommended Folder Structure 🔹 components/ – Reusable UI parts like buttons, headers, modals, layouts (MainLayout, AuthLayout, etc.) 🔹 features/ – Feature-based folders with their own logic, components, and state (auth/, products/, users/) 🔹 hooks/ – Custom React hooks (e.g., useAuth, useDebounce, useToggle) shared across the app 🔹 routes/ – All route configurations and protected route logic 🔹 services/ – API calls, Axios instances, interceptors, and service functions 🔹 store/ – Global state (Redux, Zustand, Context), slices, and configuration 🔹 utils/ – Helper functions, formatters, validators, and constants 🔹 styles/ – Global styling like SCSS variables, Tailwind configs, or theme settings 🔹 assets/ – Static files: images, icons, fonts, logos 🔹 pages/ – Top-level pages like Home.jsx, Login.jsx, Dashboard.jsx 🔹 tests/ – All test files, organized by type (unit, integration, component) 🔧 Benefits at a Glance ✅ Easy for new developers to onboard ✅ Reduces bugs by keeping logic isolated ✅ Makes collaboration smoother ✅ Keeps your code clean and DRY ✅ Scales with your app — not against it #ReactJS #WebDevelopment #FrontendDeveloper #ReactDeveloper #JavaScript #CodeStructure #CleanCode #DeveloperTips #FullStackDevelopment #ScalableArchitecture #ReactProjects #CodingBestPractices #TechTips #SoftwareEngineering

🚀 A Scalable Frontend Folder Structure That Actually Makes Sense Let’s be real—nothing beats opening a project and instantly knowing where everything is. Clean structure = clear mind = smooth dev flow. So here’s how I like to organize my React projects to keep them scalable, maintainable, and... actually fun to work in: 📂 Frontend Folder Breakdown 🔹 public/ – Static files like favicon, robots.txt, or preview images. 🔹 src/ – The heart of the app: assets/ → logos, icons, fonts – your visual toolbox. components/ → broken down into atoms, molecules, organisms for truly reusable UI. layouts/ → reusable page wrappers like MainLayout or DashboardLayout. pages/ → route-based pages (index.tsx, login.tsx, etc.). hooks/ → custom logic in one place (e.g. useAuth, useForm). services/ → centralized API calls (auth.service.ts, product.service.ts). context/ → global state with Context API or Zustand. utils/ → helpers like formatDate or debounce. constants/ → app-wide values (routes, config, enums). styles/ → global styles (Tailwind, SCSS, etc.). 🧠 Main files App.tsx → root component main.tsx → renders the app vite.config.ts / next.config.js → project config .env, .prettierrc, .eslintrc → keeping it clean & consistent ✨ Why it works: Easy to scale New features? Plug and play Keeps logic + UI separate Every dev instantly knows where to go This structure has saved me so many headaches, especially when projects grow fast. It’s clean, clear, and built to last. 💬 Curious how others do it too—How do you structure your frontend projects? Share below or drop your best tips! #FrontendDev #ReactJS #CleanCode #WebDevelopment #DeveloperTips #CodingBestPractices #ScalableArchitecture #TechLife #TypeScript #Vite #NextJS

The Art of Structured Code: Next.js Application Architecture Excited to share this comprehensive file architecture blueprint for building robust web applications with Next.js, TypeScript, and Tailwind CSS! This structure implements industry best practices for: ✅ Clean separation of concerns ✅ Feature-based organization ✅ Type-safe development ✅ Scalable component design ✅ Modern routing patterns For example, in an eCommerce context, this architecture elegantly handles: • Product catalog organization • User authentication flows • Shopping cart state management • Checkout & payment processing • Order history tracking Whether you're building a digital storefront, SaaS platform, or content-rich application, starting with a well-organized structure saves countless hours and prevents technical debt. What file structure patterns have worked best in your projects? Let's connect and share insights! #nextjs #typescript #tailwindCSS #webdevelopment #softwarearchitecture #codequality #reactJS #frontenddevelopment #webapp #developerproductivity #cleancode #techbestpractices

Here’s how to clean up messy frontend and backend code—for good: ☑ Frontend Refactoring (React, Vue, Svelte) 1. Modularize the UI → Break large components into smaller, reusable ones → Use component libraries (like Storybook) to enforce consistency 2. Tame the State Monster → Ditch prop drilling for Context, Zustand, or Vuex → Clean up unused state and only lift when necessary 3. Prevent Useless Renders → Use memo, useMemo, useCallback, or Vue’s computed → Code-split and lazy load for faster UX 4. Modernize Your Styles → Try Tailwind, CSS-in-JS, or scoped styles in Vue → Remove dead CSS and centralize theme tokens 5. Lint It or Regret It → Add ESLint, Prettier, and TypeScript for sanity → Automate formatting in CI 6. Shrink Your Bundle → Enable tree shaking, dynamic imports, and minification → Tools like Vite, Webpack, or esbuild make it easy — ☑ Backend Refactoring (Node, Express, Nest, Django, Rails) 1. Modular by Design → Use MVC or Hexagonal to separate concerns → Prefer grouping by feature, not layers 2. Service Layer FTW → Keep business logic out of controllers → Easier to test, scale, and maintain 3. Database Speed Boost → Add indexes, cache smartly (Redis), and avoid N+1 queries → Normalize or denormalize based on query patterns 4. Make Your APIs a Joy to Use → Use pagination, filtering, and proper HTTP status codes → REST is great—but consider GraphQL for flexibility 5. Go Async or Go Home → Offload heavy work to queues (Bull, Sidekiq, Celery) → Use async/await where I/O blocking hurts 6. Test. Then Test Again. → Split large functions into testable units → Write unit + integration tests and run them on every commit — Cross-Cutting Musts → Atomic commits with clear messages → API docs with Swagger or JSDoc → Automate tests and linting with CI/CD — Refactoring isn’t just technical debt cleanup—it’s developer self-respect. If this helped, repost to help clean up someone else’s codebase too. Or DM me if you want to apply these to your stack.