Booking service
Consistent selection of branch, practitioner and appointment time.
← All technologies
React · BIG FISH
Web development with React
Customer portals, booking services and operational tools with many interacting states. We build a consistent component system and connect it to your API.
BIG FISH / REACT
01Choose branch
02Shared state
03Available slots
04Confirmation
Design × technology × your workflow
PRODUCT CAPABILITIES
Technology becomes
a working product.
Customer portal
Activity history, documents and statuses in a component system.
Employee workspace
Tables, filters and actions with explicit saving states.
INTERACTIVE EXAMPLE
Try the workflow.
See the outcome.
A clinic-network booking flow: the branch determines available slots. Changing branch resets the old selection so only a current choice can be confirmed.
Educational example with fictional data. Actions stay in your browser. This models the workflow; it is not a connected CMS, server or database.
React
ReactWorkflow result
The example is ready to explore.
WORKFLOW ARCHITECTURE
Every step has
a responsibility.
01
Choose branch
02
Shared state
03
Available slots
04
Confirmation
| Layer | Outcome |
|---|---|
| Interface | Input, limits, loading and errors are clear. Keyboard operation is available. |
| Data | Values have an owner, format and freshness rules. |
| Release | Critical journeys, backups and recovery have been checked. |
BIG FISH · React
Components that hold a product together.
React application development starts with an interface component system. Order tables, filter panels and customer cards follow shared selection, editing and feedback rules, so users do not have to relearn every screen.
For React portals, we design loading, empty results and update conflicts as distinct states. The design system describes component behaviour as well as appearance, keeping new features consistent with the product.
PRACTICAL GUIDE
Building a product
with React.
Architecture, constraints and testable workflows. The exact configuration follows the project requirements.
React / 01
Component boundaries
Separate responsibilities into branch selection, timetable, practitioner card and booking summary. Reuse helps when inputs and events remain clear. An overly generic component with many flags becomes harder to maintain. Define visual states with the designer before connecting the real API.
Acceptance check
The component shows loading and error states.
React / 02
A single state model
Store the selected branch and slot in a consistent model. Derive the branch name and booking summary rather than duplicating them in unrelated variables. Recheck dependent values when the branch changes. This prevents a slot from one clinic appearing alongside another clinic’s address.
Acceptance check
Changing branch resets the selected time.
React / 03
API data
Separate local user selections from server data. Show a loading state while requesting a new timetable instead of presenting old availability as current. Define freshness and refetch rules. Cancellation and request-identity checks prevent late responses from corrupting the screen.
Acceptance check
An old timetable is not presented as a new one.
const [branchId, setBranchId] = useState('north');
const [slotId, setSlotId] = useState(null);
function changeBranch(id) {
setBranchId(id);
setSlotId(null);
}React / 04
Forms and confirmation
Validate required fields, consents and error messages. Clicking Book does not mean the booking succeeded: the server must confirm availability. On conflict, return to slot selection while preserving other input. The demonstration shows an interface model only and sends no personal information to a clinic.
Acceptance check
An unavailable slot requires a new selection.
React / 05
Design system
Buttons, inputs, alerts and dialogs share sizing, colours and states. Theme changes should not require rewriting each screen. Check contrast, keyboard access and long labels. A component is ready when it works during loading, failure and empty states, not only in an ideal mockup.
Acceptance check
The button is keyboard-accessible.
React / 06
Screen performance
Measure actual delays during input, filtering and navigation. Large lists need a deliberate rendering strategy. Do not add memoisation everywhere without measurements; it cannot repair a poor data model. Images, JavaScript size and network calls affect perceived speed alongside component rendering.
Acceptance check
Filtering is measured against the complete dataset.
React / 07
Routes and public pages
React alone does not define the entire routing and server-rendering architecture. A public catalogue and private portal may have different needs. Select suitable tooling and test direct URL entry, refresh and browser back navigation. Address public-page SEO separately from internal application screens.
Acceptance check
Refreshing retains the correct route.
React / 08
Acceptance and evolution
Test state transitions: selection, branch change, slot conflict, repeated confirmation and cancellation. Verify accessibility and integration contracts. Every new feature should pass regression checks for critical journeys. Hand over the component library, API description and state rules so future development remains coherent.
Acceptance check
Repeated confirmation does not duplicate the booking.
FAQ
Before we start
Is this a ready-made product?
No. The example illustrates a proposed workflow for React. We design the production system around your requirements, data and integrations.
Can we retain our current systems?
We first review their interfaces, data ownership and constraints. The result may be an integration, a phased migration or a focused replacement of one component.
What do we receive at handover?
The agreed deliverables include design assets, source code, environment requirements and operational instructions. Scope, ownership and support are recorded in the contract.
Let’s design your product
Tell us about your workflow, audience and existing systems. We will define the interface, technical boundaries and delivery stages.