Не могли бы привести пример предупреждений в консоли? У меня нету ни в одном проекте, как вызвать?
"Неявные подписки" - это отличная практика вынесения сложности за рамки основного кода. То есть работаешь по виду с обычными объектами, а на изменения определенных параметров, в том числе глубоко вложенных, можно еще и подписываться, это же мечта из 2000-х. Я тогда море ухищрений делал, чтобы добиться реактивного рендеринга, теперь же все очень просто.
Про стор, в котором все намешано - это конечно антипаттерн, но никто не заставляет его так организовывать. Особенно это касается экшенов (функций изменения стора), намного эффективнее их выносить, чтобы они имели доступ к разным сторам. Поэтому нельзя отнести это отнести в минусы инструмента, который делает объекты реактивными и дает полную свободу в реализации.
"В эффекторе же у вас есть только события, которые способны изменять стор" - ну и в Mobx есть функции-экшены, которые изменяют стор, только без необходимости иммутабельно писать как в редаксе (store, data) = > ({...store, items: store.items.map(item => ({...item, isViewed: data.id === item.id}))}) , разводя дубляж и значительно усложняя код, и заводя прослойку в виде событий, которые являются чистым бесполезным бойлерплейтом. Все, что нужно - вызвать функцию, она меняет нужный параметр в сторе, автоматически происходит эффективный перерендеринг.
Насчет "полегче" - аргумент, конечно, хороший, если измерения проводить в маленьких проектах, где размер библиотек намного превышает размер бизнес-логики, но уже в средних размер приложений с mobx за счет практически отсутствия бойлерплейта уже начинает выравниваться, в крупных - будет меньше.
У меня обычно в проектах разные интерфейсы для renderWait и renderEmpty, поэтому просто пишу get renderWait() { return <SomeMarkup /> } и в самом render() { if (isLoading) return this.renderWait; } . В целом тут только для очень специфических кейсов пригодится унификация и наследование, и если унифицировано - то лучше вынести на уровень выше, чтобы верхний компонент показывал соответствующую разметку, не раздувая нижние компоненты.
А разные типы одного компонента с общим функционалом сделал бы через class BranchWrapper{ render() { return Children.clone(this.props.children, { getChildNode: () => logic; }) } } . Так что варианты есть. Хотя это как раз React way, по которому не очень хочется идти, ООП довольно сильно усложняет восприятие, на мой взгляд. А еще лучше - через контекст, чтобы совсем отвязаться от пути Реакта - class SomeBranch { handleButtonClick = () => this.context.getNodes(this.props.branchId) }. Думаю, так проще, чем наследовать, но у каждого свой путь)
А где во фронте, если не секрет, вам пригодилось наследование? Мне лично - нигде, кроме как отнаследовать класс от реакта, чтобы появились методы жизненного цикла и в играх. В остальном никогда. Если нужна какая-то функция в нескольких компонентах то просто импортится из утилит и вызывается, если какая-то логика выборки переиспользуется - то делается геттер в хранилище.
Хуки вообще странный концепт, я с ними тоже не подружился. Ничего мне не нужно от того что они продают - а именно объединенный в один вызов useEffect маунт-размаунт и "переиспользуемость". Семантичные методы класса для жизненного цикла удобней и ssr поддерживают, а переиспользуемость легко и в классах реализуется. В остальном только проблемы от кода, превращающего в кашу из длинных грязных функций без явных слоев логики.
Все, что в статье приведено - это проблемы React way, то есть когда простой фреймворк обрастает концептами и фичами, которые намного эффективнее решались бы сторонними решениями. Но никто на самом деле не навязывает их, можно использовать только нужное, для меня это:
Оформление компонентов в классы
3 метода жизненного цикла - componentWillMount (для SSR+client), componentDidMount (только client) и componentWillUnmount. Я бы предпочел, чтобы они более семантично и короче назывались, но это не большая проблема
Доступ к context (некоему глобальному объекту) из любого компонента без дополнительных импортов
Грамотно сделанный HTML-in-JS шаблонизатор со скоупом функции и JS-in-HTML
(иногда) Рефы, чтобы не генерировать уникальные идентификаторы для определенных частей компонента
Для всего остального есть удобные реактивные решения, о которых все знают. И для подписки на изменения, и для ререндеринга только при изменении используемых параметров, и для кеширования в геттерах сложной логики, и для батчинга вносимых изменений. Если бы React скорцентрировался чисто на функционале выше и максимизировал перфоманс и размер исходя чисто из этих фич - я был бы счастлив. Но сейчас он дает простор и тем, кто хочет повозиться с хуками, с нереактивными пробросами пропсов, с иммутабельными изменениями через редюсеры, с невидимым вооруженному глазу состоянием внутри функции, с комбинированными в один вызов жизненными циклами, с асинхронными компонентами, разными системами стилизации - что на самом деле не такой уж большой минус, так как развивает экосистему, которая действительно стала огромной. Но заставлять все это пробовать и использовать - этого нет, можно обойтись минимумом, нужным конкретному разработчику, и дополнить решениями, которые он считает адекватными.
SWC кстати стал отличным компилятором, перевел уже несколько проектов на него в качестве лоадера для Webpack. Умеет многое из того, что умеет babel, включая полифиллы по usage исходя из browserslist, при этом работает быстрее на 20-25% в моих кейсах. Но плохо умеет в "сахарные" декораторы, приходится переписывать на функциональные, и нет плагина для оптимизации размера lodash (в случае если делается `import lodash fom 'lodash'; lodash.get()`). Минификация еще намного быстрее, чем в Terser. В целом - вполне production-ready.
Недавно было найдено решение https://github.com/DmitryKoterov/conditional-aggregate-webpack-plugin , но есть определенный issue, который я там описал. С доработкой все работает достаточно стабильно, и пересборка блочится пока не будут выполнены необходимые условия, измененные файлы агрегируются.
Начал вебмастерить сайты в 2004, после того как надоело переустанавливать винду и крякать игры (для школьника норм заработок был), первый крупный продовый проект был на Mambo/Joomla тогда же (школьный сайт с гостевой книгой, блогом, кастомным шаблоном, небезызвестными снежинками и форумом на phpbb). Чуть позже запилил стриминговый радио-сайт (плеер через flash) с трансляцией через Winamp, с друзьями до сих пор иногда запускаем.
После школы уже пошли заказы на сайты на Wordpress, Typo3, OpenCart, ModX, много сайтов-визиток. Параллельно с универом и после него настругал десятки сайтов на CouchCMS (однозначно лучший движок на мой взгляд). Интересные времена были. Как в статье и описано приходилось и в базу, и в хостинг, и в администрирование, и контент, и дизайн, и верстку, и скрипты на php, а тогдашнее сео заставляет вздрагивать (те же публикации на тысячах досок объявлений, чтобы войти в топ по перекрестным ссылкам, или невидимый текст белым на белом). Хотя веб-мастеров было немало, толково сайт, который не разъезжается, кроссбраузерный, и с минимальной резиновостью сделать могли очень немногие.
Иногда жаль, что по навыкам практически ничего с того времени не пригодилось.
Никто не мешает вынести общее ядро, а кастомные плагины и лоадеры дописывать уже в конкретных проектах, расширяя дефолтный конфиг. Не обязательно в него запихивать все, если конкретная фича нужна только в одном из десяти проектов.
Если проект экспериментальный - то делать полностью свой конфиг.
Вот здесь https://habr.com/ru/post/506636/ описывал намного более продвинутый вариант конфигурирования - конфиг вебпака протипизирован TS, разбит по папкам, файлы в которых имеют семантичные имена. Также там описан отличный вариант проброса env-параметров, рецепт параллельной сборки для фронта и для сервера, запуск сервера после билда.
Но даже тот вариант уже подустарел. А непротипизированное решение с webpack --build вместо билд-файла и продуманности системы файлов, колбеков и переменных - это просто самый первый и очевидный шаг к построению вебпакового конфига.
Но за статью плюс - часто маленькие шаги лучше принимаются и применяются сообществом, что вдохновляет задумываться и улучшать свои подходы к кодированию.
Понятно, да, если прогоняется все через функцию - тогда вытянуть тексты не проблема. Когда я имел в виду "держать тексты в шаблонах" подразумевал просто писать "some text" без функции. В вашем подходе не вижу недостатков - можно хоть в шаблоне, хоть в отдельном файле. Я обычно не использую сторонних инструментов и пишу просто
а айди формируется автоматически из __dirname. Для экспорта в любую систему локализации - либо пробежаться по всем этим файлам простой регуляркой, либо выполнить во всех этих файлах wrapMessages, подменив ее функционал на JSON.stringify. Так получится JSON с [{id: 'pages/user/accordion.hello', value: 'Hello {user}'}] , что можно загрузить в любую систему локализации. В коде в соответствии с веткой и локалью запрашивается готовый JSON и кладется в стор, который уже является источником правды для текстов в коде. Если там значения нет - то выводится дефолтный текст из объекта выше.
С арабским у меня проблем не было, владею им) А так - для какого заказчика разрабатываешь, на таком языке как правило и дефолтные тексты. Неудобства не испытываешь, т.к. имена констант все равно на английском.
JSON бандл как правило приходит через систему локализации, обычно удобнее получать данные через запрос к ней, а не загрузкой JSON, так как тексты - ответственность не разработчиков, а контент-менеджеров, поэтому в коде лучше держать только константы с базовым примером текста.
Только английский как основной не всем подойдет, это очередное ограничение.
$my_sign_in_reset_label - это что? Доллар-моя-подпись-в-сбросе-надписи? Доллар зачем, название страницы зачем? Если "для уникальности" - то пусть об уникальности заботятся инструменты.
1234 - это уникальный суффикс, не имеющий семантического значения, нужен для резолва исторически сложившегося глобального CSSOM, чтобы разруливать коллизии.
Переопределение стилей делается добавлением класса к компоненту, в Реакте например через проп <MyComponent headerClassName={styles.headerGreen} />, в самом компоненте в его class будет два класса - дефолтный и переданный, так не сломаются псевдоклассы.
Переводы в экшенах нужны для показа локализованной нотификации пользователю - например, каждый запрос к АПИ при фейле выдаст нотификацию (которая запускается через глобальный стор), но создавать на каждый запрос отдельный компонент нотификаций - это плохая практика, проще передать готовый текст через стор.
То, что не приходится писать {styles.table} - значит фреймворк решает за тебя, как будут называться классы, что является очередным ограничением. Кто-то может это назвать удобством - но нет, работа с именованиями классов это отдельное искусство, цель которого - дать ясное представление о структуре элементов на сайте и их взаимосвязях. Для этого нужна вложенность и семантика. Безиерархичные стили и автогенерируемые классы ухудшают читаемость и понятность.
Полный тайпчек стилей, если реализован грамотно, то может быть немного полезен, тут соглашусь. Но ценность этого довольно низкая, так как лишние стили лишь добавят немного размера файлам, не повлияя на работу сайта, и несложно находятся при рефакторинге.
Современные браузеры грузят ресурсы параллельно, и размер CSS как правило мал, особенно оптимизированного и сжатого, поэтому стили грузятся раньше скриптов, и нагрузка на браузер как раз снижается.
Размер бандла - хороший аргумент, с ним не поспоришь, как и со скоростью работы фреймворка, судя по бенчмаркам. Но это редко определяющие факторы при выборе. Если брать картину в целом то мой любимый стек выигрывает по более важным параметрам, а размер бандла при эффективном сжатии достаточно мал.
Ясный и понятный код у каждого свой. У одного это $.$$ { this.$ }, у другого yield* pipe(partial(sum, 1), multiply(3)).stream(), у третьего await StreamPipeUserControllerManager.emit('SuperLongNameFnFromThatModule'), у четвертого - императивный. И у каждого свое форматирование, табуляция, "лучшие практики", нейминг, длина строк, вложенность и т.п. Правила нужны для того, чтобы код оставался консистентным, согласованным и каждый человек не переписывал код другого человека под свое понимание понятности.
VSCode лучшая только для тех, кто к ней привык, и делать только для нее - как раз "заставлять ходить в брюках и рубашке", как собственно весь $mol и заставляет. "Только так, это самое лучшее, все остальное дно". Нет, не лучшее, а видение одного человека, опыт которого отличается от опыта всех остальных разработчиков.
Запрет на console.log в линтере - отличная практика, при необходимости сверху просто ставится // eslint-disable-next-line no-console. Увеличивает внимательность сотрудников, охраняет чистоту консоли. Не доводилось работать в проектах, которые при открытии консоли выводят несколько страниц кому-то когда-то нужного текста для разработки? Мне доводилось больше, чем несколько раз.
Кастомизируемость библиотек - это важно, рад, что в $mol есть хорошо кастомизируемые. Проблемы с библиотеками для Реакта бывают, и иногда весьма сложные. Но справиться можно со всем, изредка дописывая кастомные компоненты, это часть разработки.
Порядок и консистентность в файловой структуре - это отлично, только он должен создаваться соглашениями в команде, а не навязываться кодом. Код - продукт который делает команда, а не клетка, в которой они сидят. Подходы к форматированию файлов и паттерны написания кода - тоже корнями уходят в опыт и предпочтения команды. Хотя жесткие фреймворки освобождают от рутины синхронизации мнений, это подходит не всем. Я обычно высказываю в комментариях и статьях свое мнение о том, как должно быть все устроено, но в команде гибок и открыт для предложений, часто устраиваю глобальный рефакторинг проектов для того, чтобы он более соответствовал требованиям бизнеса и запросам коллектива. С $mol либо так, как видит его создатель, либо никак. С Реактом как правило всех устраивает html-подобный синтаксис и жизненный цикл, а все остальное - гибкое.
Отсутствие сокрытия состояния и глобальный доступ - это и есть глобальность. Когда можно вызвать тултип или нотификацию из любого места, провалидировать форму до перехода на другую страницу, сделать серию модалок, каждая из которых будет иметь доступ к данным предыдущей. При необходимости, разумеется. Если такое есть в $mol то может быть в этом пункте мы сходимся, только для меня состояние - это observable объект, а "канал" - функция изменения этого объекта из любого места. Каждое изменение рассылается тем компонентам, сайд-эффектам и геттерам, которым оно нужно. Этих концептов хватает для построения приложения любой сложности.
По поводу подходов к хранению состояния, подпискам на него и методов работы с жизненным циклом Flux, HOC, Redux, Hooks, MobX - лестница развития фронтенд-разработки. Где-то ступеньки приводят не туда, где-то возвращают на путь к идеальной архитектуре, и конца этого пути пока не видно - мы свидетельствуем начало кроссплатформенного программирования интерфейсов, и недостатков много и в CSS+HTML+JS, и в подходах с их использованием. Вполне возможно, что и вы со временем кардинально пересмотрите подход к фронтенду, по мере развития технологий всеобщими усилиями.
Да, были проекты с дефолтной локалью на русском и арабском. Если в отдельном файле хранить - то id можно генерировать из __dirname - соответственно не будет пересечений с другими файлами и из такого id можно по большей части понять, где текст используется.
А как вы генерируете из разметки json-файл, если объявляете тексты по месту использования? Он попадает туда в шаблонизированном виде, который удобен для добавления склонений, множественного числа, переводов строк, форматов дат? Суть объявления в отдельных файлах как раз удобство генерации id, преобразования в json и контролируемых шаблонах, которые можно отредактировать в системе локализации.
В целом да, дефолтный текст уходит в систему переводов, а финальный приходит через апи-запрос при смене языка, это довольно эффективная схема.
Кеш можно и не перегружать, но корректный hot-reload без дополнительной возни обязателен.
Тексты в разметке - всегда боль. Когда они хранятся в отдельных ts-файлах, как я сказал, можно их прогонять через любой шаблонизатор с нужными функциями, а при удалении ключей ругнется TS, при добавлении же неиспользуемых - ESLint. Так ли приятно видеть скажем проект, в разметке которого масса арабских или китайских слов? Но всегда приятно, когда видишь семантическое `{getLn(messages.buttonReset)}`. И в сторах, и в разметке, и в экшенах, и в сайд-эффектах это основа проекта, нацеленного на распространение в другие страны.
Семантичные имена классов с гарантией отсутствия пересечений - CSS Modules, где класс `.table` будет преобразован например по маске `[folder]_[name]-[hash:4]` и в итоговом коде будет `.ModalProduct_table-1234`. При этом в коде это будет просто `{styles.table}` с любым семантичным ключом, не ограниченным фреймворком. Тайпчек для css - однозначно лишнее, все проекты, в которых мы пробовали типизировать стили, в итоге приходили к мысли о бесполезности этого.
Точка отказа в файле стилей - это что-то новенькое, не сталкивался ни разу. CSS-файл обычно загружается параллельно с js и выполняется раньше него, улучшая метрики сайта. Также благодаря постпроцессорам типа CSSO стили эффективно преобразуются и размер их кардинально уменьшается, а за счет параллельной обработки браузером увеличивается скорость при открытии других страниц и при добавлении элементов на страницу, когда браузер уже знает как отображать новый элемент, а не получает инлайновый `style`.
Весь код в проекте должен быть в едином формате для простоты чтения и консистентности между разными разработчиками - это относится и к стилям, и к шаблонам, и к логике. Файлы должны переформатироваться при сохранении и на пре-коммит, чтобы гит-база содержала только консистентные данные. Это очень значительно для любого, кто занимался разработкой не в "соло".
VSCode - один из многих IDE, намного эффективней выносить правила в ESLint, который поддерживается широким спектром редакторов и может выполняться на CI для проверки консистентности форматирования и стиля кода.
Если локальная разработка на http, а стенды на https, то могут возникать определенные расхождения в работе приложения. К тому же стенд бэка, из которого локальный разработчик берет данные, может содержать специфические правила безопасности - часто на бэке длинная цепочка прокси-серверов, и то, в каком протоколе к ним обращаются, это важно. Да, можно настроить локальный nginx, не проблема, но дополнительная точка для документации, обучения, синхронизации.
Мощь готовых библиотек в соответствии функционала бизнес-требованиям. Широкий выбор библиотек и компонентов очень важен.
Свобода в организации файлов мне нужна для того, что жесткий подход в именовании файлов и их хранении - ограничение, которое может стать проблемой, как в том же Next.js, не позволяя совершенствовать архитектуру.
До каналов и инверсии я не добрался, но безусловно называть глобальные сторы и экшены непотребством - непрофессионально. Я разрабатываю в трехуровневом стиле: глобальные-модульные-локальные, из которых локальные - практически не используются, так как есть масса задач, когда контролировать компоненты требуется из-вне и часто на самом верхнем уровне (тот же онбординг).
Я понимаю, что все мы стремимся к идеальной архитектуре кода, но на мой взгляд вы давно свернули не в ту сторону, даже в самых базовых вещах, которые на мой взгляд и новичку должны быть понятны, мы расходимся. Как бы хорошо $mol ни работал в маленьких примерах и бенчмарках - в целом концепт очень навязчивый и ограничивающий, в стиле "а мы пойдем своим путем" вместо того, чтобы развивать и развиваться вместе с общим потоком фронтенд-разработки.
Может и браузерные кеш, но чтобы его не надо было отключать можно было бы contenthash дописывать к файлам.
Локализацию предпочитаю писать в отдельных тс-файлах с константами, после чего они прогоняются через шаблонизатор со всеми нужными удобствами, а в систему локализации попадают в шаблонизированном виде - держать тексты, даже дефолтные, в коде разметки - строгое табу в тех проектах, которые делаю.
Стили в TS малопривлекательная идея, т.к. реимплементируют функциональность, которая проработана в многочисленных препроцессорах и плагинах. Styled-components как вариация - это ад. Стили должны быть отдельными для эффективного кеширования и не включаться в скрипты, раздувая их размер и ухудшая перфоманс.
Генерируются js-файлы из стилевых и шаблонных. Сами стилевые и шаблонные имеют синтаксис, вряд ли поддерживаемый ESLint, Prettier, Stylelint. Опора на .editorconfig в проектах, в которых участвует не один разработчик не приводит к консистентности и не налагает достаточного количества ограничений. Переформатирование же сгенерированных файлов на precommit приведет к большим расхождениям между тем, что локально у человека, и тем, что в гите.
Про http имел в виду что таков дефолтный протокол для localhost - возможно, во фреймворке есть возможность включить https, но я, как говорил, не добрался до более глубокого изучения. Нужно это для одинаковой среды между локальным сервером и стендом.
Стандартная библиотека компонентов подойдет для маленькой CRM какой-нибудь студии, в крупных проектах требуется мощь Material UI или Antd, которые экономят громадное количество времени на разработку и легко интегрируются в Figma/Zeplin дизайнерами.
Под гибкостью я имел в виду свободу в организации файловой структуры. Может быть тут и есть import для подключения отдельных слоев (глобального апи, сторов, экшенов), но опять же я не добрался до архитектурных проб.
Попробовал запустить локально, но наткнулся на море багов. Все по туториалу сделал, перезапускал сервер и перезагружал страницу несколько раз - пустая. Потом удалил папку my, внезапно страница my/hello заработала. Пересоздал папку с другим неймспейсом - пишет что найти неймспейс не удается. Любые изменения в файлах не подтягиваются. Создал чистую папку с инсталляцией чистого hyoo-ru/mam.git, почему-то локальный сервер стал показывать что папка my/hello существует и видимо из какого-то кеша подгружает файлы из соседнего проекта. Дальше возиться смысла не вижу, пока версия библиотеки не станет достаточно протестированной (у меня свежий linux и море проектов на других фреймворках, которые запускаются без багов и танцев).
Тем не менее, посмотрел базовое описание и примеры - в них мне явно не подходит:
локализация в json, нужна ts-типизированная
процессинг стилей через postcss-cssnext вместо CSS Modules с кастомными плагинами транформации
дефолтное форматирование без ESLint и Prettier с кастомными энтерпрайзными правилами, прикрутить их будет непросто, т.к. много кода автогенерируется
http протокол локальной разработки
много автоматизированной "магии". Как правило мне нужен только рендерер в DOM с лайфциклом и совместимость с большим количеством opensource библиотек (компоненты, графики, таблицы, визуальные редакторы и т.п.). Архитектурные моменты с нужным функционалом как правило просто прикручиваю свои с дописыванием коннектора к рендереру.
негибкая структура файлов
Это чисто по чтению базовой документации, как сказал выше потрогать все это не получилось. У кого-то может и заведется и он будет готов все с нуля создавать под новые проекты, но даже при поверхностном взгляде это совсем не продакшен решение.
В первом же крупном проекте который делал на хуках пришлось писать длинные цепочки их вызовов с учетом результатов выполнения каждой (для сложного селекта и для онлайн редактора кода), что даже после нескольких итераций рефакторинга выглядело пугающе, в отличие от удобной компоновки в методах класса. Потом пришлось бороться с постоянным потоком ошибок от коллег-разработчиков в оптимизации и равенства по ссылкам при использовании длинной лестницы вложенных хуков. Это стало основными причинами нелюбви, к которым добавились впоследствии те, что описал в комментариях выше.
До него так и не добрались руки, как вижу this.$ \>= и т.п. , сразу в конец списка приоритетов по просмотру идет. Не то, чтобы было сложно разобраться - но семантичность это крайне важно для проектов, в которых участвую. Как и распространенность инструмента, экосистема, опыт разработчиков в этой системе. Также $mol - это комплексный фреймворк, я же ориентируюсь на кастомные решения в каждой из отдельных областей (рендеринг, роутинг, ssr, локализация, генерация, организация файлов и т.п.), потому что часто требуется кастомный функционал.
Но это все пальцем по воде, в бою ваш фреймворк не использовал, поэтому нет какого-либо сформированного мнения. Но попробую, когда будет свободное время.
Пожалуйста - https://habr.com/ru/post/450360/ . Уже 3 года назад Redux и Styled-components были глубоким легаси, которые только затрудняют развитие приложения.
Спустя 3 года и десятка энтерпрайз-проектов на подобной архитектуре я стал из ярого противника убежденным сторонником TS, а из сторонника реакт-хуков их ярым противником. Но React, MobX, CSS Components, Webpack и Babel прошли интенсивную проверку боем и продолжают на данный момент оставаться лидерами для старта энтерпрайз-проекта.
Я продолжаю изучать и сравнивать многое из того, что выходит на арену - сборщики, транспиляторы, фреймворки для рендеринга, подходы к стилизации, стейт-менеджеры. Перечислять все из опробованных не буду, они сейчас или в недавнем прошлом и так были у всех на слуху, но к стеку выше по функциональности, перфомансу, экосистеме, стабильности и скорости разработки на них, все едва ли приближаются.
Поэтому мои личные рекомендации - использовать для старта нового проекта именно этот стек + TS. Но подходы в той статье довольно устарели на мой взгляд, сейчас топлю за модульную архитектуру (lazy-load скриптов для каждой страницы, каждая из которых содержит модульные сторы и экшены), так как это лучше масштабируется при большом количестве страниц и разработчиков. Поэтому подумываю о сиквеле той статьи, но для этого сначала нужно завершить разработку вспомогательных библиотек.
Не могли бы привести пример предупреждений в консоли? У меня нету ни в одном проекте, как вызвать?
"Неявные подписки" - это отличная практика вынесения сложности за рамки основного кода. То есть работаешь по виду с обычными объектами, а на изменения определенных параметров, в том числе глубоко вложенных, можно еще и подписываться, это же мечта из 2000-х. Я тогда море ухищрений делал, чтобы добиться реактивного рендеринга, теперь же все очень просто.
Про стор, в котором все намешано - это конечно антипаттерн, но никто не заставляет его так организовывать. Особенно это касается экшенов (функций изменения стора), намного эффективнее их выносить, чтобы они имели доступ к разным сторам. Поэтому нельзя отнести это отнести в минусы инструмента, который делает объекты реактивными и дает полную свободу в реализации.
"В эффекторе же у вас есть только события, которые способны изменять стор" - ну и в Mobx есть функции-экшены, которые изменяют стор, только без необходимости иммутабельно писать как в редаксе (store, data) = > ({...store, items: store.items.map(item => ({...item, isViewed: data.id === item.id}))}) , разводя дубляж и значительно усложняя код, и заводя прослойку в виде событий, которые являются чистым бесполезным бойлерплейтом. Все, что нужно - вызвать функцию, она меняет нужный параметр в сторе, автоматически происходит эффективный перерендеринг.
Насчет "полегче" - аргумент, конечно, хороший, если измерения проводить в маленьких проектах, где размер библиотек намного превышает размер бизнес-логики, но уже в средних размер приложений с mobx за счет практически отсутствия бойлерплейта уже начинает выравниваться, в крупных - будет меньше.
У меня обычно в проектах разные интерфейсы для renderWait и renderEmpty, поэтому просто пишу get renderWait() { return <SomeMarkup /> } и в самом render() { if (isLoading) return this.renderWait; } . В целом тут только для очень специфических кейсов пригодится унификация и наследование, и если унифицировано - то лучше вынести на уровень выше, чтобы верхний компонент показывал соответствующую разметку, не раздувая нижние компоненты.
А разные типы одного компонента с общим функционалом сделал бы через class BranchWrapper{ render() { return Children.clone(this.props.children, { getChildNode: () => logic; }) } } . Так что варианты есть. Хотя это как раз React way, по которому не очень хочется идти, ООП довольно сильно усложняет восприятие, на мой взгляд. А еще лучше - через контекст, чтобы совсем отвязаться от пути Реакта - class SomeBranch { handleButtonClick = () => this.context.getNodes(this.props.branchId) }. Думаю, так проще, чем наследовать, но у каждого свой путь)
А где во фронте, если не секрет, вам пригодилось наследование? Мне лично - нигде, кроме как отнаследовать класс от реакта, чтобы появились методы жизненного цикла и в играх. В остальном никогда. Если нужна какая-то функция в нескольких компонентах то просто импортится из утилит и вызывается, если какая-то логика выборки переиспользуется - то делается геттер в хранилище.
Хуки вообще странный концепт, я с ними тоже не подружился. Ничего мне не нужно от того что они продают - а именно объединенный в один вызов useEffect маунт-размаунт и "переиспользуемость". Семантичные методы класса для жизненного цикла удобней и ssr поддерживают, а переиспользуемость легко и в классах реализуется. В остальном только проблемы от кода, превращающего в кашу из длинных грязных функций без явных слоев логики.
Все, что в статье приведено - это проблемы React way, то есть когда простой фреймворк обрастает концептами и фичами, которые намного эффективнее решались бы сторонними решениями. Но никто на самом деле не навязывает их, можно использовать только нужное, для меня это:
Оформление компонентов в классы
3 метода жизненного цикла - componentWillMount (для SSR+client), componentDidMount (только client) и componentWillUnmount. Я бы предпочел, чтобы они более семантично и короче назывались, но это не большая проблема
Доступ к context (некоему глобальному объекту) из любого компонента без дополнительных импортов
Грамотно сделанный HTML-in-JS шаблонизатор со скоупом функции и JS-in-HTML
(иногда) Рефы, чтобы не генерировать уникальные идентификаторы для определенных частей компонента
Для всего остального есть удобные реактивные решения, о которых все знают. И для подписки на изменения, и для ререндеринга только при изменении используемых параметров, и для кеширования в геттерах сложной логики, и для батчинга вносимых изменений. Если бы React скорцентрировался чисто на функционале выше и максимизировал перфоманс и размер исходя чисто из этих фич - я был бы счастлив. Но сейчас он дает простор и тем, кто хочет повозиться с хуками, с нереактивными пробросами пропсов, с иммутабельными изменениями через редюсеры, с невидимым вооруженному глазу состоянием внутри функции, с комбинированными в один вызов жизненными циклами, с асинхронными компонентами, разными системами стилизации - что на самом деле не такой уж большой минус, так как развивает экосистему, которая действительно стала огромной. Но заставлять все это пробовать и использовать - этого нет, можно обойтись минимумом, нужным конкретному разработчику, и дополнить решениями, которые он считает адекватными.
SWC кстати стал отличным компилятором, перевел уже несколько проектов на него в качестве лоадера для Webpack. Умеет многое из того, что умеет babel, включая полифиллы по usage исходя из browserslist, при этом работает быстрее на 20-25% в моих кейсах. Но плохо умеет в "сахарные" декораторы, приходится переписывать на функциональные, и нет плагина для оптимизации размера lodash (в случае если делается `import lodash fom 'lodash'; lodash.get()`). Минификация еще намного быстрее, чем в Terser. В целом - вполне production-ready.
Недавно было найдено решение https://github.com/DmitryKoterov/conditional-aggregate-webpack-plugin , но есть определенный issue, который я там описал. С доработкой все работает достаточно стабильно, и пересборка блочится пока не будут выполнены необходимые условия, измененные файлы агрегируются.
Asus mb16ac с матовой пленкой, годы таскаю по поездкам к мини пк. Стойки удобные можно из Китая заказать.
Начал вебмастерить сайты в 2004, после того как надоело переустанавливать винду и крякать игры (для школьника норм заработок был), первый крупный продовый проект был на Mambo/Joomla тогда же (школьный сайт с гостевой книгой, блогом, кастомным шаблоном, небезызвестными снежинками и форумом на phpbb). Чуть позже запилил стриминговый радио-сайт (плеер через flash) с трансляцией через Winamp, с друзьями до сих пор иногда запускаем.
После школы уже пошли заказы на сайты на Wordpress, Typo3, OpenCart, ModX, много сайтов-визиток. Параллельно с универом и после него настругал десятки сайтов на CouchCMS (однозначно лучший движок на мой взгляд). Интересные времена были. Как в статье и описано приходилось и в базу, и в хостинг, и в администрирование, и контент, и дизайн, и верстку, и скрипты на php, а тогдашнее сео заставляет вздрагивать (те же публикации на тысячах досок объявлений, чтобы войти в топ по перекрестным ссылкам, или невидимый текст белым на белом). Хотя веб-мастеров было немало, толково сайт, который не разъезжается, кроссбраузерный, и с минимальной резиновостью сделать могли очень немногие.
Иногда жаль, что по навыкам практически ничего с того времени не пригодилось.
Никто не мешает вынести общее ядро, а кастомные плагины и лоадеры дописывать уже в конкретных проектах, расширяя дефолтный конфиг. Не обязательно в него запихивать все, если конкретная фича нужна только в одном из десяти проектов.
Если проект экспериментальный - то делать полностью свой конфиг.
Вот здесь https://habr.com/ru/post/506636/ описывал намного более продвинутый вариант конфигурирования - конфиг вебпака протипизирован TS, разбит по папкам, файлы в которых имеют семантичные имена. Также там описан отличный вариант проброса env-параметров, рецепт параллельной сборки для фронта и для сервера, запуск сервера после билда.
Но даже тот вариант уже подустарел. А непротипизированное решение с webpack --build вместо билд-файла и продуманности системы файлов, колбеков и переменных - это просто самый первый и очевидный шаг к построению вебпакового конфига.
Но за статью плюс - часто маленькие шаги лучше принимаются и применяются сообществом, что вдохновляет задумываться и улучшать свои подходы к кодированию.
Понятно, да, если прогоняется все через функцию - тогда вытянуть тексты не проблема. Когда я имел в виду "держать тексты в шаблонах" подразумевал просто писать "some text" без функции. В вашем подходе не вижу недостатков - можно хоть в шаблоне, хоть в отдельном файле. Я обычно не использую сторонних инструментов и пишу просто
а айди формируется автоматически из __dirname. Для экспорта в любую систему локализации - либо пробежаться по всем этим файлам простой регуляркой, либо выполнить во всех этих файлах wrapMessages, подменив ее функционал на JSON.stringify. Так получится JSON с [{id: 'pages/user/accordion.hello', value: 'Hello {user}'}] , что можно загрузить в любую систему локализации. В коде в соответствии с веткой и локалью запрашивается готовый JSON и кладется в стор, который уже является источником правды для текстов в коде. Если там значения нет - то выводится дефолтный текст из объекта выше.
С арабским у меня проблем не было, владею им) А так - для какого заказчика разрабатываешь, на таком языке как правило и дефолтные тексты. Неудобства не испытываешь, т.к. имена констант все равно на английском.
JSON бандл как правило приходит через систему локализации, обычно удобнее получать данные через запрос к ней, а не загрузкой JSON, так как тексты - ответственность не разработчиков, а контент-менеджеров, поэтому в коде лучше держать только константы с базовым примером текста.
Только английский как основной не всем подойдет, это очередное ограничение.
$my_sign_in_reset_label- это что? Доллар-моя-подпись-в-сбросе-надписи? Доллар зачем, название страницы зачем? Если "для уникальности" - то пусть об уникальности заботятся инструменты.1234 - это уникальный суффикс, не имеющий семантического значения, нужен для резолва исторически сложившегося глобального CSSOM, чтобы разруливать коллизии.
Переопределение стилей делается добавлением класса к компоненту, в Реакте например через проп
<MyComponent headerClassName={styles.headerGreen} />, в самом компоненте в его class будет два класса - дефолтный и переданный, так не сломаются псевдоклассы.Переводы в экшенах нужны для показа локализованной нотификации пользователю - например, каждый запрос к АПИ при фейле выдаст нотификацию (которая запускается через глобальный стор), но создавать на каждый запрос отдельный компонент нотификаций - это плохая практика, проще передать готовый текст через стор.
То, что не приходится писать
{styles.table}- значит фреймворк решает за тебя, как будут называться классы, что является очередным ограничением. Кто-то может это назвать удобством - но нет, работа с именованиями классов это отдельное искусство, цель которого - дать ясное представление о структуре элементов на сайте и их взаимосвязях. Для этого нужна вложенность и семантика. Безиерархичные стили и автогенерируемые классы ухудшают читаемость и понятность.Полный тайпчек стилей, если реализован грамотно, то может быть немного полезен, тут соглашусь. Но ценность этого довольно низкая, так как лишние стили лишь добавят немного размера файлам, не повлияя на работу сайта, и несложно находятся при рефакторинге.
Современные браузеры грузят ресурсы параллельно, и размер CSS как правило мал, особенно оптимизированного и сжатого, поэтому стили грузятся раньше скриптов, и нагрузка на браузер как раз снижается.
Размер бандла - хороший аргумент, с ним не поспоришь, как и со скоростью работы фреймворка, судя по бенчмаркам. Но это редко определяющие факторы при выборе. Если брать картину в целом то мой любимый стек выигрывает по более важным параметрам, а размер бандла при эффективном сжатии достаточно мал.
Ясный и понятный код у каждого свой. У одного это
$.$$ { this.$ }, у другогоyield* pipe(partial(sum, 1), multiply(3)).stream(), у третьегоawait StreamPipeUserControllerManager.emit('SuperLongNameFnFromThatModule'), у четвертого - императивный. И у каждого свое форматирование, табуляция, "лучшие практики", нейминг, длина строк, вложенность и т.п. Правила нужны для того, чтобы код оставался консистентным, согласованным и каждый человек не переписывал код другого человека под свое понимание понятности.VSCode лучшая только для тех, кто к ней привык, и делать только для нее - как раз "заставлять ходить в брюках и рубашке", как собственно весь $mol и заставляет. "Только так, это самое лучшее, все остальное дно". Нет, не лучшее, а видение одного человека, опыт которого отличается от опыта всех остальных разработчиков.
Запрет на console.log в линтере - отличная практика, при необходимости сверху просто ставится // eslint-disable-next-line no-console. Увеличивает внимательность сотрудников, охраняет чистоту консоли. Не доводилось работать в проектах, которые при открытии консоли выводят несколько страниц кому-то когда-то нужного текста для разработки? Мне доводилось больше, чем несколько раз.
Кастомизируемость библиотек - это важно, рад, что в $mol есть хорошо кастомизируемые. Проблемы с библиотеками для Реакта бывают, и иногда весьма сложные. Но справиться можно со всем, изредка дописывая кастомные компоненты, это часть разработки.
Порядок и консистентность в файловой структуре - это отлично, только он должен создаваться соглашениями в команде, а не навязываться кодом. Код - продукт который делает команда, а не клетка, в которой они сидят. Подходы к форматированию файлов и паттерны написания кода - тоже корнями уходят в опыт и предпочтения команды. Хотя жесткие фреймворки освобождают от рутины синхронизации мнений, это подходит не всем. Я обычно высказываю в комментариях и статьях свое мнение о том, как должно быть все устроено, но в команде гибок и открыт для предложений, часто устраиваю глобальный рефакторинг проектов для того, чтобы он более соответствовал требованиям бизнеса и запросам коллектива. С $mol либо так, как видит его создатель, либо никак. С Реактом как правило всех устраивает html-подобный синтаксис и жизненный цикл, а все остальное - гибкое.
Отсутствие сокрытия состояния и глобальный доступ - это и есть глобальность. Когда можно вызвать тултип или нотификацию из любого места, провалидировать форму до перехода на другую страницу, сделать серию модалок, каждая из которых будет иметь доступ к данным предыдущей. При необходимости, разумеется. Если такое есть в $mol то может быть в этом пункте мы сходимся, только для меня состояние - это observable объект, а "канал" - функция изменения этого объекта из любого места. Каждое изменение рассылается тем компонентам, сайд-эффектам и геттерам, которым оно нужно. Этих концептов хватает для построения приложения любой сложности.
По поводу подходов к хранению состояния, подпискам на него и методов работы с жизненным циклом Flux, HOC, Redux, Hooks, MobX - лестница развития фронтенд-разработки. Где-то ступеньки приводят не туда, где-то возвращают на путь к идеальной архитектуре, и конца этого пути пока не видно - мы свидетельствуем начало кроссплатформенного программирования интерфейсов, и недостатков много и в CSS+HTML+JS, и в подходах с их использованием. Вполне возможно, что и вы со временем кардинально пересмотрите подход к фронтенду, по мере развития технологий всеобщими усилиями.
Да, были проекты с дефолтной локалью на русском и арабском. Если в отдельном файле хранить - то id можно генерировать из __dirname - соответственно не будет пересечений с другими файлами и из такого id можно по большей части понять, где текст используется.
А как вы генерируете из разметки json-файл, если объявляете тексты по месту использования? Он попадает туда в шаблонизированном виде, который удобен для добавления склонений, множественного числа, переводов строк, форматов дат? Суть объявления в отдельных файлах как раз удобство генерации id, преобразования в json и контролируемых шаблонах, которые можно отредактировать в системе локализации.
В целом да, дефолтный текст уходит в систему переводов, а финальный приходит через апи-запрос при смене языка, это довольно эффективная схема.
Кеш можно и не перегружать, но корректный hot-reload без дополнительной возни обязателен.
Тексты в разметке - всегда боль. Когда они хранятся в отдельных ts-файлах, как я сказал, можно их прогонять через любой шаблонизатор с нужными функциями, а при удалении ключей ругнется TS, при добавлении же неиспользуемых - ESLint. Так ли приятно видеть скажем проект, в разметке которого масса арабских или китайских слов? Но всегда приятно, когда видишь семантическое `{getLn(messages.buttonReset)}`. И в сторах, и в разметке, и в экшенах, и в сайд-эффектах это основа проекта, нацеленного на распространение в другие страны.
Семантичные имена классов с гарантией отсутствия пересечений - CSS Modules, где класс `.table` будет преобразован например по маске `[folder]_[name]-[hash:4]` и в итоговом коде будет `.ModalProduct_table-1234`. При этом в коде это будет просто `{styles.table}` с любым семантичным ключом, не ограниченным фреймворком. Тайпчек для css - однозначно лишнее, все проекты, в которых мы пробовали типизировать стили, в итоге приходили к мысли о бесполезности этого.
Точка отказа в файле стилей - это что-то новенькое, не сталкивался ни разу. CSS-файл обычно загружается параллельно с js и выполняется раньше него, улучшая метрики сайта. Также благодаря постпроцессорам типа CSSO стили эффективно преобразуются и размер их кардинально уменьшается, а за счет параллельной обработки браузером увеличивается скорость при открытии других страниц и при добавлении элементов на страницу, когда браузер уже знает как отображать новый элемент, а не получает инлайновый `style`.
Весь код в проекте должен быть в едином формате для простоты чтения и консистентности между разными разработчиками - это относится и к стилям, и к шаблонам, и к логике. Файлы должны переформатироваться при сохранении и на пре-коммит, чтобы гит-база содержала только консистентные данные. Это очень значительно для любого, кто занимался разработкой не в "соло".
VSCode - один из многих IDE, намного эффективней выносить правила в ESLint, который поддерживается широким спектром редакторов и может выполняться на CI для проверки консистентности форматирования и стиля кода.
Если локальная разработка на http, а стенды на https, то могут возникать определенные расхождения в работе приложения. К тому же стенд бэка, из которого локальный разработчик берет данные, может содержать специфические правила безопасности - часто на бэке длинная цепочка прокси-серверов, и то, в каком протоколе к ним обращаются, это важно. Да, можно настроить локальный nginx, не проблема, но дополнительная точка для документации, обучения, синхронизации.
Мощь готовых библиотек в соответствии функционала бизнес-требованиям. Широкий выбор библиотек и компонентов очень важен.
Свобода в организации файлов мне нужна для того, что жесткий подход в именовании файлов и их хранении - ограничение, которое может стать проблемой, как в том же Next.js, не позволяя совершенствовать архитектуру.
До каналов и инверсии я не добрался, но безусловно называть глобальные сторы и экшены непотребством - непрофессионально. Я разрабатываю в трехуровневом стиле: глобальные-модульные-локальные, из которых локальные - практически не используются, так как есть масса задач, когда контролировать компоненты требуется из-вне и часто на самом верхнем уровне (тот же онбординг).
Я понимаю, что все мы стремимся к идеальной архитектуре кода, но на мой взгляд вы давно свернули не в ту сторону, даже в самых базовых вещах, которые на мой взгляд и новичку должны быть понятны, мы расходимся. Как бы хорошо $mol ни работал в маленьких примерах и бенчмарках - в целом концепт очень навязчивый и ограничивающий, в стиле "а мы пойдем своим путем" вместо того, чтобы развивать и развиваться вместе с общим потоком фронтенд-разработки.
Может и браузерные кеш, но чтобы его не надо было отключать можно было бы contenthash дописывать к файлам.
Локализацию предпочитаю писать в отдельных тс-файлах с константами, после чего они прогоняются через шаблонизатор со всеми нужными удобствами, а в систему локализации попадают в шаблонизированном виде - держать тексты, даже дефолтные, в коде разметки - строгое табу в тех проектах, которые делаю.
Стили в TS малопривлекательная идея, т.к. реимплементируют функциональность, которая проработана в многочисленных препроцессорах и плагинах. Styled-components как вариация - это ад. Стили должны быть отдельными для эффективного кеширования и не включаться в скрипты, раздувая их размер и ухудшая перфоманс.
Генерируются js-файлы из стилевых и шаблонных. Сами стилевые и шаблонные имеют синтаксис, вряд ли поддерживаемый ESLint, Prettier, Stylelint. Опора на .editorconfig в проектах, в которых участвует не один разработчик не приводит к консистентности и не налагает достаточного количества ограничений. Переформатирование же сгенерированных файлов на precommit приведет к большим расхождениям между тем, что локально у человека, и тем, что в гите.
Про http имел в виду что таков дефолтный протокол для localhost - возможно, во фреймворке есть возможность включить https, но я, как говорил, не добрался до более глубокого изучения. Нужно это для одинаковой среды между локальным сервером и стендом.
Стандартная библиотека компонентов подойдет для маленькой CRM какой-нибудь студии, в крупных проектах требуется мощь Material UI или Antd, которые экономят громадное количество времени на разработку и легко интегрируются в Figma/Zeplin дизайнерами.
Под гибкостью я имел в виду свободу в организации файловой структуры. Может быть тут и есть import для подключения отдельных слоев (глобального апи, сторов, экшенов), но опять же я не добрался до архитектурных проб.
Попробовал запустить локально, но наткнулся на море багов. Все по туториалу сделал, перезапускал сервер и перезагружал страницу несколько раз - пустая. Потом удалил папку my, внезапно страница my/hello заработала. Пересоздал папку с другим неймспейсом - пишет что найти неймспейс не удается. Любые изменения в файлах не подтягиваются. Создал чистую папку с инсталляцией чистого hyoo-ru/mam.git, почему-то локальный сервер стал показывать что папка my/hello существует и видимо из какого-то кеша подгружает файлы из соседнего проекта. Дальше возиться смысла не вижу, пока версия библиотеки не станет достаточно протестированной (у меня свежий linux и море проектов на других фреймворках, которые запускаются без багов и танцев).
Тем не менее, посмотрел базовое описание и примеры - в них мне явно не подходит:
локализация в json, нужна ts-типизированная
процессинг стилей через postcss-cssnext вместо CSS Modules с кастомными плагинами транформации
дефолтное форматирование без ESLint и Prettier с кастомными энтерпрайзными правилами, прикрутить их будет непросто, т.к. много кода автогенерируется
http протокол локальной разработки
много автоматизированной "магии". Как правило мне нужен только рендерер в DOM с лайфциклом и совместимость с большим количеством opensource библиотек (компоненты, графики, таблицы, визуальные редакторы и т.п.). Архитектурные моменты с нужным функционалом как правило просто прикручиваю свои с дописыванием коннектора к рендереру.
негибкая структура файлов
Это чисто по чтению базовой документации, как сказал выше потрогать все это не получилось. У кого-то может и заведется и он будет готов все с нуля создавать под новые проекты, но даже при поверхностном взгляде это совсем не продакшен решение.
Вот в этих комментариях описывал:
https://habr.com/ru/post/534632/comments/#comment_22459664
https://habr.com/ru/company/ruvds/blog/507518/comments/#comment_21763020
https://habr.com/ru/company/skillfactory/blog/539068/comments/#comment_22619868
https://habr.com/ru/post/565904/comments/#comment_23221032
https://habr.com/ru/post/586526/comments/#comment_23656254
В первом же крупном проекте который делал на хуках пришлось писать длинные цепочки их вызовов с учетом результатов выполнения каждой (для сложного селекта и для онлайн редактора кода), что даже после нескольких итераций рефакторинга выглядело пугающе, в отличие от удобной компоновки в методах класса. Потом пришлось бороться с постоянным потоком ошибок от коллег-разработчиков в оптимизации и равенства по ссылкам при использовании длинной лестницы вложенных хуков. Это стало основными причинами нелюбви, к которым добавились впоследствии те, что описал в комментариях выше.
До него так и не добрались руки, как вижу this.$ \>= и т.п. , сразу в конец списка приоритетов по просмотру идет. Не то, чтобы было сложно разобраться - но семантичность это крайне важно для проектов, в которых участвую. Как и распространенность инструмента, экосистема, опыт разработчиков в этой системе. Также $mol - это комплексный фреймворк, я же ориентируюсь на кастомные решения в каждой из отдельных областей (рендеринг, роутинг, ssr, локализация, генерация, организация файлов и т.п.), потому что часто требуется кастомный функционал.
Но это все пальцем по воде, в бою ваш фреймворк не использовал, поэтому нет какого-либо сформированного мнения. Но попробую, когда будет свободное время.
Пожалуйста - https://habr.com/ru/post/450360/ . Уже 3 года назад Redux и Styled-components были глубоким легаси, которые только затрудняют развитие приложения.
Спустя 3 года и десятка энтерпрайз-проектов на подобной архитектуре я стал из ярого противника убежденным сторонником TS, а из сторонника реакт-хуков их ярым противником. Но React, MobX, CSS Components, Webpack и Babel прошли интенсивную проверку боем и продолжают на данный момент оставаться лидерами для старта энтерпрайз-проекта.
Я продолжаю изучать и сравнивать многое из того, что выходит на арену - сборщики, транспиляторы, фреймворки для рендеринга, подходы к стилизации, стейт-менеджеры. Перечислять все из опробованных не буду, они сейчас или в недавнем прошлом и так были у всех на слуху, но к стеку выше по функциональности, перфомансу, экосистеме, стабильности и скорости разработки на них, все едва ли приближаются.
Поэтому мои личные рекомендации - использовать для старта нового проекта именно этот стек + TS. Но подходы в той статье довольно устарели на мой взгляд, сейчас топлю за модульную архитектуру (lazy-load скриптов для каждой страницы, каждая из которых содержит модульные сторы и экшены), так как это лучше масштабируется при большом количестве страниц и разработчиков. Поэтому подумываю о сиквеле той статьи, но для этого сначала нужно завершить разработку вспомогательных библиотек.