Разработка фронтенда на TypeScript для 1С-Битрикс

Наша компания занимается разработкой, поддержкой и обслуживанием решений на Битрикс и Битрикс24 любой сложности. От простых одностраничных сайтов до сложных интернет магазинов, CRM систем с интеграцией 1С и телефонии. Опыт разработчиков подтвержден сертификатами от вендора.
Услуги, которые мы предлагаем
Показано 1 из 1Все 1626 услуг
Разработка фронтенда на TypeScript для 1С-Битрикс
Средний
~1-2 недели
Часто задаваемые вопросы

Наши компетенции:

Этапы разработки

Последние работы

  • image_website-b2b-advance_0.webp
    Разработка сайта компании B2B ADVANCE
    1357
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Разработка веб-сайта для компании ФИКСПЕР
    946
  • image_bitrix-bitrix-24-1c_development_of_an_online_appointment_booking_widget_for_a_medical_center_594_0.webp
    Разработка на базе Битрикс, Битрикс24, 1С для компании Development of an Online Appointment Booking Widget for a Medical Center
    693
  • image_bitrix-bitrix-24-1c_mirsanbel_458_0.webp
    Разработка на базе 1С Предприятие для компании МИРСАНБЕЛ
    829
  • image_crm_dolbimby_434_0.webp
    Разработка сайта на CRM Битрикс24 для компании DOLBIMBY
    732
  • image_crm_technotorgcomplex_453_0.webp
    Разработка на базе Битрикс24 для компании ТЕХНОТОРГКОМПЛЕКС
    1075

Битрикс-проект с каталогом на 50 000 товаров — это постоянная борьба с несоответствием типов. При передаче данных из PHP в JavaScript часто всплывают баги: undefined is not an object, неправильные типы цен, слетевшие фильтры. Мы регулярно сталкивались с этим на проектах любой сложности. TypeScript закрывает эту проблему: статическая типизация ловит ошибки на этапе компиляции, а не в браузере пользователя. Опыт нашей команды — 8 лет в Битрикс и более 50 реализованных проектов с TypeScript-архитектурой. Результат: снижение стоимости багфикса на 30–50% и сокращение времени на отладку интеграций. На одном проекте экономия на багфиксах составила существенную сумму за первый год после миграции.

Почему TypeScript, а не ванильный JavaScript для Битрикс?

Согласно TypeScript Handbook (на Wikipedia), статическая типизация предотвращает до 15% ошибок на этапе компиляции. В контексте Битрикс это критично: неверный тип цены или ID товара может привести к падению корзины. На одном из проектов с каталогом на 100 000 товаров мы полностью устранили баги фильтрации после перехода на строгую типизацию. TypeScript-фронтенд в 2–3 раза надёжнее аналогичного решения на чистом JS: ошибки типов, некорректная передача данных между PHP и JS, проблемы с кэшированием — всё это выявляется до выкладки в продакшн.

Как происходит интеграция TypeScript с PHP-компонентами?

Мы используем пошаговый подход, чтобы минимизировать простои:

  • Аудит текущего JS-кода: выявляем несоответствия типов, глобальные переменные, слабые места.
  • Проектирование типов для всех точек интеграции с PHP (инфоблоки, REST, компоненты).
  • Настройка сборщика Vite или Webpack с поддержкой TypeScript.
  • Разработка компонентов с полной типизацией — каталог, корзина, фильтр.
  • Тестирование и деплой с гарантией стабильности.

Архитектура TypeScript в шаблоне Битрикс

Два основных подхода, которые мы применяем:

Подход Описание Когда выбирать
MPA с TypeScript-модулями Классическая генерация страниц на PHP, JavaScript — островки интерактивности. Каждый компонент — изолированный модуль с собственными типами. Проекты среднего размера, где SEO и скорость первой загрузки критичны.
SPA/Headless React или Vue на TypeScript полностью управляют UI, Битрикс выступает как API (REST/GraphQL). Сложные пользовательские интерфейсы: кабинет клиента, CRM-виджеты, многошаговые формы.

Большинство наших проектов используют первый подход с элементами второго в самых интерактивных частях (каталог, корзина, личный кабинет).

