// A simple React component — the same way
// a BA would describe a "card" in a story.

function CourseCard({ title, price, onEnrol }) {
  return (
    <div className="card">
      <h3>{title}</h3>
      <p>₹{price}</p>
      <button onClick={onEnrol}>Enrol now</button>
    </div>
  );
}

// As a BA, this single component tells you:
// - Title and price are inputs (props)
// - The button triggers an action (event)
// - Layout is a single card
//
// Your story for this feature should answer:
// - What if title is very long?
// - What if price is 0 (free course)?
// - What happens when onEnrol is clicked?
// - Is the button disabled while enrolling?

// The three states every BA should ask about

function CourseList() {
  const [courses, setCourses] = React.useState(null);
  const [error, setError]   = React.useState(null);

  // 1. Loading state
  if (courses === null && !error) {
    return <p>Loading courses...</p>;
  }

  // 2. Error state
  if (error) {
    return <p>Could not load courses. Please try again.</p>;
  }

  // 3. Empty state
  if (courses.length === 0) {
    return <p>No courses available yet.</p>;
  }

  // 4. Success state
  return courses.map((c) => (
    <CourseCard key={c.id} title={c.title} price={c.price} />
  ));
}

// This is the single biggest BA lesson from React:
// every data-driven screen has at least 4 states.
// Stories that only describe the success state
// cause the most rework in delivery.

// A component tree — the shape every BA should sketch
// before writing a story.

<App>
  ├── <Header />
  │     ├── <Logo />
  │     └── <UserMenu />
  ├── <CoursesPage />
  │     ├── <Filters />
  │     ├── <CourseList />
  │     │     └── <CourseCard /> × N
  │     └── <Pagination />
  └── <Footer />

// As a BA, sketching this tree BEFORE the story
// gives you:
// 1. A natural way to break stories (one per component)
// 2. A clear mental model of what "reusable" means
// 3. A shared language with the frontend developer
// 4. A sanity check on scope — is this really one story?

// A BA prototype — a form that shows
// the exact business rules in a clickable demo.

function RefundForm() {
  const [amount, setAmount] = React.useState("");
  const [reason, setReason] = React.useState("");

  const isAmountValid =
    Number(amount) > 0 && Number(amount) <= 5000;
  const isReasonValid = reason.length >= 10;

  return (
    <form>
      <label>
        Refund amount (max ₹5,000)
        <input
          value={amount}
          onChange={(e) => setAmount(e.target.value)}
        />
      </label>
      {!isAmountValid && amount && (
        <p className="error">
          Refunds above ₹5,000 need manager approval.
        </p>
      )}

      <label>
        Reason (min 10 characters)
        <textarea
          value={reason}
          onChange={(e) => setReason(e.target.value)}
        />
      </label>

      <button disabled={!isAmountValid || !isReasonValid}>
        Submit refund
      </button>
    </form>
  );
}

// In a review meeting, this does more than
// any "please share the business rules" doc:
// stakeholders TEST the rules themselves.
// Arguments about "edge cases" disappear.

// A BA prototype — shows a discount rule in action.

function PriceSummary() {
  const [qty, setQty] = React.useState(1);
  const [isMember, setIsMember] = React.useState(false);

  const unitPrice = 499;
  const subtotal  = qty * unitPrice;

  // Business rule 1 — bulk discount
  const bulkRate =
    qty >= 10 ? 0.15 :
    qty >= 5  ? 0.10 : 0;

  // Business rule 2 — member discount
  const memberRate = isMember ? 0.05 : 0;

  // Business rule 3 — max discount cap
  const discountPct = Math.min(bulkRate + memberRate, 0.20);
  const discount    = subtotal * discountPct;
  const total       = subtotal - discount;

  return (
    <div>
      <label>
        Qty:
        <input
          type="number"
          value={qty}
          onChange={(e) => setQty(Number(e.target.value))}
        />
      </label>
      <label>
        <input
          type="checkbox"
          checked={isMember}
          onChange={(e) => setIsMember(e.target.checked)}
        />
        Member
      </label>

      <p>Subtotal: ₹{subtotal}</p>
      <p>Discount ({(discountPct * 100).toFixed(0)}%): -₹{discount}</p>
      <p><strong>Total: ₹{total}</strong></p>
    </div>
  );
}

// Now the "is 20% cap before or after member discount?"
// debate happens in the prototype, not in a 40-message email thread.

Project 1 — Feature prototype + spec
(a single portfolio piece that shows everything)

1. Pick a feature you've worked on (or a common one)
2. Build a small React prototype that:
   - Handles all four states (loading, error, empty, success)
   - Includes one business rule with edge cases
3. Write the user story + acceptance criteria
   that match the prototype exactly
4. Deploy it to Vercel
5. Record a 2-minute walkthrough

What a hiring manager sees:
- You understand frontend behaviour
- You write stories that map to real code
- You can prototype, not just document
- You collaborate better with engineering

Project 2 — Before/after comparison
(shows business impact, not just UI)

1. Choose a real product flow (checkout, onboarding,
   or a discount rule)
2. Build the "as-is" React version
3. Build the "to-be" React version (your improvement)
4. Add a note for each change explaining:
   - Which user problem it solves
   - Which business rule is being fixed
   - What the engineering effort would be

What a hiring manager sees:
- You can quantify impact, not just describe it
- You understand engineering trade-offs
- You can defend a design decision in a review