MVC vs Component Architecture

Small app (5 files):
  Everything in one place. No architecture needed.

Medium app (50 files):
  Need some structure. Where does the API call go?
  Where does the form validation live? Where is state managed?

Large app (500+ files):
  Architecture is critical.
  ├── Can a developer find the code for a feature?
  ├── Can they change it without breaking other features?
  ├── Can two teams work on different features simultaneously?
  └── Can components be reused across the app?

Two approaches to solve this:

  MVC: Organize by ROLE              Component: Organize by FEATURE
  ├── models/                        ├── SearchBar/
  │   ├── user.js                    │   ├── SearchBar.tsx
  │   ├── product.js                 │   ├── useSearch.ts
  │   └── cart.js                    │   └── SearchBar.css
  ├── views/                         ├── ProductCard/
  │   ├── userView.js                │   ├── ProductCard.tsx
  │   ├── productView.js             │   ├── useProduct.ts
  │   └── cartView.js                │   └── ProductCard.css
  └── controllers/                   └── Cart/
      ├── userController.js              ├── Cart.tsx
      ├── productController.js           ├── useCart.ts
      └── cartController.js              └── Cart.css

┌──────────────────────────────────────────────────┐
│                    MVC Pattern                   │
├──────────────────────────────────────────────────┤
│                                                  │
│   ┌────────────┐    ┌──────────────┐             │
│   │   MODEL    │    │     VIEW     │             │
│   │            │    │              │             │
│   │ • Data     │◄───│ • UI/HTML    │             │
│   │ • State    │    │ • Templates  │             │
│   │ • Business │    │ • Rendering  │             │
│   │   logic    │───►│ • Display    │             │
│   └─────▲──────┘    └──────▲───────┘             │
│         │                  │                     │
│         │   ┌──────────────┴──────┐              │
│         │   │    CONTROLLER       │              │
│         └───│                     │              │
│             │ • Handles user input│              │
│             │ • Updates model     │              │
│             │ • Selects view      │              │
│             │ • Orchestrates flow │              │
│             └─────────────────────┘              │
│                                                  │
└──────────────────────────────────────────────────┘

Model:  The data layer. Manages state, business rules,
        and data validation. Knows nothing about the UI.

View:   The presentation layer. Renders data to the screen.
        Knows nothing about business logic.

Controller: The glue. Receives user input, calls the model
            to update data, and tells the view to re-render.

// ── MODEL ─────────────────────────────────────
// Manages data and business logic
class TodoModel {
  constructor() {
    this.todos = [];
    this.listeners = [];
  }

  addTodo(text) {
    this.todos.push({ id: Date.now(), text, done: false });
    this.notify(); // Tell listeners (views) that data changed
  }

  toggleTodo(id) {
    const todo = this.todos.find(t => t.id === id);
    if (todo) todo.done = !todo.done;
    this.notify();
  }

  notify() {
    this.listeners.forEach(fn => fn(this.todos));
  }
}

// ── VIEW ──────────────────────────────────────
// Renders UI, knows nothing about business logic
class TodoView {
  constructor(container) {
    this.container = container;
  }

  render(todos) {
    this.container.innerHTML = todos
      .map(t => `<li class="${t.done ? 'done' : ''}">${t.text}</li>`)
      .join("");
  }

  onItemClick(handler) {
    this.container.addEventListener("click", e => {
      handler(e.target.dataset.id);
    });
  }
}

// ── CONTROLLER ────────────────────────────────
// Connects model and view, handles user actions
class TodoController {
  constructor(model, view) {
    this.model = model;
    this.view = view;

    // Model changes → update view
    this.model.listeners.push(todos => this.view.render(todos));

    // User clicks → update model
    this.view.onItemClick(id => this.model.toggleTodo(id));
  }

  addTodo(text) {
    this.model.addTodo(text);
  }
}

Classical MVC Flow:

  User Action ──► Controller ──► Model ──► View ──► User Sees Update
       │                                     │
       └─────────────────────────────────────┘
                    (cycle repeats)

Frontend MVC Reality (the messy version):

  ┌──────────┐     ┌──────────────┐     ┌──────────┐
  │  View 1  │────►│  Controller  │────►│  Model A │
  │  View 2  │────►│  Controller  │────►│  Model B │
  │  View 3  │◄────│  Controller  │◄────│  Model A │
  └──────────┘     └──────────────┘     └──────────┘
       │                  │                    │
       │    Views can listen to multiple models│
       │    Controllers can update multiple    │
       │    models and views                   │
       └───────────────────────────────────────┘

  In complex UIs, the clean one-way flow breaks down.
  Multiple views depend on multiple models.
  Controllers become "god objects" that know everything.
  This is why Facebook moved away from MVC to Flux → Redux → React.

Problem 1: Bidirectional Data Flow
──────────────────────────────────
  Model A changes → View 1 updates → triggers Controller
  → updates Model B → View 2 updates → triggers Controller
  → updates Model A again → infinite loop? race condition?

  In complex UIs, cascading updates are hard to trace and debug.