Пример структуры компонентов
/local/templates/my_site/
├── src/
│   ├── components/
│   │   ├── catalog/
│   │   │   ├── CatalogFilter.ts
│   │   │   ├── ProductCard.ts
│   │   │   └── CartButton.ts
│   │   ├── cart/
│   │   │   ├── CartDrawer.ts
│   │   │   └── CartCounter.ts
│   │   └── common/
│   │       ├── Modal.ts
│   │       └── Tooltip.ts
│   ├── api/
│   │   ├── catalog.ts
│   │   ├── cart.ts
│   │   └── user.ts
│   ├── types/
│   │   ├── bitrix.d.ts
│   │   └── api.ts
│   ├── utils/
│   │   ├── http.ts
│   │   └── format.ts
│   └── main.ts
├── dist/
├── package.json
├── tsconfig.json
└── vite.config.ts

Компонент корзины на TypeScript

Пример типизированного компонента добавления в корзину:

// api/cart.ts
interface CartItem {
    id:       number;
    name:     string;
    price:    number;
    quantity: number;
    img:      string | null;
}

interface CartState {
    items:      CartItem[];
    totalPrice: number;
    totalCount: number;
    currency:   string;
}

interface AddToCartPayload {
    productId: number;
    quantity:  number;
    properties?: Record<string, string>;
}

export async function addToCart(payload: AddToCartPayload): Promise<CartState> {
    const formData = new FormData();
    formData.append('sessid',     BX.bitrix_sessid());
    formData.append('action',     'addItem');
    formData.append('product_id', String(payload.productId));
    formData.append('quantity',   String(payload.quantity));

    if (payload.properties) {
        Object.entries(payload.properties).forEach(([k, v]) => {
            formData.append(`props[${k}]`, v);
        });
    }

    const res = await fetch('/local/ajax/cart.php', {
        method: 'POST',
        body:   formData,
    });

    if (!res.ok) throw new Error(`Cart error: ${res.status}`);

    const json = await res.json();
    if (json.status !== 'success') throw new Error(json.error ?? 'Cart error');

    return json.cart as CartState;
}

Интеграция с PHP-компонентами через data-атрибуты

Передача данных из шаблона в TypeScript без глобальных переменных:

// template.php компонента каталога
<div
    id="catalog-app"
    data-section-id="<?= (int)$arResult['SECTION']['ID'] ?>"
    data-iblock-id="<?= (int)$arParams['IBLOCK_ID'] ?>"
    data-initial-filter='<?= htmlspecialchars(
        json_encode($arResult['FILTER_PARAMS']), ENT_QUOTES
    ) ?>'
>
    <?php // SSR-вёрстка для первой загрузки ?>
</div>
// TypeScript читает данные типизированно
const appEl = document.getElementById('catalog-app');
if (!appEl) throw new Error('#catalog-app not found');

const sectionId  = Number(appEl.dataset['sectionId']);
const iblockId   = Number(appEl.dataset['iblockId']);
const rawFilter  = appEl.dataset['initialFilter'] ?? '{}';
const initFilter = JSON.parse(rawFilter) as FilterState;

Как Vite ускоряет сборку TypeScript-фронтенда?

Для многомодульных проектов используем Vite — он даёт быструю сборку и разделение точек входа.

// vite.config.ts
import { defineConfig } from 'vite';

export default defineConfig({
    root:  'src',
    build: {
        outDir:          '../dist',
        emptyOutDir:     true,
        rollupOptions: {
            input: {
                main:    'src/main.ts',
                catalog: 'src/pages/catalog.ts',
                cart:    'src/pages/cart.ts',
            },
        },
    },
    resolve: {
        alias: { '@': '/src' },
    },
});

Отдельные entrypoint для каждого раздела сайта — только нужный JavaScript загружается на странице, что улучшает скорость загрузки.

Реальный кейс: каталог на 100 000 товаров

Наш клиент — интернет-магазин с каталогом на 100 000 позиций. Продукт: динамические фильтры, корзина с множеством опций, интеграция с 1С через CommerceML. Исходный код на ванильном JS страдал от ошибок типов при обмене с 1С. Мы провели аудит, спроектировали типы для всех сущностей и мигрировали фронтенд на TypeScript за три недели. Результат: количество ошибок в корзине снизилось на 60%, время загрузки фильтров — на 30%. Клиент получил гарантию стабильности на следующие два года, а экономия на багфиксах составила значительную сумму за первый год.

