О, всплыла тема про боль. А кто как спустя годы приспособился к sale.order.ajax? Возьмём типичный процесс - прототипирование, дизайн, вёрстка. До этого момента битрикса нигде нет. Затем появляется разработчик и видит перед собой html, естественно никаких битриксовых классов и скриптов там и близко нет, да и сам внешний вид далёк от битриксового, форма часто открыта (никаких скрытых блоков на ней нет), профиль порой разбивается отдельно на доставку и отдельно на контакное лицо с раздельным выбором/редактированием (как на том же wildberries) и ещё множество всего. Начинается великая история переноса каждого битриксового класса, каждого битриксового идентификатора внутрь нового шаблона, а также выстраивание внутренней dom-иерархии согласно шаблону битрикса. Затем подключается order.ajax.js, внутри которого тоже расположена вёрстка (шаблонизатор? не, не слышали) и начинаем в нём эту вёрстку менять (время от времени попинывая верстака - мол убери флексбокс свой, order.ajax.js пихает вместо твоего праведного <ul> свои дивы с непонятным содержимым внутри и все твои свёрстанные флексбоксовые красивости рассыпаются из-за смены иерархии). Затем доработка order.ajax.js в плане логики (дополнительные проверки формы в наших новых блоках, вывод алертов ошибок в новой вёрстке и прочее). Также не забываем о внешних модулях с маркетплейса (например модули доставки), которые так и норовят залезть в твою форму через bx-soa- ... bx-delivery ... input и прочее в таком роде и где-то забудешь поставить битриксовый класс или сменишь иерархию - и прощай встраиваемая кнопка выбора ПВЗ. Затем наступает замечательный этап тестирования и за неделю (а может и больше времени уйти, в зависимости от нюансов) работы мы получаем форму заказа, которую хотел клиент. 40 часов умножаешь на час разработчика и видишь диву дивную, сколько денег сожрала одна форма только на программинг.
Вариант второй - говоришь клиенту, что есть форма заказа, она священна, трогать её нельзя и максимум что можем - поменять цвет фона, скрыть блоки и внести прочие косметические изменения. На практике такое канает только с покупными решениями по типу аспро. При уникальном дизайне же клиент отнекивается, прям нивкакую - типа что вы мне тут подсунули, мне такая форма не нужна.
Есть конечно варианты кардинальные, видим что состояние формы уходит на ajax.php и компонент возвращает нам обратно json, то есть можем шаблон выкинуть и сделать всё праведно к примеру на vue, но где гарантия того, что завтра при обновлении у клиента битрикса, этот json компонента не поменяется и форма заказа (основное действие, из-за которого весь сайт по сути и создавался) не развалится? Поразмыслив - а не вынести ли нам ещё и компонент в свою область? Окей, выносим, время идёт, добавляются новые фичи битрикса, часть методов в ядре становится deprecated, где-то меняются сами методы (например в D7), что приводит к поломкам и копируя компонент в новые проекты мы потихоньку уезжаем в прошлое.
Первым напрашивается готовое REST API (к примеру метод order.calculate), которое по состоянию формы (выбранным в данный момент пользователем значениям, идентификаторы которых должны быть в документации) будет возвращать готовый хорошо документированный неменяемый в рамках конкретной версии json. Также возможность расширения этого API, давая возможность разработчикам добавлять в json или менять в нём необходимые данные. Основной компонент формы оставить как есть, пускай и работает дальше, но будет альтернатива - взять тот же vue (избавившись наконец от BX), сделать шаблоны и таскать из проекта в проект, отдав верстаку возможность их смены. Вышли изменения - ставим версию 2.0, кто хочет - использует старую версию API. API создаёт и поддерживает сам битрикс, что снимает с каждого разработчика написание и поддержку своих велосипедов. Если открыть код компонента, то там для получения той же доставки - создаются отгрузки, определяется геолокация (которую временами приходится костылить через OnSaleComponentOrderProperties, если хочешь впихнуть свой город из cookie, а не по ip пользователя), все эти условия суммируются на получение доступных способов доставки, затем происходит расчёт и вся эта канитель выливается в сотни строк кода, просто чтобы получить образно говоря три значения. Пусть это всё будет скрыто в API.
Есть конечно ещё корзина (там смотрю mustache приделали) и смена доставки/оплаты на странице заказа, но здесь хотя бы с этой формой разобраться.
В общем интересует мнение коллег, кто как эту форму делает с нуля в своих проектах. Или по старинке - открываем sale.order.ajax.js, ящик пива и поехали? )