Problem 2: Controller Bloat
──────────────────────────────────
  // A "god controller" that knows too much:
  class DashboardController {
    handleSearch() { ... }
    handleFilter() { ... }
    handleSort() { ... }
    handlePagination() { ... }
    handleUserProfile() { ... }
    handleNotifications() { ... }
    handleSettings() { ... }
    // 500+ lines of orchestration logic
  }

Problem 3: Scattered Feature Code
──────────────────────────────────
  To understand the "search" feature, you must read:
    models/searchModel.js        (data)
    views/searchView.js          (UI)
    controllers/searchCtrl.js    (logic)
    templates/search.html        (markup)
    styles/search.css            (styling)

  5 files in 5 different directories for one feature.

Problem 4: Difficult Reuse
──────────────────────────────────
  Want to reuse a "date picker" in another project?
  You need: the view, its model, its controller, its template,
  its styles, and all their dependencies.
  Components solve this — one import, everything included.

┌─────────────────────────────────────────────────┐
│              Component Architecture             │
├─────────────────────────────────────────────────┤
│                                                 │
│   ┌─────────────────────────────────────────┐   │
│   │                  App                    │   │
│   │  ┌──────────┐  ┌────────────────────┐   │   │
│   │  │  Header  │  │     Dashboard      │   │   │
│   │  │ ┌──────┐ │  │  ┌──────┐ ┌─────┐  │   │   │
│   │  │ │ Logo │ │  │  │Search│ │Stats│  │   │   │
│   │  │ │ Nav  │ │  │  │Bar   │ │Card │  │   │   │
│   │  │ └──────┘ │  │  └──────┘ └─────┘  │   │   │
│   │  └──────────┘  │  ┌──────────────┐  │   │   │
│   │                │  │  TodoList    │  │   │   │
│   │                │  │ ┌──────────┐ │  │   │   │
│   │                │  │ │ TodoItem │ │  │   │   │
│   │                │  │ │ TodoItem │ │  │   │   │
│   │                │  │ │ TodoItem │ │  │   │   │
│   │                │  │ └──────────┘ │  │   │   │
│   │                │  └──────────────┘  │   │   │
│   │                └────────────────────┘   │   │
│   └─────────────────────────────────────────┘   │
│                                                 │
│  Each box is a COMPONENT that owns:             │
│  • Its own markup (JSX/template)                │
│  • Its own logic (event handlers, hooks)        │
│  • Its own state (useState, local data)         │
│  • Its own styles (CSS modules, styled-comp)    │
└─────────────────────────────────────────────────┘

// Everything for TodoItem lives in ONE component
function TodoItem({ todo, onToggle }) {
  return (
    <li
      className={todo.done ? "done" : ""}
      onClick={() => onToggle(todo.id)}
    >
      {todo.text}
    </li>
  );
}

// Parent component manages state and passes props
function TodoList() {
  const [todos, setTodos] = useState([]);

  const addTodo = (text) => {
    setTodos(prev => [...prev, { id: Date.now(), text, done: false }]);
  };

  const toggleTodo = (id) => {
    setTodos(prev =>
      prev.map(t => t.id === id ? { ...t, done: !t.done } : t)
    );
  };

  return (
    <div>
      <TodoInput onAdd={addTodo} />
      <ul>
        {todos.map(todo => (
          <TodoItem key={todo.id} todo={todo} onToggle={toggleTodo} />
        ))}
      </ul>
    </div>
  );
}

// Compare with MVC: no separate model, view, controller files.
// State, logic, and UI live together in the component.
// Reuse TodoItem anywhere — just import and pass props.

Component Data Flow:

  ┌─────────────────────────────────────────┐
  │              App (state)                │
  │                  │                      │
  │          ┌───────┴────────┐             │
  │          ▼                ▼             │
  │    ┌──────────┐    ┌────────────┐       │
  │    │  Header  │    │  Content   │       │
  │    │ (props)  │    │ (props)    │       │
  │    └──────────┘    │            │       │
  │                    │  ┌───────┐ │       │
  │                    │  │ List  │ │       │
  │                    │  │(props)│ │       │
  │                    │  └──┬────┘ │       │
  │                    │     │      │       │
  │                    │  ┌──▼────┐ │       │
  │                    │  │ Item  │ │       │
  │                    │  │(props)│ │       │
  │                    │  └───────┘ │       │
  │                    └────────────┘       │
  └─────────────────────────────────────────┘

  Props flow DOWN ↓ (parent → child)
  Events flow UP ↑ (child → parent via callbacks)
  State changes trigger re-renders DOWN ↓

  vs MVC where data can flow in ANY direction:
  Model ↔ View ↔ Controller ↔ Model (bidirectional, hard to trace)

// Parent owns the state
function SearchPage() {
  const [query, setQuery] = useState("");
  const [results, setResults] = useState([]);

  const handleSearch = async (searchText) => {
    setQuery(searchText);
    const data = await fetchResults(searchText);
    setResults(data);
  };

  return (
    <div>
      {/* Props DOWN: pass callback and current query */}
      <SearchBar query={query} onSearch={handleSearch} />

      {/* Props DOWN: pass results data */}
      <ResultsList results={results} />
    </div>
  );
}

