Использование Битрикс+React презентация

А зачем?
Битрикс + React?

Точка отсчета
Аналитика
Дизайн
Верстка
Разработка
Тестирование
Эксплуатация

4
3
5
В верстке приходится реализовывать много логики
“Разработка” в среднем на половину состоит из “натягивания” верстки
Интерактивные блоки приходится делать дважды: на сервере и на клиенте
В верстке куча копипаста и никакого DRY (БЭМ как полумера)
Куча избыточного кода и тормозов при отрисовке фронтенда
2
1
Есть проблемы

Умный фильтр
Корзина сейчас
3326 строк JS-кода
+ mustache.js
+ полное дублирование в PHP
Оформление заказа
Примеры из жизни
Корзина (JS) полгода назад

Избыточные JS-плагины,
неиспользуемые модули BX и
излишние манипуляции с DOM
все равно сделают Ваш сайт
медленным
И даже если вы все клево делали

Шаблонизация
на клиенте
React, Angular, Vue

Почему
React

Все плюсы клиентской шаблонизации
Полная независимость клиента и сервера (от сервера нужно только API)
SEO по-умолчанию
Разделение кода и загрузка только необходимого
Максимальное ускорение всего фронтенда и даже Critical CSS
SPA
SSR
Нужен выделенный сервер
Весь роутинг “зашивается” во фронт
Крайне высокая трудоемкость
Полное отсутствие SEO
Скорость больше чем у SSR, но сильно меньше чем у классических подходов
Отлично подходит для порталов “с авторизацией” (Битрикс24)

Личный кабинет, пошаговое оформление заказа, пр. разделы которые не нужны для SEO
Удобно для постепенного рефакторинга и перевода проект на новые рельсы
Можно использовать React точечно

Расширение PHP v8js ( habr.com/ru/post/421531/ )
Более современное решение - NextJS
2 варианта для SSR

API based
development

Взаимодействие
back-end + front-end
специалистов
API BASED DEVELOPMENT

1
Раздельный
Передача верстки, раздельные репозитории,
натягивание верстки беком
2
Алиса в стране чудес
Front дружится с чужеродной ему средой
3
API Based / Front-end based
3 основных варианта
Способ взаимодействия API

Новые эмоции
и впечатления
от работы с сайтами
какой-то скриншот, график,
иллюстрация, картинка,
схема
Раздельная работа

- Бекендер занимается шаблонами,
а не программированием
- Коллизии при нтеграции
- Как развивать фронт при поддержке?
Раздельная работа
- Бекендер должен неплохо разбираться в стеке фронта

какой-то скриншот, график,
иллюстрация, картинка,
схема
2. “Алиса в стране чудес”

- Фронт погружается в чужеродную среду
- Сложно находить и обучать фронтов
2. “Алиса в стране чудес”
+ Общие трудозатраты меньше
+ Бекендер по минимуму работает с шаблонами
- Размытие ответственности
+ Фронт органично разрабатывается в платформе, учитывается производительность, нарезка на компоненты
- Сложнее параллелить
+ Органичное развитие проекта

3. Api/Front based

4
3
Все взаимодействие строится только на API
SPA: роутинг на клиенте
Все API тщательно документируются
За приложение отвечает фронт-енд,
объем работы фронта растет
2
1
3. Api/Front based: основы

3
Четкое разделение ответственности
Бекенд не трогает шаблоны. Только логика
Бекенд может быть переиспользован для других бизнес задач проекта
4
Бекенд проще тестируется
2
1
ПЛЮСЫ +
Легче параллелить работу
Фронт не работает в чужеродной среде
5
6

Нужно писать документацию, накладные расходы
Рост сложности приложения со стороны фронт-енд
2
1
МИНУСЫ +

3
Swagger (Open Api)
RAML
Api platform
2
1
Системы документации

3
REST
fullREST
GraphQL
2
1
Протоколы

3
Костыли
Костыли
Костыли
2
1
Как в Bitrix писать API

Как в Bitrix писать API

Способ “Костыли”: ajax.php
Вызов API
echo json_encode()
Нужен еще метод? Хм…
ajax2.php !

3
Каждый второй крупный партнер придумал свой
В разной степени адекватности
webpractik.api - наш костыль, можно посмотреть на github. Гордится там нечем, но лучше чем предыдущая стадия =)
2
1
Собственный роутер

Bitrix controllers

+ Нативные!
+ Удобные полноценные контроллеры со своими фишками
+ Тайпхинтинг и приведение типов на уровне параметров
Bitrix controllers
+ Нативная JS обертка для работы с “роутером”
- Отсутствие REST friendly роутера
- Как следствие - невозможность задокументировать в виде OpenApi/Swagger

+ Нативные!
+ Удобные полноценные контроллеры со своими фишками
+ Тайпхинтинг и приведение типов на уровне параметров
Bitrix controllers
+ Нативная JS обертка для работы с “роутером”
- Отсутствие REST friendly роутера
- Как следствие - невозможность задокументировать в виде OpenApi/Swagger

FW integration

+ Легко настраивается
+ Удобный и проверенный годами инструмент
+ API Bitrix !!
FW integration
+ DI, PSR стандарты
- Отсутствие REST friendly роутера
- Swagger из коробки

+ htaccess: выделяем область /api/
+ Направляем в подпапку с laravel
FW intergration: how to
+ подключаем middleware c Bitrix
Настраивается за 15 минут.

Содержат весь нужный код и точно работают
Представьте, сколько Вы будете писать REST API для “ленты новостей”...
А для корзины?
Содержат кеширование
А вот Вы/мы когда будем делать REST API с нуля дойдем до него в последнюю очередь
Дружат с SEO-свойствами
Вычисляемые мета-свойства инфоблоков, title и description через API
Имеют механизмы кастомизации и расширения
result_modifier.php
copy & paste
Компоненты
Способ от ИНТЕРВОЛГИ

1
Инфраструктура
Базируется на стандартном модуле rest
Можно “запускать” любые некомплексные компоненты
2
Логика
При вызове компонента пропускается template.php.
Кешируются и отдаются $arParams и $arResult
3
Песочницы
Использует несколько “слоев” для слежения за компонентами:
SEO-свойства
редиректы/die
режим правки
Маленький модуль для запуска компонентов через REST
Пример: https://www.intervolga.ru/rest/search.title?q=сайты
Способ от ИНТЕРВОЛГИ

Спасибо!
Вопросы?

3
Почему React нужен сейчас и нужно забыть про Jquery
Проблемы деплоя: они есть?
Какими костылями пользуетесь вы?)
2
1
Темы для обсуждения