Keeping Admin Table State During Background Refresh
Our reset matrix separated changed filters from same-query polling, clamped shrinking lists and kept the limits of capped local pagination visible
Reviewed by Dmytro Nasyrov on October 22, 2026.
An admin could be on a later table page with a chosen sort when a background refresh replaced the data array. If that replacement was treated as a new filter, the interface could send the person back to page one even though their browsing intent had not changed. We made reset behavior explicit in the shared table engine. A user changing filters, sort or page size was different from the server returning fresher rows for the same selection. Both events changed inputs, but only one represented a new browsing request.
Define the transition before writing the effect
The table accepted an explicit filter identity. When that identity changed, pagination reset. A refetch with the same identity retained the page and sort. This avoided using array identity as a substitute for user intent. The distinction matters because fetching code can legitimately create a new array for an unchanged query. Resetting on every new array would couple navigation to a transport implementation detail. Avoiding every reset would fail in the opposite direction, leaving the reader on an inappropriate page after choosing a narrower filter.
| Event | Pagination policy |
|---|---|
| Filter changes | Return to page one |
| Sort changes | Return to page one |
| Page size changes | Return to page one |
| Same-filter refresh | Retain current page and sort |
| Rows shrink below current page | Clamp to the last valid page |
Retention still needed a validity check
Keeping page three is unhelpful if the refreshed list now ends on page two. We clamped the selected page to the valid range after the row count changed. That is a different transition from resetting to the beginning. The clamp preserved as much location as the new dataset allowed. It also avoided rendering an apparently empty page when records were still available elsewhere in the current result. The tests exercised shrinking rows separately from filter changes.
Sorting remained another responsibility. A stable, locale-aware ordering rule does not decide whether a background refresh should change the user's navigation state. Combining those concerns in one reset effect would make both harder to test.
Tests had to reject the tempting implementation
We included a same-filter poll case where the data changed but the selected page did not. That case would fail an effect keyed only to the new data array. We also checked explicit filter changes, page-size changes and the shrinking-list boundary.
The hook tests expressed the state rules directly. Product-level table scenarios then checked that controls and visible records followed them. Neither layer alone was enough: a correct hook can still be wired to an unstable filter key in a screen.
Preserving a curator's unsaved content during polling concerns the editing lifetime. The pagination reset matrix controls navigation state and does not decide when an editor's draft survives.
A fixture that changes object identity without changing intent
The saved regression did something more precise than rerendering the same array. It copied every person into a new object, retained filterKey: 'all' and asserted the selected page and sort afterward. This makes an array-identity reset fail even though all visible values could look unchanged. The fixture is small enough to inspect directly:
act(() => result.current.toggleSort('joined'))
act(() => result.current.setPage(2))
rerender(options({
filterKey: 'all',
rows: PEOPLE.map((person) => ({ ...person })),
}))
expect(result.current.sort).toEqual({
column: 'joined', direction: 'desc',
})
expect(result.current.page).toBe(2)
Those assertions close different holes. Keeping page two while silently restoring the default sort would still displace the reader within the result. Keeping the sort while resetting the page would preserve the ordering but lose the reader's location. A screenshot of the first rows after refresh would not distinguish those failures from an intentional reset.
The shrinking-list fixture began on page three of a 23-person collection, then replaced the rows with the first 12 people. With ten rows per page, its expected state became page two, two pages total and the visible range 11 through 12. That exact range matters: a test asserting only that the table contains some rows could pass an implementation that jumped to page one. The fixture checks the least disruptive valid location.
Returning to a previous filter had its own assertion. After moving from all to active, the test returned to all and still expected page one. The key names a new browsing selection when it changes, even if the user has chosen that selection before. It is not an instruction to restore a remembered page for every previously visited filter.
These examples also expose the screen-level integration risk. A hook can pass every assertion while a component passes a freshly serialized timestamp as its filter identity on every poll. The engine would then correctly treat each refresh as a new filter. The integration has to derive the key from the actual filter values, and leave transport freshness outside it.
Local pagination did not imply a complete dataset
At the recorded stage, users, companies and feedback queries loaded at most 100 rows. The frontend paged within that retrieved set and displayed a cap note. It did not turn local pagination into a claim that the user could browse every record in the service. A stable page can still belong to an incomplete list. This limit needed to remain visible near the table, especially when a user interpreted a missing item or a count. Better state retention did not add server pagination.
Recorded outcome and limits
The shared hook assertions and table scenarios are present in the source snapshot, and the table integration merge reports browser checking of desktop and phone layouts. No task-time or productivity measurement was recorded.
The reusable artifact is the reset matrix. It lets a reviewer ask which event changed the person's intent, whether the current page remains valid and whether the loaded result is complete. Those questions keep a routine data refresh from becoming an unexplained navigation command.
FAQ
Quick answers to common questions about custom software development, pricing, process and technology.
Type to filter questions and answers. Use Topic to narrow the list.
Showing all 14
No matches
Try a different keyword, change the topic or clear filters
-
How long have you been in business?
Pharos Production has been in business since 2013, with over 13 years of experience in custom software development. During this time, we have delivered over 110 applications for 200+ clients across 28 industries, including FinTech, healthcare, crypto and e-commerce. We are rated 5/5 on Clutch based on 107 verified reviews (2026).
-
What services do you provide?
Pharos Production provides six core service categories: AI Development (LLM applications, AI agents, machine learning and computer vision), Blockchain and Web3 (smart contracts, DeFi, tokenization on Ethereum, Solana, TON and other chains), FinTech Development (payment platforms, digital banking, KYC and AML integration), Software Development (mobile apps, web platforms, database design, UI/UX), Security and QA (code audits, penetration testing, smart contract audits, manual and automated testing) and Consulting (architecture design, MVP validation, startup consulting).
-
Where is Pharos Production located?
Pharos Production is headquartered in Las Vegas, Nevada, USA (5348 Vegas Dr, Las Vegas, NV 89108), with an engineering office in Kyiv, Ukraine (44-B Eugene Konovalets Str. Suite 201, Kyiv 01133). We work with clients worldwide and provide remote collaboration across all time zones. Visit our contact page for directions and scheduling options.
-
How big is your team?
Pharos Production has a team of 90+ engineers, including software developers, blockchain specialists, QA engineers, DevOps experts, UI/UX designers, project managers and solution architects. Our founder, Dr. Dmytro Nasyrov, holds a PhD in Artificial Intelligence and leads the technical direction of all projects.
-
What types of customers do you serve?
We serve a wide range of clients, from startups and product companies to mid-sized enterprises and large institutions. Our clients include crypto exchanges, FinTech providers (like Pleenk), healthcare organizations, sportsbook operators (like Pro Gambling), e-commerce platforms and SaaS companies. Pharos Production has worked with 200+ clients across 28 industries since 2013, adapting engagement models to match each client's stage, whether it is MVP validation for a startup or enterprise-scale development for an established business.
-
How is a custom software development company different from an agency?
A custom software development company like Pharos Production assigns one dedicated engineering team that owns your product across multiple release cycles, instead of handing it off once a contract ends. Agencies more often rotate staff between clients and optimize for fast delivery over long-term product ownership.
Pharos Production keeps the same team on your codebase through 2-week sprints, so there is no re-onboarding cost each time you request a new feature.
-
How much does custom software development cost?
Custom software development costs vary based on project scope and complexity. At Pharos Production, typical project ranges are: MVP development ($10,000-$25,000), suitable for startups validating a product idea; full-fledged production ($25,000-$50,000), for established businesses scaling a proven concept; and full-cycle development ($50,000-$80,000+), for complex enterprise-grade systems. These ranges include architecture design, development, QA testing and deployment. Hourly rates range from $50 to $99 depending on role and seniority. Final pricing depends on technology stack, number of integrations and engagement model (staff augmentation, dedicated team or project outsourcing).
-
How long does it take to develop a custom software application?
Development timelines depend on scope and complexity. At Pharos Production, a typical MVP takes 2-4 months, a production-ready application takes 4-8 months and a complex enterprise system can take 8-12+ months. We use an agile methodology with 2-week sprints, delivering working increments after each sprint. Every sprint includes a retrospective, progress report and planning session for the next iteration. This approach ensures transparency and allows businesses to launch faster by prioritizing high-impact features first. Get a timeline estimate for your project.
-
What industries does Pharos Production serve?
Pharos Production serves 28 industries: FinTech, MiCA Compliance, Banking, Insurance, Crypto, Healthcare, Fitness, E-Commerce, Food & Restaurant, On-Demand, Manufacturing, Automotive, Energy, Oil & Gas, Supply Chain, Construction, Real Estate, Gaming, Streaming, Media, Telecom, Education, Aviation, Travel, Logistics, Marketing, Agriculture and Recommender Systems. Our deepest expertise is in FinTech, blockchain and healthcare, where we have delivered compliance-ready platforms (HIPAA, PCI DSS, GDPR) and high-load systems handling thousands of concurrent users. For the latest industry insights, read our guides on FinTech trends in 2026 and the Web3 technology stack.
-
Why hire a software development company instead of building in-house?
Hiring a software development company offers faster time-to-market, lower upfront costs and access to specialized expertise without long-term employment commitments. According to Deloitte's 2024 Global Outsourcing Survey, 57% of companies outsource software development to access skills they cannot hire internally.
Factor In-house team Software development company Time to assemble 3-6 months (recruiting + onboarding) 1-2 weeks Upfront cost High (salaries, benefits, equipment) Lower (project-based pricing) Specialized expertise Limited to who you can hire locally Access to 90+ engineers across blockchain, AI, FinTech Scalability Slow (each new hire takes months) Fast (scale up or down per sprint) Long-term commitment Full-time employment contracts Flexible engagement models Risk High if key engineers leave Company ensures continuity and knowledge transfer For businesses that need blockchain, AI or high-load architecture expertise, outsourcing to a specialized firm like Pharos Production reduces risk and accelerates delivery.
-
What projects does Pharos Production not take on?
Pharos Production focuses on mid-to-large custom software projects with budgets starting at $10,000. We do not take on template-based websites, WordPress theme customization or short-term contracts under one month. We also do not provide non-technical staffing (marketing, sales or design-only roles). Our strongest fit is blockchain, FinTech and healthcare projects where security, compliance and high-load architecture are critical. For smaller projects or MVPs under $10,000, we recommend exploring freelance platforms or no-code tools as a more cost-effective starting point.
-
Why does Pharos Production use agile methodology?
We use agile with 2-week sprints because it reduces the risk of building features that miss the mark. Each sprint ends with a working demo, a retrospective and a plan for the next iteration.
This means clients see progress every 14 days and can adjust priorities based on real results, not assumptions. We chose this approach after years of experience showing that rigid, fixed-scope contracts lead to scope creep, missed deadlines and products that do not match market needs by launch day.
-
When should you NOT hire a custom software development company?
Custom development is not the right choice in every situation. You should not hire a custom software company if: your problem is fully solved by an existing SaaS product (e.g. Shopify for e-commerce, Salesforce for CRM); your budget is under $10,000 and timeline is under 4 weeks; you need a simple landing page or marketing website (WordPress or Webflow is faster and cheaper); or you are still validating the idea and have not spoken to potential users yet.
In these cases, off-the-shelf tools or no-code platforms offer better ROI. Custom development makes sense when you need unique workflows, regulatory compliance, high-load architecture or competitive differentiation that packaged software cannot provide.
-
What kind of projects has Pharos Production delivered?
Here are three anonymized examples from our recent delivery history:
FinTech startup - payment platform (MVP)
Scope: mobile app + backend API with bank-grade encryption. Team: 4 engineers, 1 QA. Timeline: 10 weeks. Budget: $38,000. Result: launched on schedule, processed $2M+ in transactions within the first quarter.Healthcare provider - patient portal (Full product)
Scope: HIPAA-aligned web platform with EHR integration, appointment scheduling and telemedicine. Team: 6 engineers, 1 DevOps, 2 QA. Timeline: 6 months. Budget: $120,000. Result: 15,000+ active patients, zero compliance violations in two annual audits.Crypto exchange - trading engine (Complex)
Scope: high-load matching engine handling 50,000+ orders per second, multi-chain wallet infrastructure on Ethereum and Solana. Team: 8 engineers, 2 QA, 1 security auditor. Timeline: 11 months. Budget: $340,000. Result: 99.97% uptime, passed three independent security audits.See more projects: NoMoreBets, Pulse, Sagas, Gambit Stream and Pleenk. For the full portfolio, visit our case studies. Learn more about the technology behind these projects in our guide to stablecoins and crypto infrastructure.
Stas Rysin is the Lead Frontend Developer at Pharos Production. His work covers the design system, reader interfaces and administration workflows of a professional learning platform for aesthetic medicine.