// Child receives props, calls callback UP
function SearchBar({ query, onSearch }) {
  return (
    <input
      value={query}
      onChange={(e) => onSearch(e.target.value)}  // Event UP ↑
      placeholder="Search..."
    />
  );
}

// Child receives props, renders data
function ResultsList({ results }) {
  return (
    <ul>
      {results.map(item => (
        <li key={item.id}>{item.title}</li>
      ))}
    </ul>
  );
}

Feature: User Profile Card (shows name, avatar, edit button)

── MVC Approach ──────────────────────────────────

  models/userModel.js         → fetches user data, stores state
  views/userProfileView.js    → renders HTML template
  controllers/userCtrl.js     → handles edit click, calls model
  templates/userProfile.html  → HTML markup
  styles/userProfile.css      → styling

  5 files across 5 directories. To understand the feature,
  you must read all 5 and understand how they connect.

── Component Approach ────────────────────────────

  components/UserProfile/
    UserProfile.tsx            → markup + logic + state
    UserProfile.module.css     → styling
    useUserData.ts             → data fetching hook (optional)

  2-3 files in ONE directory. Everything for the feature
  is co-located. Import <UserProfile /> anywhere.

Project Structure:
  models/
    dashboardModel.js      → all dashboard data (stats, table rows, filters)
    searchModel.js         → search query, results
    userModel.js           → current user info
  views/
    sidebarView.js         → renders sidebar navigation
    searchBarView.js       → renders search input
    dataTableView.js       → renders table with rows
    statsCardView.js       → renders stat cards
  controllers/
    dashboardController.js → orchestrates EVERYTHING
    searchController.js    → handles search logic

Data Flow:
  User types in search → searchBarView captures input
  → searchController.handleSearch(query)
  → searchModel.setQuery(query)
  → searchModel.fetchResults()
  → searchModel notifies listeners
  → dataTableView.render(searchModel.results)
  → statsCardView.render(dashboardModel.filteredStats)

Problems:
  • dashboardController grows to 400+ lines
  • searchModel change affects dataTableView AND statsCardView
  • Adding a new widget means touching model + view + controller
  • Two developers can't work on search and stats independently

// Project Structure:
//   components/
//     Dashboard/
//       Dashboard.tsx          → layout composition
//     Sidebar/
//       Sidebar.tsx            → self-contained navigation
//     SearchBar/
//       SearchBar.tsx          → search input + logic
//       useSearch.ts           → search data hook
//     DataTable/
//       DataTable.tsx          → table rendering
//       DataTableRow.tsx       → single row component
//     StatsCard/
//       StatsCard.tsx          → individual stat display

function Dashboard() {
  const [searchQuery, setSearchQuery] = useState("");

  return (
    <div className="dashboard">
      <Sidebar />
      <main>
        <SearchBar
          query={searchQuery}
          onSearch={setSearchQuery}
        />
        <div className="grid">
          <StatsCard title="Users" query={searchQuery} />
          <StatsCard title="Revenue" query={searchQuery} />
        </div>
        <DataTable query={searchQuery} />
      </main>
    </div>
  );
}

// Each component is independent:
// • Sidebar team works on Sidebar/ — no conflicts
// • Search team works on SearchBar/ — isolated
// • DataTable can be reused on other pages
// • Adding a new widget = adding a new component
// • No "god controller" — logic is distributed

Is the UI highly interactive (real-time, drag-drop, complex state)?
  │
  ├─ YES → Component Architecture (React, Vue, Angular 2+)
  │        • State is distributed across components
  │        • Unidirectional data flow
  │        • Easy to compose and reuse UI pieces
  │
  └─ NO → Is the server rendering most of the HTML?
          │
          ├─ YES → MVC is natural (Rails, Django, Laravel)
          │        • Controller handles one request at a time
          │        • View is a template rendered on the server
          │        • Model maps to database tables
          │
          └─ NO → Hybrid approach
                  • Server-side MVC for routing and data
                  • Component architecture for interactive UI islands
                  • Example: Rails + React, Django + Vue

Scenario: Fix a bug in the search feature

── MVC ──────────────────────────────────────────
  1. Open controllers/searchController.js — is the bug here?
  2. Open models/searchModel.js — is the data wrong?
  3. Open views/searchView.js — is the rendering wrong?
  4. Open templates/search.html — is the markup wrong?
  5. Check how searchController interacts with dashboardController
  6. Check which other views subscribe to searchModel
  → 6+ files across 4+ directories, complex dependency chain

── Component Architecture ───────────────────────
  1. Open components/SearchBar/SearchBar.tsx
  2. Check state, props, and render output
  3. If data issue → check useSearch.ts hook
  → 1-2 files in 1 directory, isolated from other features

Scenario: Delete the search feature entirely

── MVC ──────────────────────────────────────────
  Delete searchModel, searchView, searchController, search template
  But wait — does dashboardController reference searchModel?
  Does another view subscribe to searchModel events?
  → Risky deletion, requires careful dependency analysis

── Component Architecture ───────────────────────
  Delete the SearchBar/ directory
  Remove <SearchBar /> from the parent component
  → Clean deletion, no hidden dependencies