MiniShop3 особенности и отличия от miniShop2

Всем привет, друзья. Давненько я ничего не писал про MiniShop3, но это совсем не означает, что ничего не происходит. Работа над проектом идет. Еженедельно я стараюсь тратить один свой выходной на разработку компонента и работы уже близятся к той точке, когда можно выпускать релиз.



Сегодня я хочу еще раз показать и рассказать в чем разница между двумя компонентами. Мы оставим за скобками то, что они выпущены для разных платформ, которые достаточно сильно отличаются и не особо между собой совместимы.

1. Хранение корзины и информации о заказе на стадии оформления.

MiniShop2 — из коробки хранит информацию в сессиях. С версии 3.0 есть экспериментальная возможность хранения данных в базе данных, что дало возможность обращаться к корзине из разных устройств, организовывать ссылку на корзину, а управляющему видеть брошенные корзины, и проводить работу над ошибками.

MiniShop3 — из коробки хранит данные сразу в базе данных. Никаких сессий. Механизм хранения, обмена данными оптимизирован по сравнению с MS2.

2. Опознавание владельца корзины и заказа.

MniShop2 — куки для восстановления сессии. В режиме хранения «База данных» сочетание данных session_Id и user_id.

Работа с куками сложна и ненадежна. Не каждый разработчик сможет корректно восстановить сессию, при использовании RESTfull API. Постоянно приходится изобретать велосипеды при работе с удаленными запросами из мобильного приложения, поддомена или Localhost. Кроме того все идет к тому, что кроссдоменные куки запретят в хроме из-за их ненадежности.

MiniShop3 — внедрен механизм токенов. Каждый покупатель при первом посещении получает токен, к которому привязаны корзина и заказ. Все запросы обязаны быть подписаны токеном в заголовке запроса. тут все просто — прислал токен — получил свою корзину. И не важно откуда ты обращаешься, с сайта, из поддомена, из приложения или localhost. Актуальные данные всегда под рукой. Нет привязки к устройству.

3. Отрисовка корзины и миникорзина

MiniShop2 — после обновления корзины, удаления товара и т.п. нужно перезагрузить страницу, либо сочинять собственную логику отрисовки корзины заново.
Стандартные ответы сервера возвращают только общие данные, которые можно вставить в блок Total

MiniShop3 — из коробки реализован механизм серверного рендера корзины. Используйте хоть десять сниппетов корзины на странице. Они все будут обновляться и перерисовываться на лету. Каждый со своими чанками и другими параметрами естественно. Также предусмотрен механизм возврата только сырых данных, для отрисовки корзины на VUE, к примеру.

Сниппет мини-корзины больше не нужен. Просто вызывайте две разные корзины со своей версткой.

4. Изменение опций внутри корзины

Minishop2 — невозможно в принципе.

MiniShop3 — Выполнено. Предыдущий пункт — дал возможность реализовать и такую возможность. Выводите в корзине список доступных опций. Меняйте их, и корзина на лету пересчитается. Если ваш выбор опций совпадает с уже существующим сочетанием — то строки суммируются и объединятся.

5. Новая сущность — msCustomer (покупатель)

Minishop2 — Отсутствует.

MiniShop3 — добавлено. Новая логика дает нам возможность отказаться от обязательного создания системного пользователя MODX с частой проблемой генерации Email. Не на каждом проекте предусмотрена регистрация, авторизация с особыми правами и т.п. Идея сделать такую возможность опциональной.

Будем хранить данные о покупателе в сокращенном формате. К примеру только имя и телефон.
Появился новый сниппет msCustomer, для вывода формы и сохранения данных Покупателя.

В добавок к Покупателю, заводим еще одну новую сущность. msCustomerAddress (Адрес покупателя).
Это дает нам возможность сохранять все вводимые адреса Покупателя и при последующих заказах просто выбирать из списка нужный.

5. Новые правила валидации

Minishop2 — валидация полей заказа происходит по «вшитым» в код правилам.
Не всех устраивает то, как валидируется телефон (иногда не хватает символов).
Не всех устраивают правила валидации имени. К примеру там обязательно первая буква меняется на заглавную. Это не всегда удобно.
Для переопределения необходимо переписывать класс заказа.

MiniShop3 — я выбросил всю логику валидации, и внедрил готовую библиотеку похожую на ту, что используется в Laravel

Теперь правила валидации будут указываться разработчиком прямо в вызове сниппета, по примеру FormIT, что дает возможность не лезть в PHP

Пример сниппета (валидация предусмотрена как в msCustomer, так и в msOrder)

{'!msCustomer'|snippet : [
    'tpl' => '@FILE chunks/demo/customer.tpl',
    'validationRules' => [
        'first_name' => 'required|min:2',
        'last_name' => 'required|min:3',
        'email' => 'required|email',
        'phone' => 'required|min:10'
    ]
]}

Пока на этом все.

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

Как видите изменений очень много (это я еще не писал об отличиях двух платформ, о технологических отличиях версии PHP и других мелочах). Меня много чего не устраивало в работе miniShop2 и проще было сделать все с нуля, а не выбрасывать из старого компонента.

Когда релиз

У меня не так много времени на работу. Никто ведь не отменял необходимости коммерческой работы. Я стараюсь выделять один день в неделю и по ощущениям мне осталось еще 4-6 недель до завершения работ.

Важно понимать, что «завершение работ» еще не подразумевает коммерческого релиза для всех. Я изготавливаю Альфа-версию, цель которой показать концепт-идею проекта. Разработчики компонентов смогут изучить проект, пощупать его, прикинуть как подогнать под него свои существующие компоненты и как реализовать новые идеи.

Опытные участники сообщества смогут приступить к тестированию и поиску багов. Ну а я займусь документацией и решением найденных проблем. В лучшем случае после 6 месяцев со дня альфа-релиза можно будет пилить какие-то более менее стабильные проекты. Там может и базовые компоненты подтянутся.

Чем помочь

В первую очередь меня конечно же интересует финансовая помощь. Желающим помочь — все реквизиты есть на отдельной странице modx.pro/about

Всегда приятно, когда работа оплачивается.
На данный момент помощь именно разработчиков мне не нужна, хотя нужно признать, что наши топовые разработчики помощь предлагают почти все. По мере необходимости я задаю вопросы и выношу спорные моменты на обсуждение в нашем закрытом чате контрибьютеров.

После альфа-релиза я составлю подробный план тестирования, выложу его здесь и мы сможем начать собирать первые данные о работе проекта.