What Building Pagelyze Taught Me About React Best Practices

Prazin Karki — Fri, 26 Jun 2026 11:37:58 +0000

What building Pagelyze taught me about React best practices - and why it has very little to do with hooks.

Building Pagelyze has made me think more carefully about React best practices, not as theory, but as product architecture.

I already work across Vue, Nuxt, Laravel, CMS platforms, and analytics. But React is a skill I want to sharpen properly, especially while building my own product, Pagelyze (a website audit and lead-check tool), under PKTechie.

Pagelyze isn't a toy app with a few components. It has real product concerns: audit reports, scoring logic, lead-flow evidence, dashboards, and paid-conversion paths. So while relearning React, I kept asking one practical question:

Can the code stay clean while the product gets more useful?

Good React isn't just about hooks

useState, useEffect, useMemo, custom hooks - important, but not the full story. A React app can use modern syntax everywhere and still be miserable to maintain. The real issue is rarely syntax. It's whether each piece of code has a clear responsibility.

Component responsibility matters early

In Pagelyze, an audit report screen could easily turn into one giant file handling everything from loading data to deciding which service to recommend. It would work for a while - it wouldn't scale.

A cleaner split:

<AuditSummary />
<LeadCheckPanel />
<EvidenceList />
<ServiceRecommendationCard />
<ReportActions />

Each component has one clear reason to exist - so I can improve Lead Rescue without touching SEO scoring, or redesign a card without rewriting data logic.

State should live where it makes sense

The better question isn't "Redux or Context?" - it's who actually needs this state?

Local UI state:    tabs, toggles, modals, expanded panels
Form state:        audit URL, validation, submission status
Server state:      audit reports, scans, saved results
Global state:      user, organisation, plan, permissions

Hooks should extract meaning, not hide mess

A custom hook should represent a meaningful piece of behaviour, not just relocate messy code:

const { report, isLoading, error } = useAuditReport(reportId)

function AuditReportPage({ reportId }: { reportId: string }) {
  const { report, isLoading, error } = useAuditReport(reportId)

  if (isLoading) return <ReportLoadingState />
  if (error) return <ReportErrorState />

  return (
    <ReportLayout>
      <AuditSummary report={report} />
      <LeadCheckPanel leadCheck={report.leadCheck} />
      <RecommendedFixes report={report} />
    </ReportLayout>
  )
}

The page only coordinates the screen - that's enough.

Structure the project around the product, not the framework

features/
  audit-report/
    components/
    hooks/
    types.ts
  lead-rescue/
    components/
    evidence/
    manual-proof/
  dashboard/
    components/
    hooks/

Routing is part of conversion

For Pagelyze, routing is not just URLs. It is the user journey from the first landing page visit to a clear service enquiry:

Landing page
  ↓
Free audit
  ↓
Report result
  ↓
Lead-check explanation
  ↓
Recommended fix
  ↓
Service enquiry

Good routing guides them to the next step.

Measure performance - don't guess it

Build clearly. Measure honestly. Find the actual bottleneck. Optimise that specific thing.

Security is front-end work too

The rule I keep coming back to: don't expose anything in the browser that shouldn't be public.

The takeaway

React best practices are really about decision-making - what each component owns, where state lives, whether a route helps the user move forward, and whether the app is safe and fast in real use.

Pagelyze is my real test: not whether I can build a screen, but whether I can keep the product clean and maintainable as it gets more serious.

Originally published on PKTechie.

DEV Community: Prazin Karki