Hire React Developers

React earns its place where an interface has to change shape with the data — approval queues, configurators, dashboards that pull in live state. Sazinga Quote drives a formula pricing engine and a 3D preview from the same React front end, and Field runs offline in vans and on shop floors, which is the kind of work that exposes whether someone understands rendering or merely uses it.

Nearly every hard React problem is a state-ownership problem wearing a rendering problem’s clothes. A component re-renders too often, a stale value appears after a save, two tabs disagree about the same record — the fix is almost never memo, and almost always deciding where that piece of state actually lives.

Server state and client state are not the same thing

Data that came from a server has properties client state does not: it can be stale, it can fail to load, it can be refetched, and two components can want it at once. Putting it in the same store as “is this drawer open” is how applications acquire a hand-written cache nobody meant to write.

The practical division we hold to is a query layer for anything the server owns, and a small client store for genuinely local state. In Comply’s portal — React 18 on Vite, twenty lazily loaded route groups behind a single Suspense boundary — memoisation is deliberately concentrated rather than sprinkled: the calendar page, which builds a month grid, chunks it into weeks and groups records by day on every render, carries most of the useMemo in the codebase. Everywhere else it would be noise, and noise in a dependency array is how a stale closure bug gets introduced.

Put list state in the URL, not in a hook

Any screen with filters, sorting and pagination should read them from the query string. It is not a nicety. A list whose state lives only in a hook cannot be linked to a colleague, cannot be restored by the back button, and loses the user’s place every time they open a record and return.

The version worth copying centralises the parameter names and their defaults in one module, plus a predicate that says whether the current query is the default one — so a page that has not been filtered produces a clean URL rather than a query string with nine parameters set to nothing.

The date bug that reaches production in nearly every React application

A bare YYYY-MM-DD string passed to new Date() is parsed as UTC midnight. Rendered with local formatting, it shows as the previous day for every user behind UTC. It survives review because it is correct on the developer’s machine, and it survives testing because the tests run in the same timezone as the developer.

Our fix is unglamorous and it works: parse date-only values at local noon, so no offset in normal use can push the value across a day boundary. A date without a time is not an instant, and the moment you convert it into one you have made a timezone decision on the user’s behalf.

How the build is made to stop things

Type checking is a build gate, not an editor feature. The portal’s build script runs tsc --noEmit before Vite ever starts, so a type error fails the build rather than shipping as a warning nobody saw. noUnusedLocals and noUnusedParameters are on, which sounds pedantic and is in practice how half-finished refactors get caught.

Bundle shape is deliberate too — React, the DOM renderer and the router are pinned into their own vendor chunk so an application change does not invalidate the largest cached asset a returning user already holds.

Where React is the wrong choice

Content-heavy pages that must rank, where a static generator will produce better results for less work. Interfaces so simple that the library’s weight and build chain exceed the problem. And large organisations that need one enforced structure across many teams, where an opinionated framework’s constraints are the feature and React’s freedom is the cost.

There is also a team-shape answer. React makes it easy to arrange an application in a dozen defensible ways, which is fine with one team and expensive with five, unless someone is empowered to say which way is the house style and hold that line in review.

What we interview for

Ask about the second year of an application rather than the first. What did their state management look like once forty screens shared it, how did they stop a table of ten thousand rows from stuttering, and what broke when React 18 changed effect behaviour under strict mode. Candidates who have only built greenfield features tend not to have answers to any of those.

Two more that separate quickly. What happens to an in-flight request when the user navigates away mid-load, and can they name the mechanism that cancels it. And: a component re-renders on every keystroke somewhere else on the page — what do you check first. We are listening for context boundaries and where the state was declared, not for a reflexive React.memo on everything.