Комментарии 8
Я пошел другим путем: сделал на ReactJS транспайлер, который преобразует JSON в реакт-примитивы (типа div и пр.) и сложные компоненты типа FileShow. Формы сделаны на Питоне и хранятся на сервере в отдельных директориях. Обработчики форм (команды, скрытие, валидация) в подгружаемых чистых JS. Шесть проектов разного уровня сложности используют 1 JS размером около 300 кб. Количество СПА около 30. В качестве примера SPA, в которой можно открыть несколько SPA. Если в поле «Более поздние обращения, ответы» нажать ссылку, открывается связанный документ. Многооконное SPA :)
GitHub
cypress можно параллелить из коробки или через sorry-cypress
Спасибо за перевод!
Подобный путь проходит большинство компаний с крупными реакт-приложениями. В статье, на мой взгляд, примерно середина этого пути "от первого прототипа до грамотно спроектированной системы". Чтобы комментарий не был пустословным, попробую предсказать дальнейший путь разработчиков в том проекте.
Как исходный уровень:
- есть достаточно структурированная кодовая база
- единообразие стиля написания кода и некоторых принципов (наименование, запрет использования определенных элементов, реэкспорт), наверняка внедрен и Prettier
- пишутся юнит- и интеграционные тесты
- есть страница с визуализацией компонентов и примерами использования (Storybook) без выделения в отдельный репозиторий (что намного более удобно, если не нужно ее использовать в совсем других проектах)
- есть типы (с линтингом ESLint, что более современно)
- организована двойная проверка кода — на гит хуки и в CI/CD
- код группируется по модулям
Пространства для улучшения:
- к тестовым прогонам можно прикрутить систему наподобие Allure
- можно разделить тесты на части, чтобы не прогонять полные регрессы на пуш в каждую ветку, оставив полные только для релизных веток или ручного запуска
- стек redux+saga чрезмерно многословен и запутан, в будущем явно разработчики поймут, что редюсеры, константы, селекторы, контейнеры, пробросы многочисленных импортов через пропсы, вручную написанные SCU (если не все на селекторах и каждый компонент контеризируется, что, наверное, еще хуже) намного более эффективно было бы заменить на мутабельные реактивные структуры
- react-router, вполне возможно, будет заменен на другое решение. Эта библиотека меняет подходы от версии к версии и делает код несовместимым, а в последних версиях работа с конфигами практически не поддерживается, что приводит к вынужденному разбрасыванию роутов по различным файлам. Недостатки очевидны, разбиение на асинхронные чанки, поддержка и документирование осложнены (из конфига можно ее генерировать автоматически)
- для локализации понадобится система автоматического создания id для сообщений + сбор всех констант в отдельный файл при сборке для отправки в систему локализации и независимого обновления текстов на сайте, без трат времени разработчика и изменения кода в гите
- все, про что рассказывается в статье, нужно будет поместить в техническую базу знаний, так как количество соглашений и условностей уже стало большим, и обучить новых разработчиков будет не так просто лишь путем менторинга
- вполне возможно, что от такого количества юнит-тестов ребята откажутся, оставив их только для утилит, так как интеграционные намного лучше справляются с обеспечением итогового качества, а shallow render реактовых компонентов пригождается в очень немногих случаях (например, когда один компонент может работать в десятках режимов)
- в CI/CD внедрят проверку производительности (скорость рендеринга и т.п.) для истории перфоманса и анализа возможных узких мест
- про CRA в начале было упомянуто, в дальнейшем про него не вижу рассуждений (как и ответов на вопросы из вступления), но если эта штука используется, то, безусловно, первым делом нужно будет переходить на кастомную сборку. Промышленная разработка и слишком высокоуровневые пакеты (особенно zero config) несовместимы по причине отсутствия гибкости, так что если ребята там присматриваются к Next.js, то лучше отказаться сразу от этой идеи.
Итогом этих нескольких шагов будет качественная смена состояния на более стабильное (примат интеграционных тестов над юнитами, анализ скорости), быстрее разрабатываемое (автоматика в локализации, отказ от неэффективных архитектур), быстрее выкладываемое (разделение тестов), проще изучаемое (техническая база знаний, автогенерация документации из конфигов, например — роутинга или апи). Потом, отталкиваясь от нового состояния этих организационных моментов и, зная специфику конкретного проекта, можно затронуть темы работы с гитом, связки различных систем (база знаний + дизайн-система + таск-трекер + гит-хранилище), работы с CDN, системы метрик… Много всего.
По выводу темы я бы не согласился с автором, сказавшим "А самое важное — стремитесь к минимализму". По моему опыту главное — это удобство, которое подразумевает довольно большую автоматизацию.
стек redux+saga чрезмерно многословен и запутан, в будущем явно разработчики поймут, что редюсеры, константы, селекторы, контейнеры, пробросы многочисленных импортов через пропсы, вручную написанные SCU (если не все на селекторах и каждый компонент контеризируется, что, наверное, еще хуже) намного более эффективно было бы заменить на мутабельные реактивные структурыМне кажется, уже не поймут. Уже свернули не туда и развивают дальше это направление. Если опытные разработчики повелись на красивую презентацию и распространили redux и прочее, то и более молодые, выращенные на этих redux-ах, будут считать такое нормальным подходом.
стек redux+saga чрезмерно многословен и запутан, в будущем явно разработчики поймут....
Mobx, Mobx-state-tree, Recoil, ну или хотя бы Redux-toolkit.
А вы бы что посоветовали?
react-router, вполне возможно, будет заменен на другое решение.
Согласен. Они, кстати, делают опять новую версию. Номер 6. Судя по комментариям, там-то мы и заживем. Но в 5 версии нет по-настоящему тесной интеграции с нативным History API, что в результате добавляет множество вопросов. То есть интеграция есть, но назвать ее полной — нельзя. И в планах у них нет.
Могу посоветовать роутер от nextjs/router. Понятное дело, использовать его отдельно не выйдет, да и какой смысл.
Промышленная разработка и слишком высокоуровневые пакеты (особенно zero config) несовместимы по причине отсутствия гибкости, так что если ребята там присматриваются к Next.js, то лучше отказаться сразу от этой идеи.
Не согласен про отказ от идеи использовать next.js.
Во-первых, у них цель — это настоящий суровый продакшен, во-вторых, у них взаимодействие с командой разработки Chrome, и они совместно делают движение в сторону повышения производительности, довольно успешно.
Я давно остановился на observable (в данном случае mobx), для SPA ключевой момент — синхронизация js-состояния (стор) и DOM (компоненты с жизненным циклом). Если у компонента есть доступ к любым свойствам и методам хранилища, а ререндер происходит только при изменении использованных при прошлом рендере свойств, то такая система становится идеальной по удобству и перфомансу. При добавлении любых дополнительных прослоек — ручного проброса свойств и методов (коннект редакса), вручную написанных SCU, вызова методов через диспетчер, маппинга изменений в хранилище исходя из констант (типов экшенов), отсутствие прямого доступа к нескольким подсторам, иммутабельность и т.п., и удобство разработки, и скорость приложения ухудшаются. Так что тут минимализм вполне оправдан)
У реакт-роутера много недостатков, причем легко какой-либо функционал не внедрить. Надо блокировать переход на роут по каким-то условиям? Ставь версию, в которой есть Prompt. Нужно задавать роуты конфигом, а не свичом в компонентах? Ставь соответствующую версию. Выполнять действия перед загрузкой страницы и после ухода? Тоже подбирай из многообразия версий. Куда проще этой возни написать свой роутер, весь этот функционал займет не так уж много строк кода, включая синхронизацию с URL, безопасный парсинг, анимации переходов между страницами, промисные цепочки переходов.
Даже и не знаю, чем может быть нужен next.js энтерпрайзу, все что он умеет, несложно сделать и так, только более гибко и по соответствующим стандартам. Может быть, кому-то и будет проще сделать прототип приложения на нем, но впоследствии, как с любым комплексным сложно кастомизируемым инструментом, будет больше возни, чем профита.
А думали о разделении по каталогам на верхних уровнях не по функциональному принципу (components, reducers, constants, ..), а по бизнес-задачам (user, product, cart,...) или?
Хотел тоже самое написать.
Разбивать проект вглубь по бизнес логике ( я называю их модулями) намного удобнее, чем вширь по типу файлов.
Сейчас у вас скорее всего папки экшенов, редюсеров, компонентов содержат десятки папок и при работе с одной страницей их всех нужно держать открытыми, бегая по всему проекту.
Если разбить проект на модули, которые содержат свой редюсер, экшен, селектор, хуки, компонент, стили, картинки и т.п., то вы как уже было сказано видите всё в одной папке, а так же можете спокойно настроить ленивую подгрузку захватив это всё разом, перенести этот модуль из проекта в проект или клонировать и изменять.
А если учесть, что модули могут содержать другие модули, то получается очень красивая древовидная структура.
Организация разработки крупномасштабных React-приложений