React Personal Account for 1C-Bitrix Development
We know firsthand: the standard personal account in 1C-Bitrix is a set of PHP components bitrix:sale.personal.* that render on the server, deliver a full HTML page, and on any user action (changing delivery address, viewing order status) perform a full page reload. In small stores, this is tolerable. When the account has an order history of 200+ items, a loyalty system, multiple delivery addresses, documents, and integration with external services — the standard approach becomes a bottleneck in terms of UX and performance. Developing a personal account on React solves this problem: the server only provides data via REST, the interface lives in the browser. This gives instant transitions between sections, data updates without reloads, and the ability to build complex interactive forms without page recompilation. According to our case study, a React account reduces load time by 70% and lowers operational support costs.
How a React Account Increases Performance
With server-side rendering, every navigation is a new request that builds the entire page again. A React account only loads data: order list, profile, history. The browser updates only the necessary part of the interface. For example, switching between 'Orders' and 'Addresses' tabs takes 50–100 ms instead of 1–2 seconds for a full reload. This is confirmed by our case studies: order page load time decreased from 4.2 to 0.9 seconds (see table below).
Integration Architecture
There are two fundamentally different ways to embed a React account into Bitrix.
Option 1: React inside a Bitrix template. On the PHP page /personal/, a React application is mounted in a container <div id="personal-root"></div>. Bitrix handles authorization, SEO (title, meta), and the overall layout (header, footer). React manages only the account content. Routing is via React Router with BrowserRouter, browser history is synced with URL. This option is simpler to integrate: authorization through standard $USER->Login(), Bitrix session is passed automatically, CSRF token taken from BX.bitrix_sessid().
Option 2: SPA with JWT authorization. The React application lives separately (separate domain or subdomain) and communicates with Bitrix exclusively via REST API with JWT tokens. Authorization is through a custom endpoint, token stored in httpOnly cookie or localStorage. This option is justified when the account must work with both a mobile app and a web version through the same API. For most projects, Option 1 is optimal—it's easier to maintain and doesn't require separate deployment; authorization is already solved.
| Parameter |
React inside template |
Standalone SPA |
| Deployment complexity |
Low (one site) |
High (CORS, separate hosting) |
| Authorization |
Uses Bitrix session |
JWT tokens, custom |
| Performance |
Fast (no reload) |
Fast (no reload) |
| SEO of account pages |
Supported |
Poor (needs isolation) |
| Module compatibility |
Full |
Limited (REST only) |
API Layer on the Bitrix Side
React components interact with data via AJAX requests to Bitrix. For this, a controller is created in /local/php_interface/include/api/personal/:
// Example: endpoint for order list
class PersonalOrdersController extends \Bitrix\Main\Engine\Controller
{
public function getListAction(int $page = 1, int $limit = 20): array
{
$userId = \Bitrix\Main\Engine\CurrentUser::get()->getId();
$orderList = \Bitrix\Sale\Order::getList([
'filter' => ['USER_ID' => $userId],
'select' => ['ID', 'DATE_INSERT', 'PRICE', 'STATUS_ID', 'CURRENCY'],
'order' => ['DATE_INSERT' => 'DESC'],
'limit' => $limit,
'offset' => ($page - 1) * $limit,
]);
$orders = [];
while ($order = $orderList->fetch()) {
$orders[] = $order;
}
return [
'orders' => $orders,
'total' => \Bitrix\Sale\Internals\OrderTable::getCount(['USER_ID' => $userId]),
];
}
}
Routing in Bitrix via local/ajax/personal.php with a dispatcher or through \Bitrix\Main\Engine\Router. For CSRF protection, all POST requests from React send the header BX-Ajax: true and the session token.
React Application Structure
src/
personal/
api/ # axios instance, request types
components/ # reusable UI elements
pages/
Orders/ # order history
OrderDetail/ # order detail page
Profile/ # profile data
Addresses/ # delivery addresses
Loyalty/ # loyalty program
store/ # state (Zustand or Redux Toolkit)
App.tsx
router.tsx
State management: for simple accounts, React Query (request cache + synchronization) is sufficient without a global store. For complex ones, Zustand as a lighter alternative to Redux.
Case Study: B2B Distributor Account
A wholesale supplier of electronics, ~1,500 active client accounts. Task: a personal account for client managers — ability to view purchase history, reorder from history, manage multiple legal entities in one account, download closing documents. The standard Bitrix account did not support multi-legal entities at all, and order history with 3,000+ lines rendered on the server in 4–6 seconds.
Implementation Details
-
API controller for orders with server-side pagination, filtering by date/status, and search by order number. A request for a page of 50 items — 80–120 ms vs 4+ seconds for full render.
-
Multi-legal entities via custom table local_personal_company (relation user_id → company_id), company switcher in the account header with context reload via React Query invalidateQueries.
-
'Reorder' button in history that adds all order items to the cart via \Bitrix\Sale\Basket::create() and bulk-inserts items. On the frontend — animated indicator, toast notification on success.
-
Documents — integration with 1C: order documents via 1C REST, generation status via polling every 3 seconds, direct PDF download from 1C using a temporary link.
| Metric |
Before |
After |
| Order page load |
4.2 sec |
0.9 sec |
| Reorder |
5 steps, 2 minutes |
1 click, 3 seconds |
| Support tickets for documents |
~40/month |
~8/month |
Reducing support tickets by 80% cuts maintenance costs. This saves budget for support and allows resources to be directed to development.
What's Included in Turnkey Account Development?
- API design: endpoints, data structure, pagination, filtering.
- Server-side development: controllers, authorization, access rights.
- React application development: routing, components, state management.
- Integration with Bitrix modules:
sale, catalog, crm as needed.
- Build, deployment, API response caching setup.
- API and component structure documentation.
- Administrator training: how to add new sections or modify data.
- Warranty: we maintain build and API functionality for 3 months after delivery.
Timeline Estimates
Basic account (profile + orders + addresses) — 3–4 weeks. Full-featured B2B account with multi-legal entities, 1C integration, and document workflow — 2–4 months. We specify timelines after auditing your requirements during a free consultation.
Why Choose React for a Personal Account?
A React account is 3–5 times faster than standard on pages with large amounts of data. It allows building interfaces impossible with standard components — for example, multi-legal entities, dynamic filters, real-time editing. Moreover, a React application is easier to maintain and extend due to its modular architecture. If you have a complex account with unique logic, this is the right choice.
Order a free consultation: we will evaluate your project and offer the optimal solution. We work turnkey: from API design to deployment and training. Get a consultation — we will explain how React will speed up your account and reduce support costs.
What Does React Development for 1C-Bitrix Provide and When Is It Needed?
A catalog with 30,000 SKUs and a faceted filter — the standard Bitrix template loads the page in 3 seconds. A B2B cabinet with personalized discounts — price recalculation with every filter change. The bottleneck is not the data but the monolithic architecture: each block calls REST separately, 6–8 sequential requests of 200–500 ms result in a total delay of 2–3 seconds. React solves this radically: component model, virtual DOM, and library ecosystem turn a slow interface into a responsive application. We are a certified 1C-Bitrix partner with 10+ years of experience and over 500 completed projects. Order an audit — we will evaluate your project in 1–2 days and show cases similar to yours.
Architectural Approaches
SPA on React + REST API Bitrix (BX.rest)
The React application lives separately, accessing /rest/ or custom endpoints via CRestServer. Maximum control, but also maximum work.
- Client-side routing with React Router — transitions without reload, but on F5 you need a catch-all on Nginx:
try_files $uri /index.html
- Optimistic updates: cart updates instantly,
sale.basket.update flies in the background. On error, roll back state and show a toast
- Frontend deploys to CDN independent of Bitrix — updated a button without touching the backend
SSR with Hydration — When Yandex Doesn't See SPA
Yandex has learned to render JS, but not perfectly; Googlebot is better, but still not 100%. Server-side rendering of React components via Node.js solves the problem radically: the bot receives ready HTML, the user gets an interactive application after hydration. FCP drops below one second on normal hosting, og:title and og:image work for social networks. The complexity is needing a Node.js process alongside Apache/Nginx serving Bitrix: two runtimes, two deploys, two log sets. Bitrix cache (CPHPCache, Composite) can be used to warm data that later goes to SSR.
Headless Bitrix — Admin Panel for Content Managers, React for Visitors
Content manager logs into /bitrix/admin/, edits infoblocks. The visitor sees a React application that retrieves data via API. One backend serves the site, mobile app, and Telegram bot. Scaling: React bundle on CloudFront/CDN, Bitrix on a single server. With 50,000 unique visitors, the frontend does not directly load the backend. Pitfall: the standard Bitrix visual editor (BXEditor) stops working for visitors — content managers will have to work only through the admin panel.
Stack and Component Architecture
Stack We Actually Use
| Technology |
Why It's Used |
| React 18+ |
Suspense, useTransition — UI does not block during heavy catalog updates |
| TypeScript |
Typing Bitrix API responses — IBlockElement, BasketItem, Order. Without it, refactoring is Russian roulette |
| Vite |
HMR in 50 ms vs 3–5 s for webpack. On a project with 200 components, the difference is enormous |
| React Query |
useQuery(['catalog', sectionId]) — automatic cache, revalidation, retry on 503 from overloaded Bitrix |
| React Hook Form + Zod |
Order form: 15–20 fields, conditional validation (legal entity — one set, individual — another). RHF does not re-render form on every keystroke |
| Tailwind CSS |
Utility classes — no fighting with cascades from Bitrix's template_styles.css |
| Radix UI / Shadcn |
Accessible primitives with ARIA out of the box |
How We Build Components and Type Data
Every project starts with a design system — otherwise, by the third month, three developers will write three different button components. Typography, colors, spacing — via CSS variables and Tailwind config. Forms: inputs with masks (phone, INN), searchable selects, file upload with preview and MIME validation. Product card is a separate story: price with discounts from CCatalogProduct::GetOptimalPrice(), labels "Hit"/"New" from infoblock properties, "Add to cart" button with loading/success/error states. Tables with virtualization (react-window) for price lists of 5000+ rows.
We type everything that comes from Bitrix. The REST API returns string where you'd expect number, "Y"/"N" instead of boolean, and null instead of empty array. A Zod schema on input parses and transforms — components get proper types.
// Real type of CIBlockElement via REST — surprises everywhere
interface BitrixProduct {
ID: string; // yes, string, not number
ACTIVE: "Y" | "N"; // not boolean
PRICE: string; // also string
QUANTITY: string; // and this is string
}
Performance and API Integration
Aggregating endpoints are key. One ajax.php or custom controller on \Bitrix\Main\Engine\Controller gathers catalog data, filters, cart, and user in a single request. React Query caches the response, and a second visit returns from cache with staleTime — load time reduces by 60% already on the second load.
How Does React Improve Core Web Vitals?
-
LCP < 2.5 s — lazy loading images via
loading="lazy", inline critical CSS, preload LCP image via <link rel="preload">
-
INP (replaces FID) < 200 ms —
useTransition for heavy filtering, useDeferredValue for search input
-
CLS < 0.1 — fixed sizes for skeletons and images. Skeleton placeholders instead of spinners
Virtualization is not optional, but necessary. A catalog with faceted filter may return 500 products per page. React-window or react-virtuoso render only the visible 20–30 cards — DOM does not bloat, scrolling is smooth.
REST and Custom Controllers
Out of the box via /rest/: infoblocks (iblock.element.get), cart (sale.basket.*), orders (sale.order.*), users (user.*). For a simple catalog, that's enough. But 70% of tasks require custom endpoints. \Bitrix\Main\Engine\Controller is the standard way to create your own endpoints in D7. Write a controller, register via registerAction, get endpoint with CSRF protection and authorization out of the box.
- Aggregation: one request = catalog data + filters + cart + user
- WebSocket via Bitrix Push & Pull (
CPullStack::AddByTag) — order status updates in real time, no polling
- GraphQL middleware (webonyx/graphql-php) on top of D7 ORM — frontend requests exactly the fields it needs. Mobile traffic savings up to 40%
Projects, Timelines, and What's Included
Typical Projects We Have Already Done
- Online store with 30,000 SKUs and faceted filter via
\Bitrix\Iblock\PropertyIndex\Facet — SPA, React Query, catalog virtualization
- B2B cabinet: personalized prices from
CCatalogGroup, reconciliation statements from 1C via \Bitrix\Sale\Compatible\OrderCompatibility, order history with filtering
- Corporate portal: dashboards on Recharts, real-time via Push & Pull, integration with internal APIs through middleware
- Marketplace: two React applications (buyer + seller), common backend, data separation via
CUser::GetUserGroup()
Timelines and What's Included
| Project Type |
Timeline |
| Landing page on React + Bitrix |
2–4 weeks |
| SPA online store |
8–16 weeks |
| Corporate portal |
10–20 weeks |
| Gradual frontend migration to React |
6–12 weeks |
- Audit of current Bitrix code and architecture
- Design of API layer (REST / custom controllers / GraphQL)
- Development of design system and components
- CI/CD setup (deploy React bundle independently of Bitrix)
- Documentation of endpoints and types (Swagger / TypeScript types)
- Transfer of access to server, admin panel, repository
- Training content managers to work through the admin panel
- Warranty support for 2 months after delivery
Exact numbers after scope analysis. Assessment is phased, with a fixed budget for each sprint.
How We Implement React in a Project
- Audit existing code — find bottlenecks: redundant requests, outdated templates, suboptimal caches.
- Design API layer — determine which endpoints are needed, design aggregators or GraphQL.
- Develop design system — create components (buttons, forms, cards) based on mockups or UX recommendations.
- Integrate with Bitrix via chosen approach (SPA, SSR, or Headless) — set up rendering and routing.
- Test and deploy — launch a pilot section (e.g., catalog), measure Core Web Vitals, upon approval expand.
Typical Mistakes When Implementing React in Bitrix
- Ignoring Bitrix caching — React Query may conflict with composite cache if tagged caching is not configured.
- Lack of error handling from REST — on a 500 error, the interface may "freeze". Need a global handler with fallback UI.
- Too many micro-components — each small widget calls API. Better to aggregate data in a single request.
- Wrong hydration order in SSR — data from the server must exactly match the client's initial state, otherwise React hydration errors.
Why React, Not Vue or Bitrix Templates
- Ecosystem. For any UI task, there is a ready library: tables, charts, drag-and-drop, virtualization. For Vue, the choice is narrower; for Bitrix templates, almost absent.
- Talent pool. Finding a React developer is three times easier than a Bitrix templater who knows D7 and
template.php.
- React Native. Components are reused in mobile app — not one-to-one, but business logic and types are shared.
- Gradual adoption. Start with one section (
/catalog/) on React, keep the rest on Bitrix templates. component_epilog.php loads the React bundle, data is passed via window.__INITIAL_DATA__.
1C-Bitrix + React is not a theoretical architecture but a working combination that already serves catalogs with tens of thousands of SKUs and B2B cabinets with heavy business logic. Learn more about React and 1C-Bitrix. Get a consultation — we will send you cases similar to your project. Contact us to discuss details. We implement turnkey with a guarantee of results.