Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 26
Перестал читать когда сказали, что в yarn.lock нет смысла
На всякий случай раскрою тему:
1. даже если зафиксировать топ левел зависимости то ИХ зависимости будут ставиться согласно ИХ package.json (а там как правило крышки) — то есть всё дерево зависимостей зафиксировано не будет.
2. lock- фаилы увеличивают скорость установки зависимостей, что важно для CI (например
1. даже если зафиксировать топ левел зависимости то ИХ зависимости будут ставиться согласно ИХ package.json (а там как правило крышки) — то есть всё дерево зависимостей зафиксировано не будет.
2. lock- фаилы увеличивают скорость установки зависимостей, что важно для CI (например
npm ci работает только на основе package-lock.json
Верно, глубокие зависимости без lock-файла не будут зафиксированы. По всей видимости я сам себе противоречу в статье — выступаю за стабильные зависимости без ^, при этом допускаю возможность поломки из-за глубоких зависимостей.
Проблема, которую я решал — чтобы зависимости, указанные с помощью «file:./webpack-custom» обновлялись, так как с lock-файлом при изменении их package.json они не обновляются. Выходом вижу использовать yarn install --force. Возможно есть другие варианты?
Проблема, которую я решал — чтобы зависимости, указанные с помощью «file:./webpack-custom» обновлялись, так как с lock-файлом при изменении их package.json они не обновляются. Выходом вижу использовать yarn install --force. Возможно есть другие варианты?
Это же просто очередной бойлерплейт, причем тут архитектура?
При проработке названия искал слово, которым можно емко объединить сразу много сфер — контроль качества и форматирования кода, сборку, оптимизацию, работу со стилями, метод организации файлов, создание связки store+view, локализацию, практический обзор работы с React Hooks, принципы работы с АПИ, проектирование роутинга, конечное тестирование. Можно это было бы назвать «Основа для полноценного SPA-приложения», но тоже можно найти недостатки.
Так как «архитектура ПО» — размытое понятие, у которого сотни определений с разным охватом тем, можно взять например такое от Екатерины Головановой: «это процесс превращения таких характеристик программного обеспечения, как: гибкость, масштабируемость, возможность реализации, многократность использования и безопасность — в структурированное решение, которое соответствует как техническим, так и бизнес требованиям». По большей части подходит, на мой взгляд.
Понимаю, что тем, кто хотел увидеть в статье архитектуру «в узком смысле» — как «выбор структурных элементов, интерфейсов и их поведения в рамках системы» — здесь информации не много, так что для них это выглядит кликбейтом.
Boilerplate — «шаблонный код, который должен быть написан во многих местах практически без изменений», в статье встречается только в виде
и параметров вроде «name», «version» в *.json файлах. А как тогда назвать все остальное? Архитектура вроде как подходит
Так как «архитектура ПО» — размытое понятие, у которого сотни определений с разным охватом тем, можно взять например такое от Екатерины Головановой: «это процесс превращения таких характеристик программного обеспечения, как: гибкость, масштабируемость, возможность реализации, многократность использования и безопасность — в структурированное решение, которое соответствует как техническим, так и бизнес требованиям». По большей части подходит, на мой взгляд.
Понимаю, что тем, кто хотел увидеть в статье архитектуру «в узком смысле» — как «выбор структурных элементов, интерфейсов и их поведения в рамках системы» — здесь информации не много, так что для них это выглядит кликбейтом.
Boilerplate — «шаблонный код, который должен быть написан во многих местах практически без изменений», в статье встречается только в виде
/**
* @param rootStore {RootStore}
*/
constructor(rootStore) {
this.rootStore = rootStore;
}
и параметров вроде «name», «version» в *.json файлах. А как тогда назвать все остальное? Архитектура вроде как подходит
>шаблонный код, который должен быть написан во многих местах практически без изменений
Так и получается — куча всего этого кода берется каждый раз заново для старта проекта.
(для примера можно загуглить react redux boilerplate)
Еще альтернативные названия это starter kit, seed.
Под архитектурой я понимаю разбиение на модули проекта и границы между ними, без выбора конкретных библиотек, но это субъективное мнение.
Так и получается — куча всего этого кода берется каждый раз заново для старта проекта.
(для примера можно загуглить react redux boilerplate)
Еще альтернативные названия это starter kit, seed.
Под архитектурой я понимаю разбиение на модули проекта и границы между ними, без выбора конкретных библиотек, но это субъективное мнение.
- Webpack+babel — а чем результат отличается от Create React App?
- Локализация — в чем отличие от react-intl? Результат получился очень похожим с виду.
- Роутинг — в чем преимущество самодельного решения над react-router (возможно, в связке с mobx-react-router)?
Раньше использовал вышеуказанные библиотеки, но в большинстве проектов приходилось их клонировать и дорабатывать, либо использовать сложные конструкции, для соответствия тем принципам, которых я придерживаюсь при разработке.
react-intl, к примеру, работает через свой провайдер, требует в каждом сообщении передавать уникальный id (который, конечно, можно сгенерировать через _filename), не всегда подходит его шаблонизатор. Если можно сделать намного проще и удобней — то стараюсь избегать сторонних зависимостей.
react-router использовал 2-4 версии, каждый раз приходилось писать много лишнего кода, чтобы добиться тесной интеграции с приложением, вплоть до нескольких миддлвар на каждый onEnter / onLeave, а правами на просмотр управлять через Prompt… Работало хорошо, но код совсем не элегантный.
Create React App все же для небольших приложений, так как накладывает жесткие ограничения, в которые проект неминуемо упрется. Придется делать npm run eject и основательно перерабатывать конфиги (проходил, не удовольствие).
Уверен, что можно так обернуть готовые библиотеки, чтобы соответствовали всем предъявляемым требованиям — просто времени и усилий лично у меня займет больше, чем написать с чистого листа.
react-intl, к примеру, работает через свой провайдер, требует в каждом сообщении передавать уникальный id (который, конечно, можно сгенерировать через _filename), не всегда подходит его шаблонизатор. Если можно сделать намного проще и удобней — то стараюсь избегать сторонних зависимостей.
react-router использовал 2-4 версии, каждый раз приходилось писать много лишнего кода, чтобы добиться тесной интеграции с приложением, вплоть до нескольких миддлвар на каждый onEnter / onLeave, а правами на просмотр управлять через Prompt… Работало хорошо, но код совсем не элегантный.
Create React App все же для небольших приложений, так как накладывает жесткие ограничения, в которые проект неминуемо упрется. Придется делать npm run eject и основательно перерабатывать конфиги (проходил, не удовольствие).
Уверен, что можно так обернуть готовые библиотеки, чтобы соответствовали всем предъявляемым требованиям — просто времени и усилий лично у меня займет больше, чем написать с чистого листа.
Прочитал немного, глянул на ползунок страницы… Там только ТРЕТЬ от написанного, а программировать еще не начали… И это KISS? =) попахивает сарказмом… однако, особенно после прочитанной статьи «Вы не Google».
Большое спасибо за конфигурации и реальные примеры (устал от статей хелоу ворд) фронтэнд поражает своей сложностью…
Большое спасибо за конфигурации и реальные примеры (устал от статей хелоу ворд) фронтэнд поражает своей сложностью…
Исправил в апдейте на кроссплатформенный, только
\/ будет недостаточно, а [\\/] покроет оба написания слэшей. Папка dist коммитится для демо — так работают Github Pages, они показывают контент одной из папок в репозитории. Другие хеши в первоначальном варианте получились скорее всего потому, что скрин с ними я сделал до финальной версии кода — так что если бы и сам пересобрал, то были бы другие. С yarn.lock разобрался в апдейте, действительно было ошибкой не использовать его для основных зависимостей
Статью стоит переименовать в «Как я решал конкретную задачу с помощью React и MobX, и зачем-то написал в процессе пару велосипедов».
Помимо велосипедов, о которых уже написали в комментариях, не ясно, чем автору не угодила типизация. По мне, так это must have и стандарт для промышленной фронтенд разработки в 2019 году.
Помимо велосипедов, о которых уже написали в комментариях, не ясно, чем автору не угодила типизация. По мне, так это must have и стандарт для промышленной фронтенд разработки в 2019 году.
Типизация обязательно будет, просто не в его смену.
У меня скорее негативный опыт взаимодействия с TypeScript. Понимаю, что тема спорная, и зависит от принципов, которых придерживается сам разработчик. Знаю сильных специалистов, которым комфортно работать в стиле «тише едешь — дальше будешь», и проекты они выполняют с полной тщательной типизацией и за тройной, на мой взгляд, срок, при сравнимом качестве итогового продукта.
Видел проекты с типизацией и сотнями зарегистрированных багов по части фронтенда, в том числе касательно некорректных типов (т.к. разработчики полагались на типизацию, а не проверяли данные в рантайме, применяя стратегии отказоустойчивости). Также часто возникали ситуации, когда в репозиторий коммитился не проходящий сборку код — проблема встает остро, когда проект разбит на несколько репозиториев (например, на библиотеку компонентов, валидационные схемы).
Сам код, на мой взгляд, становится сложнее читаемым, в миддлварах и сложных функциях и декораторах приходится писать многотомные типы ценой дополнительных часов, не получая профита (автодополнение? JSDoc в помощь), а ввиду того, что работал в проектах, где важна скорость разработки, приходилось «скатываться» в any. Еще помню большие затраты времени на обучение корректному использованию типизации всех разработчиков. Для динамической типизации в ряде случаев приходилось использовать хаки со StackOverflow, также было несколько проблем касательно утечек памяти при сборке (watch-режим падал, какие бы лоадеры и ухищрения не пробовали, через 2-3 часа работы), увеличении времени на сборку, и баги, специфичные для Linux / Windows систем.
В итоге польза была катастрофически не совместима с затрачиваемыми усилиями. Эти минусы касаются именно SPA-разработки. Для отдельных библиотек (к примеру, для графиков) и онлайн-игр, думаю, типизация была бы очень кстати. А в разработке сайтов минимизирую количество багов тщательными интеграционными тестами и проверкой данных в рантайме.
Опыт работы с TypeScript — 6 месяцев. Итоговое впечатление — сырой продукт, не приносящий ощутимой пользы, при этом значительно увеличивающий время на разработку, при этом расхолаживая коллег, которые вместо заботы над реальным user experience начинают полагаться на «скомпилировалось — значит все будет работать».
Видел проекты с типизацией и сотнями зарегистрированных багов по части фронтенда, в том числе касательно некорректных типов (т.к. разработчики полагались на типизацию, а не проверяли данные в рантайме, применяя стратегии отказоустойчивости). Также часто возникали ситуации, когда в репозиторий коммитился не проходящий сборку код — проблема встает остро, когда проект разбит на несколько репозиториев (например, на библиотеку компонентов, валидационные схемы).
Сам код, на мой взгляд, становится сложнее читаемым, в миддлварах и сложных функциях и декораторах приходится писать многотомные типы ценой дополнительных часов, не получая профита (автодополнение? JSDoc в помощь), а ввиду того, что работал в проектах, где важна скорость разработки, приходилось «скатываться» в any. Еще помню большие затраты времени на обучение корректному использованию типизации всех разработчиков. Для динамической типизации в ряде случаев приходилось использовать хаки со StackOverflow, также было несколько проблем касательно утечек памяти при сборке (watch-режим падал, какие бы лоадеры и ухищрения не пробовали, через 2-3 часа работы), увеличении времени на сборку, и баги, специфичные для Linux / Windows систем.
В итоге польза была катастрофически не совместима с затрачиваемыми усилиями. Эти минусы касаются именно SPA-разработки. Для отдельных библиотек (к примеру, для графиков) и онлайн-игр, думаю, типизация была бы очень кстати. А в разработке сайтов минимизирую количество багов тщательными интеграционными тестами и проверкой данных в рантайме.
Опыт работы с TypeScript — 6 месяцев. Итоговое впечатление — сырой продукт, не приносящий ощутимой пользы, при этом значительно увеличивающий время на разработку, при этом расхолаживая коллег, которые вместо заботы над реальным user experience начинают полагаться на «скомпилировалось — значит все будет работать».
Достаточно было написать "мне не понравилось". Приведённые аргументы весьма притянуты, как по мне, но вступать в полемику не виду смысла, ибо тема раскрыта уже не раз. Мой опыт (пользуюсь TS с начала 16 года версии 1.6 с которой началась поддержка типизированного jsx) говорит об обратных выводах.
С тех пор много воды утекло и поменялось как в языке так и в тулчейне. И на текущей момент всё очень даже хорошо.
Я описал только малую часть проблем — каждый день несколько часов работы команды уходило на типизацию и борьбу с негативными эффектами. Разумеется, все можно победить — вопрос зачем? Пользу от типизации в SPA я до сих пор не увидел.
Ошибки в типах в рантайме только увеличились. Рефакторинг стал сложнее — в ES6 проекте 90% рефакторинга выполняется findAndReplace с помощью регулярок, с типизацией работа удваивается. Переменные как были с опечатками или не отражающие назначения, так и остались. В опенсорс-зависимостях очень часто выходят версии с некорректными типами, ломающими сборку, и приходится форкать и вручную исправлять. Перечислять минусы могу еще долго.
Я действительно хочу понять, что именно сподвигает некоторых людей топить за Typescript в SPA.
Ошибки в типах в рантайме только увеличились. Рефакторинг стал сложнее — в ES6 проекте 90% рефакторинга выполняется findAndReplace с помощью регулярок, с типизацией работа удваивается. Переменные как были с опечатками или не отражающие назначения, так и остались. В опенсорс-зависимостях очень часто выходят версии с некорректными типами, ломающими сборку, и приходится форкать и вручную исправлять. Перечислять минусы могу еще долго.
Я действительно хочу понять, что именно сподвигает некоторых людей топить за Typescript в SPA.
«Извращение», «все неправильно» и особенно «все уже поняли что всем нужна типизация», как модно было говорить в докладах на недавних конференциях, для меня не аргументы использовать эту технологию.
Если бы я знал о явных преимуществах и они стоили всех мучений и долгого обучения — как вы правильно заметили, за полгода команда довольно сильных специалистов не научилась «правильно работать со строгой типизацией», хотя в основном проблемы зависели не от команды, то можно было бы дальше возиться с этим и обильно осваивать бюджет компании. Но нет. Предпочитаю делать продуманные качественные продукты и приносить пользу, а не возиться с почти бесполезными инструментами, не двигающими к этой цели.
Я не говорю за всех разработчиков и за все проекты — как я писал выше, в отдельных библиотеках использование типизации скорее оправдано, а в сложных многосоставных системах вроде SPA явно негативный эффект — замедление разработки без видимых профитов. IMHO
Если бы я знал о явных преимуществах и они стоили всех мучений и долгого обучения — как вы правильно заметили, за полгода команда довольно сильных специалистов не научилась «правильно работать со строгой типизацией», хотя в основном проблемы зависели не от команды, то можно было бы дальше возиться с этим и обильно осваивать бюджет компании. Но нет. Предпочитаю делать продуманные качественные продукты и приносить пользу, а не возиться с почти бесполезными инструментами, не двигающими к этой цели.
Я не говорю за всех разработчиков и за все проекты — как я писал выше, в отдельных библиотеках использование типизации скорее оправдано, а в сложных многосоставных системах вроде SPA явно негативный эффект — замедление разработки без видимых профитов. IMHO
Отлично, что популяризируете связку React + Mobx, сам тоже на ней остановился — удобно тестируется, превосходно типизируется. Жаль, что в статье больше внимания уделено тулингу, чем архитектуре приложения. Например, не объяснено зачем во все сторы передавать корневой стор, это ведь типичный Service Locator, скрывающий реальные зависимости и усложняющий написание юнит тестов. Например, у меня RootStore выглядит так:
Такие сторы легко юнит-тестируются, по конструктору видно, что достаточно лишь замокать вызовы к API. По поводу роутера — если предлагаете писать вручную, то неплохо бы объяснить чего не хватает в существующих решениях, так как ваш роутер в использовании имеет много общего с mobx-state-router
class RootStore {
testEditorStore = new TestEditorStore(testApi);
testListStore = new TestListStore(testApi);
attemptStore = new AttemptStore(attemptApi, testApi);
routerStore = new RouterStore(this, routes);
}
Такие сторы легко юнит-тестируются, по конструктору видно, что достаточно лишь замокать вызовы к API. По поводу роутера — если предлагаете писать вручную, то неплохо бы объяснить чего не хватает в существующих решениях, так как ваш роутер в использовании имеет много общего с mobx-state-router
Корневой стор передается, чтобы MobX-сторы имели доступ друг к другу и могли напрямую получать данные друг от друга. Всегда будут методы, которые должны изменить сразу несколько сторов — это просто решение проблемы. Диспетчер как в Redux здесь будет скорее неэффективен, так как желательно единомоментно в одной транзакции менять все параметры. А вы как решаете эту задачу?
Чтобы продемонстрировать принципы, которыми руководствуюсь, полезней и понятней написать свою реализацию, хотя можно было бы и сделать на базе готового инструмента, основательно обработав напильником.
Чтобы продемонстрировать принципы, которыми руководствуюсь, полезней и понятней написать свою реализацию, хотя можно было бы и сделать на базе готового инструмента, основательно обработав напильником.
Сейчас пришла идея, что если потребуется изменить в одной транзакции сразу много сторов, можно это красиво сделать через реализованный в статье autorun. Таким образом, сторы потеряют тесную связь, что снизит сложность программы. Да, так всегда — по мере «выращивания» кода приходят идеи, как его улучшить. Сразу идеально спроектировать у меня никогда не получалось
Автору, безусловно, респект за труд, но мне кажется, заголовок статьи и ее содержание немного не соответствуют друг другу.
хотел перестать читать после фразы: типизация: не в мою смену.
но стало любопытно из-за демо. в итоге ясно одно — вся соль статьи это архитектура.
а в Angular она из коробки.
ИМХО, реакт разработчик с каждым новым проектом пытается
но стало любопытно из-за демо. в итоге ясно одно — вся соль статьи это архитектура.
а в Angular она из коробки.
ИМХО, реакт разработчик с каждым новым проектом пытается
сосредоточиться именно на архитектурепопутно написав приложение
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Архитектура SPA-приложения биржи в 2019 году