Продолжаем путь к совершенству нашего приложения. Сегодня решим проблему каскадной передачи состояния в виде props-ов через всё дерево. Напишем тесты и введём понятие презентационных и контейнерных компонентов. И переведём код на передачу состояния через контекст React. А в следующем эпизоде попробуем это отрефакторить для избавления от копипасты.

Мы нашли удобный способ подключать компоненты к хранилищу, передаваемому через контекст, через connected-компоненты. Теперь мы можем обобщить этот процесс, создав универсальный настраиваемый коннектор. Заодно избавимся от перерендера целого приложения. Доработаем метод dispatch, чтобы он умел работать с асинхронными экшенами. В итоге получим более аккуратный код.

Вот мы и сделали приложение на React. Но загрузка лотов производится даже когда мы не выводим их на странице. Использование Redux порой может быть лишним. И загрузка данных из API может быть сложнее.

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

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

И после исследования работы React уже можем продолжить проект аукциона на Slim.

Мы это сделали! В честь завершения серии про исследование React публикуем пост с итогами в блоге

Возвращаемся к аукциону 👍🏼

За время наших похождений в мир React вышли новые Composer 2, Xdebug 3, Psalm 4, Cucumber 7 и PHP 8. Также обновились базовые Docker-образы Nginx, NodeJS и PostgreSQL.

Так что сейчас самое время перейти на свежий софт и в следующем эпизоде заняться полезной интеграцией PHPUnit, CodeSniffer и Psalm в новый PhpStorm. А потом (когда на него перейдут все пакеты) встретить PHP 8. Очень ждём :)

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

Для этого сегодня проведём интеграцию PHPUnit, CodeSniffer и Psalm прямо в PhpStorm. И заодно подключим плагины Psalm для упрощения описания типов для сервисов контейнера и для классов с тестами. Так разрабатывать будет интереснее.

Чем заниматься в новогоднюю ночь – дело фантазии каждого. Может кому-то нравится в это время деплоить...

Если под утро вам вдруг станет грустно, то можете провести это время с пользой и через Ansible поднять свой локальный кэширующий прокси-реестр DockerHub для своего Jenkins :)

Каникулы проведены с пользой. На них занялся уборкой:

Исправил опечатки в коде аукциона по issues. Доработал некоторые эпизоды: улучшил команду deploy в эпизоде о Jenkins, перешёл везде на вызов docker-compose build с флагом --pull, кое-где сократил длинные вступления и подведения итогов.

Видеоролики тоже исправлены и перезалиты.

Скринкастов на сайте уже стало много. Свои комментарии под ними искать не очень удобно.

Чтобы вы больше не теряли свою переписку с полезными вопросами и ответами в кабинете теперь есть ссылка "Мои комментарии":

https://deworker.pro/cabinet

А в ближайшем эпизоде напишем полноценную инфраструктуру Feature Toggles к фронтенду и бэкенду для более удобной разработки по принципам CI/CD.

Многие из вас интересовались, какая цветовая схема для PhpStorm используется в наших скринкастах. Тема сделана вручную специально для скринкастов. Делимся ей в нашем новогоднем дайджесте.

Новый мегаэпизод готов!

При рассмотрении философий CI/CD мы вместо Feature Branches говорили о подходе Trank Based Development для скрытой разработки новой функциональности в основной Git-ветке.

Сегодня это сделаем на практике. Добавим к проекту инфраструктуру полноценной работы с Feature Flags для фронтенда на ReactJS и бэкенда на PHP.

И при разработке компонента для бэкенда рассмотрим и применим принцип ISP из SOLID.

Если мы ведём разработку всего проекта в одном монорепозитории, то сталкиваемся с неудобством долгого запуска pipeline. При малейшей правке файлов фронтенда у нас запускаются линтеры и тесты для всего проекта, а не только для фронтенда.

Сегодня мы оптимизируем наш Pipeline в Jenkins так, чтобы он запускал проверки только для изменённого кода. Для этого научим его пользоваться командами git diff и docker-compose images для отслеживания изменений кода и софта. При этом рассмотрим нюансы, с которыми можно столкнуться при внедрении такой автоматизации.

В нашем коде мы активно используем контейнер внедрения зависимостей для работы с сервисами. Но мы с вами мало внимания уделяли практикам написания самих сервисов. Этому я решил посвятить следующую большую подробную статью своём блоге @elisdnru

Но перед этим нужно разобраться с определениями, которые мы будем там использовать. Чтобы потом было понятнее. Поэтому сегодня рассмотрим, что в нашем коде чем является с точки зрения ООП.

В личном блоге опубликовал импровизированный стрим на общеполезные темы:

Чем неудобен в разработке процедурный код. Какие сложности предметной области обнаруживаются при анализе бизнеса. Как использовать классы провайдеров для конфигурирования приложения и для организации гибкой модульности.

Репостить статьи и видео с сайта elisdn.ru здесь больше не буду. Для них рекомендую подписаться на канал @elisdnru. Там помимо стримов скоро выйдет вторая мега-статья про практики внедрения зависимостей.

А пока мы записываем и монтируем свежие видео для серии Slim & React про подключение маршрутизации и работу фронтенда с API в форме регистрации. Так что до встречи в следующих скринкастах 👍🏼

Продолжаем разработку проекта.

Чтобы было где размещать формы регистрации и входа нам понадобятся новые страницы.

Поэтому сегодня вынесем общий шаблон вёрстки, установим маршрутизатор и с помощью Feature Flag добавим страницу для формы регистрации.

А перед этим заодно доустановим линтеры для Jest-тестов и доработаем E2E-тесты для возможности работы с асинхронными страницами и добавления тестов до кода.

Осторожно, много кода и тестов :)

Сегодня сделали форму регистрации со страницей подтверждения. Организовали работу React с API. Добавили вывод доменных ошибок и ошибок валидации для полей. Отрефакторили код и вынесли клиент для работы с API. Сделали проксирование запросов с фронтенда на бэкенд. Добавили защиту от повторных кликов и вынесли компоненты для элементов формы для использования в других формах.

С фронтендом мы разобрались. Пора переходить к разработке API-бэкенда. Сегодня переведём API на PHP 8.0. Перейдём на сборку PHP-расширений в Dockerfile напрямую из исходников вместо использования PECL. Пропишем новые нативные типы. Также упростим PHPDoc-блоки за счёт перехода от Psalm-аннотаций на классические и за счёт удаления повторов.

Многие спрашивали, почему мы проверяем свой код только на соответствие PSR-12, но не следим за другими нюансами и не используем популярный подход final or abstract для написания классов.

Сегодня как раз это и сделаем. Перейдём на использование инструмента PHP CS Fixer, рассмотрим полезные для нас правила и интегрируем с PHPUnit и PhpStorm.

После формы регистрации осталось добавить вход в кабинет и восстановление пароля.

Для этого перед программированием нам нужно определиться, как мы будем осуществлять аутентификацию в приложении из JS-фронтенда и API.

Как раз сегодня рассмотрим практики аутентификации по токенам при работе с API и сравним классические подходы с использованием токенов в формате JWT.

И смоделируем по шагам процесс получения и обновления токенов по универсальной спецификации OAuth2, чтобы с нашим API могли работать сторонние клиенты.