Что входит в нашу работу по разработке TypeScript-фронтенда

  • Аудит текущей архитектуры: выявление проблем в JS-коде, оценка объёма миграции.
  • Настройка TypeScript + сборщик (Vite/Webpack) с учётом окружения Битрикс.
  • Создание типов для всех точек интеграции с PHP (инфоблоки, REST, компоненты).
  • Разработка новых компонентов (каталог, корзина, фильтр, личный кабинет) с полной типизацией.
  • Миграция существующего кода с ванильного JS на TypeScript с сохранением функциональности.
  • Документация по архитектуре и описание типов.
  • Тестирование и отладка в продакшне с гарантией стабильности.

Ориентировочные сроки

Этап Сроки
Аудит и проектирование архитектуры 1–2 дня
Настройка инфраструктуры TypeScript + Vite 1 день
Разработка компонентов каталога (фильтр, список, карточка) 3–5 дней
Разработка корзины и мини-корзины в шапке 2–3 дня
Миграция существующего JS-кода (зависит от объёма) 2–5 дней
Тестирование и деплой 1–2 дня

Точные сроки и стоимость рассчитываются индивидуально после знакомства с проектом. Закажите аудит вашего проекта — мы проанализируем ваш код и предложим оптимальное решение. Получите консультацию, чтобы понять, как TypeScript сократит ваши издержки на поддержку фронтенда.

Почему вёрстка сайтов на 1С-Битрикс требует профессионализма?

Открываете template.php у предыдущего подрядчика — а там SQL-запросы, бизнес-логика и inline-стили в одном файле. На каждом втором проекте, который берём на поддержку, код шаблонов выглядит как свалка: кэш не работает, добавить новую фичу — переписывай всё. Средняя стоимость исправления такой вёрстки сайтов — 15 000–30 000 рублей только на отладку, а потерянная выручка из-за сломанной корзины в пик сезона может уходить в миллионы. Наша команда с 10-летним опытом строго разделяет: логика — в result_modifier.php или component_epilog.php, представление — в template.php. Никакого CIBlockElement::GetList в шаблоне. Это сокращает время правок на 30–40% и исключает типовые ошибки, которые ломают кэш. Аналогичную проблему исправляли клиенту, который месяц не мог обновить блок «Акции» — после настройки тегированного кэша правки вставали за минуту, а не за день.

Как правильно организовать шаблоны компонентов?

Кастомный шаблон — это не один файл, а структура из пяти-шести файлов:

  • template.php — только HTML и вывод $arResult
  • result_modifier.php — подготовка данных, дополнительные выборки
  • component_epilog.php — код после кэширования (счётчики, динамика)
  • style.css и script.js — подключаются через Asset::getInstance()->addCss() и addJs() (не через <link> — иначе ломается объединение)
  • .parameters.php — параметры визуального редактора

Пример структуры для каталога:

local/templates/your_template/components/bitrix/catalog.section/.default/
├── template.php
├── result_modifier.php
├── component_epilog.php
├── style.css
├── script.js
└── .parameters.php

Типовые шаблоны, которые верстаем под ключ:

Компонент Что делаем
catalog.section и catalog.element Переключение вида (плитка/список/таблица), lazy load для изображений, srcset для ретины
sale.basket.basket AJAX-обновление без перезагрузки, мини-корзина через sale.basket.basket.line
menu Мегаменю с кэшированием по разделам, отложенная загрузка подменю
search.title Автоподсказки с дебаунсом 300 мс, превью товаров в дропдауне
breadcrumb Микроразметка BreadcrumbList по Schema.org

Кэширование: почему оно ломается и как чиним?

Компонентное кэширование в Битрикс ломается одной ошибкой: вывели имя пользователя внутри кэшированного каталога — все видят одно имя. Решение — component_epilog.php для динамических вставок.

Tagged cache ($this->setResultCacheKeys, CIBlock::clearIblockTagCache) настраиваем обязательно. Изменили товар — очищается кэш только этого товара, а не всего раздела. На проекте с 50 000 товаров это даёт прирост скорости на 40% по сравнению с полным сбросом.

