What Building Pagelyze Taught Me About React
Building Pagelyze changed my view on React. I stopped looking at theory and started looking at product architecture.
Pagelyze is a website audit tool. It is not a small practice app. It handles audit reports, scoring logic, and dashboards. Because of this, I had to answer one question:
Will this code stay clean as the product grows?
Hooks like useState or useEffect are important. But they are not the whole story. You can use modern syntax and still have a mess to maintain. The problem is usually responsibility.
In a bad setup, one file handles everything from loading data to showing results. This fails as you scale.
A better way is to split components by purpose:
- AuditSummary
- LeadCheckPanel
- EvidenceList
- ServiceRecommendationCard
- ReportActions
Each piece has one job. You can change a card design without breaking your data logic.
Stop asking if you should use Redux or Context. Ask who needs the state.
- Local UI state: tabs and modals
- Form state: URLs and validation
- Server state: reports and scans
- Global state: user profile and permissions
Custom hooks should represent behavior. They should not just move messy code to a different file. A good hook fetches data so the page component only coordinates the screen.
Structure your folders by feature:
- features/audit-report/
- features/lead-rescue/
- features/dashboard/
Routing is more than just URLs. It is the user journey. A user goes from a landing page to a free audit, then to a report, and finally to a service inquiry. Good routing guides them to the next step.
Build with clarity. Find the bottleneck. Fix that specific part.
React best practices are about decisions. You decide what a component owns. You decide where state lives. You decide if a route helps the user.
Pagelyze is my test. I am not testing if I can build a screen. I am testing if I can keep a product clean as it grows.
Source: https://dev.to/prazink/what-building-pagelyze-taught-me-about-react-best-practices-5fhb