Реальный кейс. Клиент жаловался — на странице каталога у всех одна корзина. Оказалось, предыдущий разработчик вывел $_SESSION['BASKET'] внутри template.php компонента catalog.section. Компонент кэшировался на час — корзина застыла. Перенесли вывод в component_epilog.php, настроили тегированный кэш на sale.basket.basket.line. Страница не потеряла в скорости, корзина стала актуальной. Ущерб от неработающей корзины в пик сезона мог составлять миллионы, а цена исправления — в пределах 15 000 рублей. Другой клиент потерял 200 000 рублей за неделю из-за некорректного кэша формы заказа — мы вернули работоспособность за два дня.

Официальная документация Битрикс рекомендует использовать component_epilog.php для динамических вставок — подробнее в руководстве.

CSS-подходы: BEM, Tailwind или гибрид?

Для больших проектов (30+ шаблонов) используем BEM — .product-card__price, .product-card--featured. Стили изолированы, конфликтов нет. Подробнее о BEM. В Битрикс обёртки с классами bx-component не трогаем — оборачиваем свой BEM-блок внутри.

Для типовых задач (лендинги, админки) берём Tailwind 3+ с PurgeCSS — итоговый CSS 10–30 КБ вместо сотен. Дизайн-токены в tailwind.config.js фиксируют цвета, шрифты, отступы в одном месте.

На большинстве проектов применяем гибрид: BEM для структурных компонентов (каталог, карточка, чекаут), Tailwind для утилитарных вещей (отступы, flex-раскладки). Границу оговариваем с командой заранее.

Как мы достигаем Core Web Vitals?

Critical CSS — выделяем стили первого экрана через пакет critical, инлайним в <head>. Остальное грузится асинхронно через media="print" onload="this.media='all'". LCP на мобильных сокращается на 1–1.5 секунды.

Изображения — главный тормоз. Используем <picture> с WebP и JPEG-фолбэком. loading="lazy" для всего ниже первого экрана. width и height явно прописаны — CLS = 0. Обработчик в urlrewrite.php генерирует WebP на лету.

Минификация и сжатие. CSS и JS через Vite или встроенное объединение Битрикс. Brotli на nginx (brotli_comp_level 6) — на 15–20% эффективнее gzip. Кэширование статики: expires 1y + версионирование через query string.

Хотите получить подобные показатели? Свяжитесь с нами — сделаем аудит вашего проекта и предложим конкретные шаги.

Что входит в услугу вёрстки сайтов на 1С-Битрикс?

После заказа вёрстки шаблона или адаптации готового решения передаём:

  • Исходники шаблонов компонентов с разделением на template.php, result_modifier.php, epilog
  • CSS и JS, подключённые через Asset — без инлайн-стилей
  • Настроенное кэширование с тегами
  • Документацию по структуре и параметрам
  • Доступ к Git-репозиторию с историей изменений
  • Обучение вашего разработчика: как править шаблон без потери обновляемости

Гарантируем соответствие Core Web Vitals и кроссбраузерность. Закрепляем инженера с опытом 10+ лет — получите консультацию по вашему проекту до начала работ.

Процесс работы:

  1. Анализ макетов и текущего проекта — выявляем компоненты для переработки
  2. Проектирование структуры — разбиваем страницу на BEM-блоки
  3. Реализация — верстаем шаблоны по схеме: template, result_modifier, epilog, CSS, JS
  4. Тестирование — проверяем кэш, адаптивность, Core Web Vitals, кроссбраузерность
  5. Деплой — стейджинг, приёмка, продакшен

На каждом этапе вы получаете промежуточный результат и можете внести правки. Свяжитесь с нами — оценим проект за 1–2 дня после получения макетов.

Сроки

Объём работ Срок
Лендинг (5–7 экранов) 3–5 дней
Корпоративный сайт (15–20 уникальных страниц) 2–4 недели
Интернет-магазин (30+ шаблонов компонентов) 4–8 недель
Кастомизация готового решения Маркетплейса 1–3 недели
Редизайн существующего проекта 3–6 недель

После анализа даём разбивку по компонентам — что переиспользуется, что верстается с нуля. Закажите предварительную консультацию — посчитаем сроки и бюджет индивидуально.