Comments 100
Картинка к статье. Шестерни фрезеруют на портальном ЧПУ. Аж глаз задергался :)
В 2022 такое отношение к typescript вызывает удивление. Ну правда, я даже в стартапах, где нужно "ещё вчера" вижу значительное улучшение качества кода, а значит - меньше багов. Не говоря уже об крупных проектах. А вот ваши аргументы не выдерживают критики.
Несомненно, найдутся сложные вещи, которые сложно быстро без опыта воплотить в коде. Но всегда можно заигнорить.
Тема локализации и интернационализации не раскрыта. Почему не formatjs? Только из-за next?
Почему не рассмотрен mobx?
Аналогично. Я просто не понимаю, когда говорят, что typescript, что-то усложняет. Он ничего не усложняет, наоборот он многократно упрощает написание кода и его читаемость.
Потому что это дополнительный уровень абстракции, который требует транспайлер и сопутствующие настройки, пекеджи и т. п. Это повышает сложность системы. Особенно это неудобно новичкам, которые итак с трудом в этой реактовой бороде разбираются.
Что меня всегда удивляло в сторонниках тайпскрипта, так это нетерпимость у другому мнению. Это особенно настораживает. Наверно в ИТ не должно быть правильного мнения и неправильного, все таки. Я высказал свое. Если оно вас удивляет, это не значит, что оно не правильное.
Хм, а меня удивляет больше другой момент. Вам привели несколько аргументов которые ставят под сомнение ваше мнение (в том числе в комментариях к оригинальной статье), и вместо того чтобы его отстаивать в конструктивной дискуссии - вы переходите к тому, что "в IT не должно быть правильного мнения". И говорите о том что сторонники чего-то не терпимы к чему-то отличному...
не змаетил аргументов, к сожалению. "Я вижу что тайпскрипт лучше", это не аргумент, а личное мнение. Аргумент, это какие-то рассуждения, анализ, выводы, сравнения и т.д.
И минус - это не аргумент, а скорей показатель их отсутсвия
Неявные аргументы были, но Вы решили их пропустить.
Но я не акцентировал на этом внимание, потому что у Вас нет аргументов не использовать ts. Вы приводите какие-то слабейшие мифы и домыслы, расписываясь в том, том, что ts не использовали и не знаете. Зачем тогда о нем пишите?
Я лишь взывал к здравому смыслу.
Разве в моем сообщении есть намек нетерпимость? Вы что-то путаете.
Я не называл Ваше мнение неправильным, это сделали Вы сами.
Мнение? Я выразил свое, да. А Вы оскорбились.
Имхо, вы просто не пользовались ts-ом. Поэтому и такое отношение.
Если послушать интервью Дэна, то на вопрос о TS ответ однозначно "нет" ) Команда, которая поддерживает свыше 700 страниц, по словам того же Дэна, не использует TS. Но есть люди, как выясняется, которые его и в стартапах юзают. И да, они достаточно агрессивны.
Они там вместо TS используют Flow. Так исторически сложилось. Не было бы Flow, давно перешли бы на TS.
Цитирую ответ Дэна:
" Если и будем переписывать, то как-то более фундаментально, на тот же Rust или что-то такое. "
Так что на счет "перешли бы на TS" - это вряд ли.
Не буду критиковать TS, но как-то не находит отклик в душе, как-то (исключительно моё мнение) угловато всё это.
mobx не рассмотрен, потому что это не обзор экосистемы Реакта. Это предлагаемый универсальный стек для реализации приложений любого маштаба. На мой взгляд mobx не позвоялет реалтизовать приложения любого маштаба.
mobx не позвоялет реалтизовать приложения любого маштаба
Для реализации приложений любого масштаба нужны механизмы декомпозиции. MobX, как реализация ОПР, это позволяет. Redux же, наоборот, всячески сопротивляется.
На мой взгляд mobx не позвоялет реалтизовать приложения любого маштаба.
Уже который раз вижу такие слова, но как всегда - без обоснования.
Вы использовали mobx на проектах среднего и выше масштаба, чтобы так заявлять?
Аргумент "это мое мнение" Вы уже приводите второй раз, серьезно?
Я могу пропагандировать "теорию" плоской земли, имея в арсенале только лдин аргумент: "потому что я так считаю"?
В Vuex и Mobx практически все используют MVVM (или что-то близкое к этой архитектуре). Получается и Vue не должен позволять писать приложения любого масштаба. Но ведь пишут, как на Mobx так и на Vue + Vuex).
Mobx в отличие от Redux не ограничивает какой-либо архитектурой. Если плохо получается на нем, дело в навыках. При хороших архитектурных навыках можно вообще без менеджеров написать что угодно, но с ними удобнее.
Порекомендую перейти с redux на что-то другое хотя бы по той причине, что когда ответсвенность за архитектуру перекладывается на фремворк/библиотеку, это плохо сказывается на росте навыков проектирования.
У vue появилась pinia от разраба vuex.
Очень крутая штука. Я так понял, она в обозримом будущем будет как рекомендуемое хранилище.
Буду знать, спасибо! Пока пишу на React, но думаю при удобном случае перейти на Vue.
Я перешёл уже как пол года. Сейчас у меня проекты vue2/vuex и vue3/pinia. Ну что сказать: после реакта как-то бедненько с экосистемой. Если что-то популярное есть, то оно часто безальтернативное. А разраб vee-validate, единственого популярного решения про формы, вообще упоротый чувак, смена мажорной версии - новая либа под старым названием.
Но кодить мне нравится больше на vue, но тут ещё фактор новизны играет роль.
Это интервью Дэна 2021 года.
В твоих постах периодически видно пассивно-агрессивное отношение к Redux. Почему он тебе так не нравится, учитывая, насколько удобные обёртки написали мейнтейнеры, Redux toolkit и насколько улучшилась документация?
В плане документации и так далее — они большие молодцы, я оценил. К тем, кто его поддерживает, у меня нет совершенно никаких претензий, только благодарность. Почему я пассивно-агрессивно отношусь к нему — потому что это несколько строк кода, которые ничего не делают.
У меня первая реакция на такие вопросы — я не знаю, что такое state management, не понимаю, что люди имеют в виду, когда говорят об этом. Может, у меня профдеформация, потому что в React-команде мы просто думаем об этом иначе.
В React уже есть понятие State, это UI-состояние, его менеджишь тем, что просто используешь State, если нужно передать глубоко, используешь контекст и все дела.
— Насколько я знаю, Vue уже переписали на TypeScript. Когда, может быть, React перепишут с Flow на TypeScript?
Зачем? Я не то, чтобы какой-то адский фанат Flow, мне и то и другое по большей части по барабану, но это звучит как проект, в котором я не вижу смысла. На definitions, которые публичные, это никак не влияет. Наши внутренние типы всё равно будут другие, потому что то, как ты используешь React, отличается от того, как он реализован. Поэтому это звучит как большой проект, который не даёт для нас никакого выхлопа, и главное — для наших юзеров
Мнения разные бывают, так что не удивляйтесь.
Профессиональный React стек
Экспертный астрологический прогноз. Ладно, ладно, сначала глянем что нам там посоветуют профессионалы..
Redux — Central state management
Привет, процедурное программирование вокруг глобальной переменной, замаскированное под ФП, порождающее горы тормозящего бойлерплейта.
Redux-Saga — Async middleware для Redux
Здравствуй, состояние гонки и гличи.
Без SSR практически невозможно добиться хороших результатов в новой методике оценки сайтов от Google - Core Web Vitals.
Смелое заявление. Проверять я его конечно.. буду:
Как-то не густо для показа 10 карточек, десятка ссылок и поисковой формы. Которые, к тому же ещё и толком не работают. Но требуют 200КБ скриптов!
Для сравнения, старая демка без SSR, с нормально работающим поиском, подсветкой найденного, фильтрами, сортировкой и 40 отображаемыми карточками:
И всё это всего в 45КБ скриптов. Ну да ладно, пошли дальше..
С надежной и производительной технологией Fast Refresh ... ценность юнит тестирования становиться совсем неочевидной.
Основная задача тестов - постоянно проверять, что ты не сломал что-то ещё, пока пилил то, что хотел. Скорость перезагрузки тут ни чем не поможет.
если только у вас нет файлов с действительно сложной логикой. Но если они есть, то имеет смысл подумать про перенос этой логики на backend
Привет, сетевые задержки на ровном месте, ибо фронтендер не осилил тесты.
что может быть действительно полезным, так это функциональное тестирование интерфейса. Разработчику часто бывает сложно заметить, что радиус контейнера картинки составляет 2px вместо 4px
Функциональные тесты проверят функциональность. Какую функцию выполняют скругления контейнера и почему радиус берётся не из константы и требует написания тестов?
Typescript позволяет совершать меньше ошибок при разработке приложений. Возможно, это так, но не стоит забывать про побочные эффекты, такие как менее читаемый код и дополнительный траблшутинг специфичных для Typescript проблем, который отнимает время, но не улучшает при этом само приложение
Отладка таки допущенных ошибок отнимает куда больше времени. А если не хочется траблшутить - всегда можно написать any откатившись до Wild Wild JS.
Typescript может быть полезен при разработке модулей для других разработчиков, так как это позволяет получить подсказки в стиле IntelliSense от IDE. Ценность Typescript при разработке конечных продуктов для меня менее очевидна.
Конечные продукты всегда пилят программисты-одиночки, способные удерживать в голове проект любой сложности не ограниченно долгое время?
Статья отлично иллюстрирует как используется современный фронтенд тулзы - столько всего, чтобы отобразить сайт с функционалом из 2009 года, при том что сейчас работает еще и медленнее!
Покажите пример другого стека с переводами и адекватным стейтом и удобным функционалом. Желательно конечно, чтобы было репо и демка, чтобы было удобно перенять чужой позитивный опыт. Всем будет полезно.
Пожалуйста - https://habr.com/ru/post/450360/ . Уже 3 года назад Redux и Styled-components были глубоким легаси, которые только затрудняют развитие приложения.
Спустя 3 года и десятка энтерпрайз-проектов на подобной архитектуре я стал из ярого противника убежденным сторонником TS, а из сторонника реакт-хуков их ярым противником. Но React, MobX, CSS Components, Webpack и Babel прошли интенсивную проверку боем и продолжают на данный момент оставаться лидерами для старта энтерпрайз-проекта.
Я продолжаю изучать и сравнивать многое из того, что выходит на арену - сборщики, транспиляторы, фреймворки для рендеринга, подходы к стилизации, стейт-менеджеры. Перечислять все из опробованных не буду, они сейчас или в недавнем прошлом и так были у всех на слуху, но к стеку выше по функциональности, перфомансу, экосистеме, стабильности и скорости разработки на них, все едва ли приближаются.
Поэтому мои личные рекомендации - использовать для старта нового проекта именно этот стек + TS. Но подходы в той статье довольно устарели на мой взгляд, сейчас топлю за модульную архитектуру (lazy-load скриптов для каждой страницы, каждая из которых содержит модульные сторы и экшены), так как это лучше масштабируется при большом количестве страниц и разработчиков. Поэтому подумываю о сиквеле той статьи, но для этого сначала нужно завершить разработку вспомогательных библиотек.
Я продолжаю изучать и сравнивать многое из того, что выходит на арену - сборщики, транспиляторы, фреймворки для рендеринга, подходы к стилизации, стейт-менеджеры. Перечислять все из опробованных не буду, они сейчас или в недавнем прошлом и так были у всех на слуху, но к стеку выше по функциональности, перфомансу, экосистеме, стабильности и скорости разработки на них, все едва ли приближаются.
Что, даже $mol едва ли приближается?
До него так и не добрались руки, как вижу this.$ \>= и т.п. , сразу в конец списка приоритетов по просмотру идет. Не то, чтобы было сложно разобраться - но семантичность это крайне важно для проектов, в которых участвую. Как и распространенность инструмента, экосистема, опыт разработчиков в этой системе. Также $mol - это комплексный фреймворк, я же ориентируюсь на кастомные решения в каждой из отдельных областей (рендеринг, роутинг, ssr, локализация, генерация, организация файлов и т.п.), потому что часто требуется кастомный функционал.
Но это все пальцем по воде, в бою ваш фреймворк не использовал, поэтому нет какого-либо сформированного мнения. Но попробую, когда будет свободное время.
Вот как раз с семантичностью у $mol всё в порядке. Чего только стектрейсы стоят:
$mol - не комплексный фреймворк, а набор микромодулей, любым из которых можно использоваться независимо. В частности:
рендеринг - $mol_dom_render
роутинг - $mol_state_arg
ssr не требует особых приседаний
локализация - $mol_locale
генерация - чего? если HTML, то $mol_view / $mol_jsx
организация файлов - MAM
и так далее.
Попробовал запустить локально, но наткнулся на море багов. Все по туториалу сделал, перезапускал сервер и перезагружал страницу несколько раз - пустая. Потом удалил папку my, внезапно страница my/hello заработала. Пересоздал папку с другим неймспейсом - пишет что найти неймспейс не удается. Любые изменения в файлах не подтягиваются. Создал чистую папку с инсталляцией чистого hyoo-ru/mam.git, почему-то локальный сервер стал показывать что папка my/hello существует и видимо из какого-то кеша подгружает файлы из соседнего проекта. Дальше возиться смысла не вижу, пока версия библиотеки не станет достаточно протестированной (у меня свежий linux и море проектов на других фреймворках, которые запускаются без багов и танцев).
Тем не менее, посмотрел базовое описание и примеры - в них мне явно не подходит:
локализация в json, нужна ts-типизированная
процессинг стилей через postcss-cssnext вместо CSS Modules с кастомными плагинами транформации
дефолтное форматирование без ESLint и Prettier с кастомными энтерпрайзными правилами, прикрутить их будет непросто, т.к. много кода автогенерируется
http протокол локальной разработки
много автоматизированной "магии". Как правило мне нужен только рендерер в DOM с лайфциклом и совместимость с большим количеством opensource библиотек (компоненты, графики, таблицы, визуальные редакторы и т.п.). Архитектурные моменты с нужным функционалом как правило просто прикручиваю свои с дописыванием коннектора к рендереру.
негибкая структура файлов
Это чисто по чтению базовой документации, как сказал выше потрогать все это не получилось. У кого-то может и заведется и он будет готов все с нуля создавать под новые проекты, но даже при поверхностном взгляде это совсем не продакшен решение.
перезапускал сервер и перезагружал страницу несколько раз - пустая
Вангую, что надо было просто выключить кеш в девтулзах.
локализация в json, нужна ts-типизированная
В коде тексты пишутся на английском, потом оттуда они экстрактируются в JSON и передаются в сервис переводов.
процессинг стилей через postcss-cssnext вместо CSS Modules с кастомными плагинами транформации
Там нет ни того, ни другого. Стили пишутся в TS.
дефолтное форматирование без ESLint и Prettier с кастомными энтерпрайзными правилами, прикрутить их будет непросто, т.к. много кода автогенерируется
Не распарсил. Кто где генерируется?
http протокол локальной разработки
А это о чём?
Как правило мне нужен только рендерер в DOM с лайфциклом и совместимость с большим количеством opensource библиотек (компоненты, графики, таблицы, визуальные редакторы и т.п.)
В $mol довольно богатая стандартная библиотека компонент. Любые сторонние прикручиваются элементарно - берёте this.dom_node() и делаете с ним, что хотите.
негибкая структура файлов
Какой гибкости не хватает?
Может и браузерные кеш, но чтобы его не надо было отключать можно было бы contenthash дописывать к файлам.
Локализацию предпочитаю писать в отдельных тс-файлах с константами, после чего они прогоняются через шаблонизатор со всеми нужными удобствами, а в систему локализации попадают в шаблонизированном виде - держать тексты, даже дефолтные, в коде разметки - строгое табу в тех проектах, которые делаю.
Стили в TS малопривлекательная идея, т.к. реимплементируют функциональность, которая проработана в многочисленных препроцессорах и плагинах. Styled-components как вариация - это ад. Стили должны быть отдельными для эффективного кеширования и не включаться в скрипты, раздувая их размер и ухудшая перфоманс.
Генерируются js-файлы из стилевых и шаблонных. Сами стилевые и шаблонные имеют синтаксис, вряд ли поддерживаемый ESLint, Prettier, Stylelint. Опора на .editorconfig в проектах, в которых участвует не один разработчик не приводит к консистентности и не налагает достаточного количества ограничений. Переформатирование же сгенерированных файлов на precommit приведет к большим расхождениям между тем, что локально у человека, и тем, что в гите.
Про http имел в виду что таков дефолтный протокол для localhost - возможно, во фреймворке есть возможность включить https, но я, как говорил, не добрался до более глубокого изучения. Нужно это для одинаковой среды между локальным сервером и стендом.
Стандартная библиотека компонентов подойдет для маленькой CRM какой-нибудь студии, в крупных проектах требуется мощь Material UI или Antd, которые экономят громадное количество времени на разработку и легко интегрируются в Figma/Zeplin дизайнерами.
Под гибкостью я имел в виду свободу в организации файловой структуры. Может быть тут и есть import для подключения отдельных слоев (глобального апи, сторов, экшенов), но опять же я не добрался до архитектурных проб.
Может и браузерные кеш, но чтобы его не надо было отключать можно было бы contenthash дописывать к файлам.
Зачем засирать кеш, если достаточно один раз поставить галку?
держать тексты, даже дефолтные, в коде разметки - строгое табу
Это какое-то религиозное убеждение делать лишнюю работу или есть какая-то рациональная причина?
Стили в TS малопривлекательная идея, т.к. реимплементируют функциональность, которая проработана в многочисленных препроцессорах и плагинах
В каких таких препроцессорах и плагинах вы видели тайпчек стилей по иерархии владения компонент а так же семантичные имена классов с гарантией отсутствия конфликтов?
Стили должны быть отдельными для эффективного кеширования и не включаться в скрипты, раздувая их размер и ухудшая перфоманс.
И скрипты, и стили обновляются как правило вместе. Объём стилей не такой уж и большой получается - несколько килобайт. Выносить их в отдельный бандл, создавая дополнительную точку отказа, нет особого смысла.
Генерируются js-файлы из стилевых и шаблонных. Сами стилевые и шаблонные имеют синтаксис, вряд ли поддерживаемый ESLint, Prettier, Stylelint.
Какая разница как там отформатирован сгенерированный JS-код? Глазами вы его обычно не видите.
Опора на .editorconfig в проектах, в которых участвует не один разработчик не приводит к консистентности и не налагает достаточного количества ограничений.
Для любителей бондажа там есть настройки форматирования для VSCode. Впрочем, вы тут акцентируете внимание на совершенно не значительных вещах.
Про http имел в виду что таков дефолтный протокол для localhost - возможно, во фреймворке есть возможность включить https
Фреймворк-то тут при чём? Дев-серверу TLS не нужен. Если очень хочется - всегда можно поднять локальный прокси для ходьбы на локалхост через TLS.
Нужно это для одинаковой среды между локальным сервером и стендом.
Что дев-сервер забыл на стенде?
Стандартная библиотека компонентов подойдет для маленькой CRM какой-нибудь студии, в крупных проектах требуется мощь Material UI или Antd
В чём же заключается их мощь?
Под гибкостью я имел в виду свободу в организации файловой структуры.
Вам эта свобода нужна чтобы что?
Может быть тут и есть import для подключения отдельных слоев (глобального апи, сторов, экшенов), но опять же я не добрался до архитектурных проб.
В $mol используется концепции каналов и инверсии контроля, так что никаких глобальных апи, сторов, экшенов и прочего непотребства тут не нужно.
Кеш можно и не перегружать, но корректный 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 ни работал в маленьких примерах и бенчмарках - в целом концепт очень навязчивый и ограничивающий, в стиле "а мы пойдем своим путем" вместо того, чтобы развивать и развиваться вместе с общим потоком фронтенд-разработки.
Кеш можно и не перегружать, но корректный hot-reload без дополнительной возни обязателен.
Добавил, чтобы сервер требовал ревалидацию кеша. Больше таких проблем быть не должно.
Когда они хранятся в отдельных ts-файлах, как я сказал, можно их прогонять через любой шаблонизатор с нужными функциями
В $mol каждый текст вам доступен через отдельный канал. Он умеет динамически подгружать JSON бандл с локализацией на соответствующем языке, который экстрактируется из кода.
а при удалении ключей ругнется TS, при добавлении же неиспользуемых - ESLint
У нас сборщик ругается, если встречает лишние тексты. Если какого-то не хватает - фолбечится до английского.
Так ли приятно видеть скажем проект, в разметке которого масса арабских или китайских слов?
Там только английский.
Но всегда приятно, когда видишь семантическое
{getLn(messages.buttonReset)}.
Семантично - это что-то типа $my_sign_in_reset_label
И в сторах, и в разметке, и в экшенах, и в сайд-эффектах это основа проекта, нацеленного на распространение в другие страны.
Зачем вам переводы в "сторах, экшенах, сайд-эффектах", если они нужны исключительно для отображения пользователю?
Семантичные имена классов с гарантией отсутствия пересечений - CSS Modules, где класс
.tableбудет преобразован например по маске[folder]_[name]-[hash:4]и в итоговом коде будет.ModalProduct_table-1234.
Вот это вот 1234 имеет какую семантику? И чем оно отличается от 1235? Как переопределить стили у заголовка в компоненте карточки продукта на этой странице без повышения специфичности селектора, чтобы не ломать работу его псевдоклассов?
При этом в коде это будет просто
{styles.table}с любым семантичным ключом, не ограниченным фреймворком.
В $mol этот бойлерплейт писать не приходится вообще.
Тайпчек для css - однозначно лишнее, все проекты, в которых мы пробовали типизировать стили, в итоге приходили к мысли о бесполезности этого.
У $mol_style так-то нет аналогов. Вообще. Такого уровня тайпчека вы не встретите больше нигде. А на тех всех проектах была не стат типизация, а лишь её видимость.
Точка отказа в файле стилей - это что-то новенькое, не сталкивался ни разу.
Ну а я приодически натыкаюсь, что сайт загрузися и пытается тебе что-то показывать, а стили - нет. Да, собственно, чего далеко ходить:
CSS-файл обычно загружается параллельно с js и выполняется раньше него, улучшая метрики сайта.
Это распаралленивание ничего не даёт, ибо показывать что-то пользователю мы можем лишь когда и то и другое прогрузилось. А вот нагрузка на всех участников процесса возрастает пропорционально числу запросов.
благодаря постпроцессорам типа CSSO стили эффективно преобразуются и размер их кардинально уменьшается
На фоне сжатия все эти "оптимизации" являются пустой тратой времени. Я вам больше скажу - у нас даже JS не минифицируется, но бандлы получаются меньше, чем любимый вами стек даже без прикладной логики.
счет параллельной обработки браузером увеличивается скорость при открытии других страниц и при добавлении элементов на страницу, когда браузер уже знает как отображать новый элемент, а не получает инлайновый
style
Браузер получает stylesheet. Откуда он получен ему в принципе фиолетово. Более того, ему же проще, получить его сразу в виде CSSOM, а не парсить из текста. Опять же, даже с созданием этого стайлшита при загрузке, приложение на $mol грузится быстрее, чем пустая страница на React с параллельным парсингом ультраоптимизированного CSS.
Весь код в проекте должен быть в едином формате для простоты чтения и консистентности между разными разработчиками
А все разработчики должны ходить в пиджаках и брюках для консистентности перед начальством. Вы возводите в абсолют совершенно бессмысленные правила. Важно, чтобы код был ясным и понятным. Никакой автоформаттер не сделает ваш код более ясным для человека, чем это сделает сам человек. А вот испохабить его форматированием "по правилам" он может запросто.
VSCode - один из многих IDE
VSCode сейчас лучшая IDE для веб разработки. Поэтому с MAM в нём работать проще всего. Поддержкой других IDE сейчас заниматься некому, к сожалению.
намного эффективней выносить правила в ESLint, который поддерживается широким спектром редакторов и может выполняться на CI для проверки консистентности форматирования и стиля кода.
У меня вьетнамские флешбеки от зафейленных сборок из-за какой-то мелочи с форматированием. Да, собственно, чего далеко ходить:
Мощь готовых библиотек в соответствии функционала бизнес-требованиям.
Ни одна нетривиальная библиотека не будет соответствовать вашим требованиям на 100%. Поэтому важна кастомизируемость. А с этим у популярных фреймворков просто беда. В результате на доработки порой приходится тратить времени больше, чем на разработку с нуля. В $mol же мало того, что уже есть больше готовых библиотек, чем в любом другом UI-ките, так ещё и кастомизируются они куда проще.
Например, какие-нибудь ЯКарты - это мегабайт кода, монструозный апи и дикие ограничения по возможностям отрисовки. А $hyoo_map - это всего 50КБ кода и вся мощь $mol по кастомизации. Например, вот, взяли и прикрутили коллаборативное рисование на карте - бандл всгео 60КБ.
Свобода в организации файлов мне нужна для того, что жесткий подход в именовании файлов и их хранении - ограничение, которое может стать проблемой, как в том же Next.js, не позволяя совершенствовать архитектуру.
MAM очень слабо вас ограничивает: он лишь гарантирует, чтобы расположение сущностей соответствовало их именам. Странно, что вам, как любителю порядка и консистентности, это не по душе.
До каналов и инверсии я не добрался, но безусловно называть глобальные сторы и экшены непотребством - непрофессионально.
Не профессионально рассуждать о том, до чего не добрался. А процедурное программирование вокруг глобального дерева я, разумеется, пробовал. Для меня остаётся загадкой как такая тупая идея смогла захватить столько умов.
Я разрабатываю в трехуровневом стиле: глобальные-модульные-локальные, из которых локальные - практически не используются, так как есть масса задач, когда контролировать компоненты требуется из-вне и часто на самом верхнем уровне (тот же онбординг).
В $mol все компоненты хранят состояние по умолчанию локально, но при этом полностью контролируются владельцем, который может любое состояние как "поднимать", так и "опускать", и даже "сдвигать". Тут нет дилеммы между "контролируемыми" и "неконтролируемыми" компонентами. Это позволяет писать простой и ясный код, не теряя в гибкости и надёжности.
Онбординг, кстати, - это антипаттерн, который не работает так, как задумывается. Ибо пользователь хочет поскорее приступить к своим задачам и прокликивает этот онбординг не вникая. Но даже он на $mol реализуется гораздо проще, ибо в $mol, не смотря на инкапсуляцию, нет сокрытия. То есть вы легко можете достучаться до любого канала в приложении. И тайпскрипт всё это протайпчекает.
Как бы хорошо $mol ни работал в маленьких примерах и бенчмарках
На больших примерах он ещё лучше работает. Собственно, это сейчас единственный фреймворк, рассчитанный на экосистемы приложений и микросервисную разработку порталов. Ближайшим конкурентом был БЭМ, но он, считай, помер. Все остальные легко и просто смотрятся на каунтерах и привет-мирах, но чуть более сложное приложение и начинается ад.
"а мы пойдем своим путем" вместо того, чтобы развивать и развиваться вместе с общим потоком фронтенд-разработки.
Ну вот те, кто гнался за общим потоком сначала вкорячивали Flux и shouldComponentUpdate, потом переписывали всё на HOC и Redux, потом переписывали на Hook и MobX.. И судя по тому говнокоду, что людям приходится писать на хуках, это ещё не конец. Тем временем, в $mol как была абстракция реактивных каналов 6 лет назад, так никуда и не делась. Не смотря на то, что система реактивности дважды полностью переписывалась.
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, и в подходах с их использованием. Вполне возможно, что и вы со временем кардинально пересмотрите подход к фронтенду, по мере развития технологий всеобщими усилиями.
лучше держать только константы с базовым примером текста.
В $mol так и есть, только без ручного задания констант.
Только английский как основной не всем подойдет, это очередное ограничение.
Если что, сборщик никак не проверяет на английском вы там пишите или нет. Как раскладывать выгрузку из системы перевода вы решаете сами.
$my_sign_in_reset_label - это что? Доллар-моя-подпись-в-сбросе-надписи?
Скорее "моя-метка-сброса-входа".
Доллар зачем, название страницы зачем?
Это полная семантика от общего к частному.
Если "для уникальности" - то пусть об уникальности заботятся инструменты.
Так это инструменты и позаботились. Я выше кидал ссылки.
Реакте например через проп ,
Это так сработает лишь на один уровень вглубь и потребует тонны бойлерплейта.
в самом компоненте в его class будет два класса - дефолтный и переданный, так не сломаются псевдоклассы.
Надеюсь вы в курсе, что стили будут применяться не в порядке перечисления классов, а в порядке расположения css-правил, и ваша система сборки гарантирует корректный порядок склеивания правил?
каждый запрос к АПИ при фейле выдаст нотификацию (которая запускается через глобальный стор)
И что пользователю с ней делать? Я понимаю, что это самое дешёвое решение, но для пользователя это очень не удобно. Особенно на 4к мониторе.
но создавать на каждый запрос отдельный компонент нотификаций - это плохая практика
Создайте один и параметризуйте его кодом ошибки.
фреймворк решает за тебя, как будут называться классы, что является очередным ограничением
В данном случае человек лучше фреймворка не справится при всём желании.
работа с именованиями классов это отдельное искусство, цель которого - дать ясное представление о структуре элементов на сайте и их взаимосвязях
Это прекрасно отражено во view.tree описании компонента.
Безиерархичные стили и автогенерируемые классы ухудшают читаемость и понятность.
Вы опять придумываете небылицы, не ознакомившись с документацией. Не надо так, это понижает уровен дискусси.
Но ценность этого довольно низкая, так как лишние стили лишь добавят немного размера файлам
И добавят веселья при отладке.
Если брать картину в целом то мой любимый стек выигрывает по более важным параметрам
Каким же?
Ясный и понятный код у каждого свой. У одного это
$ { this.$ }, у другого yield* pipe(partial(sum, 1), multiply(3)).stream(), у третьего await StreamPipeUserControllerManager.emit('SuperLongNameFnFromThatModule'), у четвертого - императивный
Вы прекрасно проиллюстрировали, что линтер вам тут ни чем не поможет.
Правила нужны для того, чтобы код оставался консистентным, согласованным и каждый человек не переписывал код другого человека под свое понимание понятности.
Что плохого в том, что владелец кода пишет его так, как прежде всего ему удобнее с ним работать? Вы правда считаете, что "неудобно для всех" (а любой стандарт будет компромисом) лучше, чем "удобно хоть кому-то, и желательно тому, кто будет его отлаживать"?
VSCode лучшая только для тех, кто к ней привык
Это, объективно, не так. Иначе бы эта поделка не отжала львиную долю разработчиков у конкурентов.
делать только для нее - как раз "заставлять ходить в брюках и рубашке", как собственно весь $mol и заставляет
Давайте не гиперболизировать. Фреймворк никак не диктует вам, какую IDE использовать.
Нет, не лучшее, а видение одного человека
Чтобы такое утверждать не плохо было бы сперва ознакомиться с предметом обсуждения. Пока что мы слышим отв ас много домыслов, не соответствующих реальности, на основании которых вы делаете далеко идущие выводы.
Запрет на console.log в линтере - отличная практика, при необходимости сверху просто ставится // eslint-disable-next-line no-console
Отличная практика - помочь человеку освоить log-point-ы. А вот мусорить в коде - плохая.
Увеличивает внимательность сотрудников, охраняет чистоту консоли. Не доводилось работать в проектах, которые при открытии консоли выводят несколько страниц кому-то когда-то нужного текста для разработки?
Делать код-ревью по диагонали - тоже плохая практика.
С $mol либо так, как видит его создатель, либо никак. С Реактом как правило всех устраивает html-подобный синтаксис и жизненный цикл, а все остальное - гибкое.
Почему вы считаете архитектурные ограничения, накладываемые Реактом, более приемлемыми, чем ограничения на расположение файлов, накладываемые МАМ, и никак не влияющими на архитектуру?
Отсутствие сокрытия состояния и глобальный доступ - это и есть глобальность.
Возможность полиции зайти в любое помещение, не делает ваше жилище публичным домом.
сделать серию модалок
Модалки - это UX анти-паттерн, а серия - это вообще анти-паттерн в квадрате.
для меня состояние - это observable объект, а "канал" - функция изменения этого объекта из любого места
В $mol канал - это ещё и точка расширения, вы можете соединять каналы как угодно, перенаправляя информационные потоки как угодно. При этом состояние не дублируется по компонентам, каждый компонент всегда работает с актуальным значением, вычисления происходят в корректном порядке и не вызывают гличей. В отличие от обсерваблов с сайд-эффектами.
Flux, HOC, Redux, Hooks, MobX - лестница развития фронтенд-разработки.
По сравнению с $mol_wire всё это топтание на месте, а не лестница. Идеи, на которых он построен, появились задолго до появления Flux. А MobX даже не думает догонять.
Влезу в ваш диалог с вопросами по локализации.
Скажите, Вы реально работаете с проектами, где default locale - не английская?
Я много работал с локализациями и пришёл к выводу, что удобнее всего комбинированный подход:
Локали можно объявлять по месту использования
Локали можно объявлять в отдельном файле
id - или явный, или автоматический. Явный id меньше мешает рефакторингу, если не хранить историю изменений суррогатного.
А всю "магию" делает тулинг: вытаскивает в json всю инфу. Так мы всегда видим неиспользуемые локали. Дефолтная является технической: она тоже уходит в систему переводов. И уже подгружаемая подключается для пользователя.
Юзаю formatjs
Да, были проекты с дефолтной локалью на русском и арабском. Если в отдельном файле хранить - то id можно генерировать из __dirname - соответственно не будет пересечений с другими файлами и из такого id можно по большей части понять, где текст используется.
А как вы генерируете из разметки json-файл, если объявляете тексты по месту использования? Он попадает туда в шаблонизированном виде, который удобен для добавления склонений, множественного числа, переводов строк, форматов дат? Суть объявления в отдельных файлах как раз удобство генерации id, преобразования в json и контролируемых шаблонах, которые можно отредактировать в системе локализации.
В целом да, дефолтный текст уходит в систему переводов, а финальный приходит через апи-запрос при смене языка, это довольно эффективная схема.
Вы реально для арабского языка не использовали дефолтный русский/английский вариант? Это не усложняло разработку?
В коде пишем:$formatMessage({
id: 'id', // или автогенерация, функцию для которой можно переопределить
message: 'ICU_MESSAGE format',
description: 'опциональное описание, которое можем отдать переводчику'
}, { /* здесь передаем параметры, если есть */ })
Если хочется отдельным файлом, то просто объявляем объект с доступом по ключу:const messages = defineMessages({
greeting: {
id: 'app.home.greeting',
description: 'Message to greet the user.',
defaultMessage: 'Hello, {name}!',
},
})
Для дат, чисел, валют и т.д. есть свои форматеры. $formatNumber(3, {style: 'currency', currency: 'USD'})
Тулинг либы formatjs:
extract: в базовую локаль, которая уходит в систему переводов. Здесь хоть место в файле указывай.
compile: plane object 'id': 'ICU Message'. Или ast.
https://formatjs.io/
В коде объявлять имеет эффекты:
- пухнет шаблон
- все перед глазами: не нужно переключаться на контекст файла с текстами
- у нас гарантировано удаляются неиспользуемые локали
Понятно, да, если прогоняется все через функцию - тогда вытянуть тексты не проблема. Когда я имел в виду "держать тексты в шаблонах" подразумевал просто писать "some text" без функции. В вашем подходе не вижу недостатков - можно хоть в шаблоне, хоть в отдельном файле. Я обычно не использую сторонних инструментов и пишу просто
export const messages = wrapMessages({
hello: 'Hello {user}',
})а айди формируется автоматически из __dirname. Для экспорта в любую систему локализации - либо пробежаться по всем этим файлам простой регуляркой, либо выполнить во всех этих файлах wrapMessages, подменив ее функционал на JSON.stringify. Так получится JSON с [{id: 'pages/user/accordion.hello', value: 'Hello {user}'}] , что можно загрузить в любую систему локализации. В коде в соответствии с веткой и локалью запрашивается готовый JSON и кладется в стор, который уже является источником правды для текстов в коде. Если там значения нет - то выводится дефолтный текст из объекта выше.
С арабским у меня проблем не было, владею им) А так - для какого заказчика разрабатываешь, на таком языке как правило и дефолтные тексты. Неудобства не испытываешь, т.к. имена констант все равно на английском.
Вот view.tree же в коде будет просто:
<= Greting $mol_paragraph
title @ \Hello, {name}!И ничего не пухнет. Из этого автоматически сгенерится бандл с локализацией:
{
"$my_app_home_Greeting_title": "Hello, {name}!"
}
А можно вот это:
title @ \Hello, {name}!заменить на ключ?
И 2-й вопрос:
"$my_app_home_Greeting_title": "Hello, {name}!"А можно вот тут руками ключ задать? А текст вынести в файл? А то блин небольшой редизайн выдаст новые ключи, и привет — посыпались все переводы в онлайн сервисе.
Сама идея давать ключам имена по их положению в компонентном древе… спорная. Но к чёрту споры. Вопрос — система поддерживает ручной режим? Если да, то как он выглядит? Можно как-то переопределить поведение @?
А можно вот это заменить на ключ?
Можно вручную дёрнуть локализацию из TS:
greeting_title() {
return this.$.$mol_locale.text( 'my super key' )
}<= greeting_title \А можно вот тут руками ключ задать? А текст вынести в файл?
Конечно, кладёте рядом файл вида foo.locale=en.json и пишете туда всё вручную. Сборщик просто делает это автоматически из кода.
А то блин небольшой редизайн выдаст новые ключи, и привет — посыпались все переводы в онлайн сервисе.
В ключе лишь семантические имена, а семантика при редизайне обычно не меняется. Если же поменялась семантика - скорее всего перевод тоже надо поменять. Даже если в английском текст тот же - в другом языке всё может быть иначе.
Сама идея давать ключам имена по их положению в компонентном древе
Наоборот, имя не зависит от положения в дереве. Только от иерархии владения. Располагаться при этом они могут как угодно.
Можно как-то переопределить поведение
@?
Смотря что именно хочется поменять.
а семантика при редизайне обычно не меняется.
Хаха. Или это меня текущий проект с его безумной волатильностью травмировал. Но у нас древо компонентов без перетряхивания переводов меняется каждый после обеда. Эта схема для таких проектов нежизнеспособна.
Хотя вы ниже пишете, что речь не про компонентную модель...
greeting_title() {
return this.$.$mol_locale.text( 'my super key' )
}Не, это эребор. Нужны удобства.
Только от иерархии владения
Вот с этого момента начинается интересно. Что такое "иерархия владения"? Речь про модель данных?
Смотря что именно хочется поменять.
Чтобы можно было также просто (фантазия на тему):
<= Greting $mol_paragraph
title @ t('my_manual_key', { name })но с ручными ключами.
Не, это эребор. Нужны удобства.
Если очень хочется - можно завести универсальный канал:
l10n( key: string ) {
return this.$.$mol_locale.text( key )
}<= l10n!my_super_key \Вот с этого момента начинается интересно. Что такое "иерархия владения"? Речь про модель данных?
В любом приложении есть минимум 4 иерархии:
древо исходников (какой модуль частью какого является)
дерево наследования (кто от кого наследует реализации)
дерево владения (кто чьим управляет временем жизни)
дерево рендеринга (кто в ком и за кем находится)
Это всё ортогональные деревья. В терминах Реакта дерево владения образуют файберы, которые создаются для каждого VDOM узла, возвращённого из render функции. А сами VDOM узлы образуют дерево рендеринга. Дерево владения получается более плоским и не зависящим от того какой VDOM узел внутри какого отрендерен - для файбера их фаберы - непоследственные дети. За счёт этого, в частности, думаю работают и порталы, когда владеет один файбер, а рендерится всё в другом.
<= l10n!my_super_key \Вот это уже гуд. А параметры туда можно передавать? Типа <= l10n!my_super_key {param1} \?
В любом приложении есть минимум 4 иерархии
Но ведь fibers это и есть древо компонентов. А, если убрать порталы из рассмотрения, то это же и древо рендеринга (за парой оговорок). Про древо наследования не понял (реализации чего?).
Собственно я выше и писал, что у нас (не от хорошей жизни и точно не от большого ума), 7 пятниц на неделе, и по древу владения и по древу рендеринга всё гуляет. Железная привязка ключей по звеньям в этих древах будет регулярно ломаться.
Чем больше я думаю про идеальную i18n систему, тем больше она мне кажется такой:
- все переводы в jsonc файлах, в виде ключ-перевод, в древовидном виде
- над каждым переводом комментарием можно задать доп. информацию для переводчика (очень полезным оказалась такая штука в деле)
- автоматическая генерация
.d.tsпо такимjsoncфайлам, с поддержкой типизации параметров - переводы импортировать в .ts файлы напрямую (т.е. нужен как минимум json loader, как максимум свой самописный с какими-нибудь удобными обвязками)
- иерархию для экспорта во всякие po-ресурсы проводить с оглядкой на какое-нибудь meta-поле вида
"$scope: "where.this.i18n.branch.is",
Остальное как у всех.
Ещё вопрос про $mol. Есть поддержка слотов? Например есть UI:
<FormRow>
From <FromInput/> to <ToInput/>
</FormRow>Нужно закодировать from [[from]] to [[to]] в переводы. Вот так нельзя from, to, т.к. языки вроде казахского спасибо не скажут (там [[from]] from [[to]] to). Понятно что кейс специфический (хотя у нас таких мест штук 10 на проект наберётся). $mol шаблоны позволяют задать такое? Думаю да, просто интересно посмотреть как будет выглядеть View.
У нас такое выглядит так:
<FormRow>
<T
path="some key"
jsxParams={{
from: <FromInput/>,
to: <ToInput/>
}}
/>
</FormRow>Насколько я помню в аналогичных либах (у нас самописная) подход примерно такой же.
Если не указывается id, то как сохранится история изменений id? Рефакторинг структуры - это неизбежно рано или поздно. А на id локали завязываются, например, клиентские кастомизации.
Но про "пухнуть" я имел в виду совершено другое:
gender_of_host, select, "
"female {"
"{num_guests, plural, offset:1 "
"=0 {{host} does not give a party.}"
"=1 {{host} invites {guest} to her party.}"
"=2 {{host} invites {guest} and one other person to her party.}"
"other {{host} invites {guest} and # other people to her party.}}}"
"male {"
"{num_guests, plural, offset:1 "
"=0 {{host} does not give a party.}"
"=1 {{host} invites {guest} to his party.}"
"=2 {{host} invites {guest} and one other person to his party.}"
"other {{host} invites {guest} and # other people to his party.}}}"
"other {"
"{num_guests, plural, offset:1 "
"=0 {{host} does not give a party.}"
"=1 {{host} invites {guest} to their party.}"
"=2 {{host} invites {guest} and one other person to their party.}"
"other {{host} invites {guest} and # other people to their party.}}}}"Если не указывается id, то как сохранится история изменений id?
id формируется из того, что до собачки и имени владельца. То, что после собачки в id не попадает.
Но про "пухнуть" я имел в виду совершено другое:
Такие монструозные "человекопонятные" тексты - это боль. Как для разработчика, так и для самого пользователя, который не может быстро выцепить важную ему инфу, а вынужден вчитываться в толмуды текста.
Лучше так:
Invitation
Host: Jin
Guests: John +5
А если изменится "до собачки" - то к переводчикам уйдут новые тексты для переводов?
–
Синтетический пример просто описывает многообразие возможностей. В каком-нибудь текстовом квесте может таких текстов набрать множество, кстати.
В вашем же примере можно писать host/hosts и guest/guests в зависимости от количества элементов справа.
Простое из реальной практики: no coins, 1 coin, N coins. Три варианта. Можно, конечно, ограничиться одним и понадеяться на квалификацию переводчика. Но все равно же нужно проверить самому.
А "как лучше" обычно решает не разрабочик, хотя в стартапах ещё возможно продвигать свои решения и идеи.
А если изменится "до собачки" - то к переводчикам уйдут новые тексты для переводов?
Да, конечно.
В вашем же примере можно писать host/hosts и guest/guests в зависимости от количества элементов справа.
В этом нет необходимости в такой формальной записи. Просто используем множественное число там, где может быть больше одного значения. И единственное, где не может.
А "как лучше" обычно решает не разрабочик
Можно привести расчёты накладных расходов на разработку, поддержку, тестирование, удвоенную работу переводчиков, затраты времени ользователя и тд.
Да, конечно.
Так это плохо
В этом нет необходимости в такой формальной записи.
Это была шутка.
Можно привести расчёты ...
"Как лучше для пользователя" - чаще всего разработчик не обладает компетенциями для формирования этого решения
А затраты и т.д. - околонулевые, если озаботиться этим вопросом заранее.
Так это плохо
Почему?
А затраты и т.д. - околонулевые, если озаботиться этим вопросом заранее.
Поддержка кучи текстов - это очень не нулевые затраты.
Рефакторинг ведет к изменению ключей. Предлагаете всегда писать идеальный код? Я же уже писал, что на ключ перевода могут быть завязаны внешние системы.
У меня другое понимание стоимости поддержки "кучи текстов".
Только, если рефакторинг привёл к изменению семантики, а в этом случае переводы всё равно надо чекать.
А вы оценивли стоимость перевода одной строчки на 30 языков?
а в этом случае переводы всё равно надо чекать.
Представим систему, которую делаем мы, но тексты переводов для которой управляемы пользователем.
А вы оценивли стоимость перевода одной строчки на 30 языков?
Переводы стоят в диапазоне 0.05-0.5$ за слово * N языков.
Строк, которые имеют plural form, на самом деле, всегда мало. Я тут на своем проекте глянул: ни одной на 5к ключей. На предыдуших проектах было чуть больше, но не более 1%.
Но это не значит, что можно не поддерживать формат ICU Message
Лучше так:
Нас всё равно никто спрашивать не будет. Так что поддержка плюрализации вынужденная боль.
Жалко что сейчас документации недостаточно, чтобы в $mol въехать. Если будете еще разбираться, лучше зайдите в чат https://t.me/mam_mol , хотя бы с проблемами там можно быстро разобраться.
В целом, боюсь что сейчас у вас неверное представление. $mol сильно отличается, от других решений, тут багаж знаний скорее мешает разобраться.
Зачем засирать кеш, если достаточно один раз поставить галку?
Поведение браузера с "disable cache" и без очень разное. Гораздо лучше работать локально без неё, чтобы потом не заниматься отловом cache-based багов на тестовом сервере или проде.
Всё таки кеширование это сложный и неотъемлемый элемент веб-разработки. Чем ближе ваше дев-окружение к настоящему, тем меньше граблей вы соберёте в проде.
Гораздо лучше работать локально без неё
Пробовал - не понравилось. Дебажиться очень трудно, меняешь код, а поведение не меняется, и это выносит мозг.
Про cache-based баги лучше подумать отдельно.
Пробовал — не понравилось.
Собственно причиной тому у вас, скорее всего, было то, что cache на уровне dev просто непродуман. В идеале он может быть устроен почти также как и в prod-е
Про cache-based баги лучше подумать отдельно.
Они бывают слишком хитрые. Я столько этого наелся (всякие CDN, CORS, и просто двойные загрузки), что прямо "нафиг-нафиг". У меня доходило до дебага https2 запросов через wireshark.
Поведение браузера с "disable cache" и без очень разное.
Именно, и быстро переключается одной галкой. Вообще, я стараюсь по максимуму задействовать нативные девтулзы, а не лепить сбоку какие-то кастомные.
Я понимаю, как вы пытаетесь это подать, но снаружи это выглядит скорее так:
- для работы в dev-режиме необходимо отключать кеш (и, соот-но держать дев-тулзы открытыми)
- для dev разработки на мобилке нужно пробрасывать adb и отключать кеш на десктопных дев-тулзах
- о реальных кеш-related проблемах узнавать уже с прода (в худшем случае не узнаёте)
- разработка чего-то с прогревом кеша — постоянно toggle-ить галочку "disable cache"
И при этом это называется не "мы пока не довели до ума dev-кеширование", а "стараюсь задействовать нативные тулы".
Дело ваше, конечно.
На проде у вас один сервер, выдающий одни хттп-заголовки для статики. В деве у вас другой сервер, выдающий другие хттп-заголовки для статики. Дополнительно, на проде скорее всего статика раздаётся не напрямую, а через прокси какого-нибудь CDN. А локально вы через него не ходите. На проде одни тайминги, а локально абсолютно другие.
Так что давайте не фантазировать про приближенность локального дев-сервера к проду. Для этого обычно поднимается тестовый контур на продовой инфраструктуре.
А почему стал противником хуков? Хуки же реально проще для понимания, чем работа с классовыми компонентами.
Влезу в ваш разговор.
Проще для понимания маленьких и простых компонентов. Потом есть "средний размер и функционал", где хуки превращаю код в кашу.
Вот в этих комментариях описывал:
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
В первом же крупном проекте который делал на хуках пришлось писать длинные цепочки их вызовов с учетом результатов выполнения каждой (для сложного селекта и для онлайн редактора кода), что даже после нескольких итераций рефакторинга выглядело пугающе, в отличие от удобной компоновки в методах класса. Потом пришлось бороться с постоянным потоком ошибок от коллег-разработчиков в оптимизации и равенства по ссылкам при использовании длинной лестницы вложенных хуков. Это стало основными причинами нелюбви, к которым добавились впоследствии те, что описал в комментариях выше.
Сложная логика на хуках выглядит кошмарно, согласен. Все эти обвесы useCallback и проч.
Мне нравится такой подход: логика уезжает в классы (некоторые из них - сторы мобх). Экземпляры классов хранятся в рефах, то есть живут, пока жив компонент-владелец. Могут прокидываться вниз через контексты. А хуки - только как связующее звено: создание/хранение экземпляров, резолв зависимостей, очистка перед удалением, контексты. Гибкая схема, на основе которой можно всякое мутить без лапшекода, нормально декомпозировать и легко писать юнит-тесты как на логику, так и на компоненты.
Любопытно сравнить отношение к чужому труду тут и на международном medium
Ваш труд, то есть мнения, ценны тем, что они имеют отношение к истине, а не априори потому, что озвучены. Выходите из информационного пузыря и учитесь отстаивать своё мнение, если уж высказываете что-то столь непопулярное.
Если убрать из статьи категоричность, то стек как стек: я бы писать на таком не стал, но каждый кодит как он хочет.
Что еще удивляет, почему 40+ пользователей добавили статью в закладки, но не поставили +. Если вы хотите использовать результат работы другого человека, ну уделите хотябы 5 секунд, чтобы сказать "спасибо".
Возможно добавившие в закладки не имели достаточной кармы, чтобы поставить плюс?
Очень странно. Т.е кому статья не нравится, у тех есть карма ставить минус, а кому полезна, те не могут поставить +.
Есть интересно у Хабра канал для обратной связи. Это уже совсем косаяк PM такой вот user interaction реализовать.
Есть "мэйнстрим" и их не волнует, что разработчики React просто смеются, когда слышат "стэйт менеджер", ну типа, была такая тема для конференции и про TS они ничего слышать не хотят, но только снисходительно улыбаются. Посмотрите интервью Интервью Наталии Теплухиной с Дэном Абрамовым + подкаст на Вебстандартах с ним есть, но это никого не убедит не смотря на то, что это, как бы разработчики собственно React и масштабы приложений у них high-end. Притом, что я интересом прочитал статью буквально за пару минут интереса ради. В чем-то согласен, в чем-то нет.
Интересный у вас вышел диалог.
Вы одновременно и поддерживаете ТС, и кидаете в него ссаной тряпкой, ибо он топит за Redux.
И Дэн не смеётся, он говорит, что redux не задумывался как параллельное отражение состояния всего приложения. Он говорит что поддержка этого состояния - сложно.
И он не является противником внешних сторов, судя по интервью. Скорее наоборот.
Возможно, есть "политика партии" снижения популярности redux в пользу встроенных решений.
Реакты - дно, некст - тем более, редукс - муть а статья - легаси-рефлексия.
Но все плюсы что есть отдаю за верные слова о тайпскрипт.
Всё остальное в мире жс можно принять с улыбкой или слепой но тайпскрипт, его не здоровое лобби это злючий мрак который должен уволили в свою ООО дыру и сдохнуть, вот тогда он действительно сделает то о чем поют его сторонники: наконец-то поможет программистам жс!
Не, ребят, серьезно, это уже чересчур. В 2022 писать, что TypeScript это хайп - это просто мракобесие какое-то.
Доказывать бесполезность TS через аналогию (или вообще доказывать что-либо через аналогию) - это демагогия, а не аргументация.
Typescript может быть полезен при разработке модулей для других разработчиков, так как это позволяет получить подсказки в стиле IntelliSense от IDE
А код в обычных приложениях вы только для себя пишите? Другие разработчики с вашими модулями не работают или других разработчиков просто нет? В этом и заключается одно из преимуществ типизации - вы перекладываете информацию, которая доступна только у вас в голове, в код, который потом будут читать другие. А в случае несоответствий контрактов между модулями компилятор вас об этом предупредит.
Ранее популярной опцией был также Material UI, но он уже несколько приелся, да и развивается не очень активно.
Вот на основании чего вы решили, что MUI не развивается? Смотрим статистику за последний месяц:
https://github.com/mui-org/material-ui/pulse/monthly
152 Merged pull requests | 71 Open pull requests | 133 Closed issues | 86 New issues
https://github.com/chakra-ui/chakra-ui/pulse/monthly
51 Merged pull requests | 7 Open pull requests | 52 Closed issues | 19 New issues
Почему вся статья про "Профессиональный React" состоит из голословных утверждений и субъективного мнения?
Спасибо за комментарий.
Я отвечу сразу на последний вопрос, и это даст ответ на предыдущие. Я считаю, что субъективное мнение гораздо интересней "объективного". Никому не интересен стэк, составленный по количеству пул реквестов, звездочек в гитхабе или еще какому-то объективному показателю. Это может сделать каждый без Хабра или других источников.
Что гораздо интересней, так это живое мнение живых людей, которые много лет работают над живыми проектами.
Никто никогда не читает одну статью и бежит делать то, что в ней написано. Любая статья — это маленький кирпичик в копилку знаний. Не согласие с тезисами статьи не должно означать, что она плохая. Тем более, если вы так любите цифры, то увидели наверно, что на гитхабе репо этой статьи имеет уже 40+ звезд и 6 форков. А раз она кому-та полезна, значит имеет право на существование.
Ну а «профессиональный» не значит лучший и идеальный. Наверняка существует несколько профессиональных стеков для решения фронтэнд задач. Я описал один. Это же не научая работа на тему «как надо писать фронтэд приложения, а как не надо»
Что гораздо интересней, так это живое мнение живых людей, которые много лет работают над живыми проектами.
Мнение без аргументации имеет приблизительно никакую ценность для других живых людей. А с аргументацией в статье у вас, простите, полный швах.
Только по аргументации можно восстановить ход принятия решений. Без неё — что я тут могу сказать на ваше "TS не нужен"? Может у вас очень оправданные условия для такого вывода, а может быть вы просто ретроград, который уже получает свои 300кк/нс, и теперь работает исключительно на то, чтоб стать абсолютно незаменимым (т.е. неувольняемым) человеком в компании?
Это статья не про тайпскрипт. Совсем не про тайпскрипт. Он даже не входит в список основным тем. Я рекоммендую тайпскрипт обсуждать в других статьях.
Это один из вопросов, затронутых в статье, взятый как пример. С остальными так же всё плохо.
Redux — кучка антипаттернов, глобальная переменная в пределах приложения, адский оверинжиниринг со связями уровня все со всеми, бла бла бла...
Эта статья не про redux
Typescript не про "подсказки в IDE", это в первую очередь клей приложения, механизм в десятки разов упрощающий решение проблем технического долга, бла бла бла
Эта статья не про Typescript
SSR ни разу не "a must". И вообще мало каким приложения рекомендуется. Более того сам подход SPA мало каким задачам нужен. А большинство тех кому нужно SEO не нужны SPA, бла бла бла бла
Эта статья не про SEO и не про SSR
Ну и т.д… Тебе тут уже несколько раз очень правильно расписали, что "С остальными так же всё плохо". И то что концепт JS + Next.JS + Redux + R-Saga + Axios это рабочая и популярная схема, не делает его даже рекомендуемым. Уж тем более рандомному ынтерпрайз приложению.
Поэтому у статьи оценка 0. И да я помню, помню. Ты уже писал что мы "лузеры", "хейтеры", жалкие "неудачники", не уважающие чужой труд, и "без уважения к старшим". И да я помню, что "подрастёшь поймёшь". Хорошо хоть здесь ты об этом не пишешь, хехе.
Но концепт хабра прост. Ты публикуешь. Ты получаешь критику. Не нравится критика — твои проблемы. Аргументация "моё мнение, имею на него право" никому не интересна. Аргументация "а на {medium | dev.to | иная помойка} мне дали 4 лайка" тоже не интересна. Аргументация уважайте чужой труд — тоже не интересна. Интересны фактические доводы изложенные в статье и в комментариях к ней (всем известный факт — на хабре комментарии почти всегда полезнее статьи). А сам факт того что материал явился на свет очень малоценнен сам по себе.
Наиболее разумный подход, столкнувшись с критикой, как минимум в неё вникнуть. А "люди заносят статью в избранное, но не лайкают, негодяи", на "хабре сидят одни токсики, они не лайкают и не уважают мои труды" — это, пардон, какой-то инфантилизм. С тем же ты, вероятно, столкнёшься на реддите, если выберешь достойный сабреддит, где будут толковые ребята с опытом. Они тоже ни поставят ни в грош сам факт стараний, а будут оценивать именно сам материал. Ну и там тоже не жди развёрнутой критики, т.к. оная обычно подразумевает куда больше работы, чем провёл автор. Но хотя бы ориентиры обозначат. А дальше дело за автором. Обидеться на мир злобных людей, не оценивших нетленку, или, всё таки, подумать, а что было не так? В подаче материала? В высказваниях? В самих доводах? Несколько пунктов сразу?
Наверное я зря об этом пишу.
Не боитесь, что с таким отношение к авторам комментировать скоро будет нечего?
Или авторы проходя через боль и унижения будут все равно писать?
Или останется только группа людей которая друг другу нахваливает тайпскрипт, мобикс и не видит других мнений, потому что другие мнения заминусованы и авторы пошли доучиваться после фидбэка на Хабре?
У нас есть, например, сиятельный Дмитрий Карловский (nin-jin), который как только перешел от статьей "один я в белом пальто" к статьям "рассмотрим детально вот эти и эти аспекты фронт-разработки (а еще один я в белом пальто)" — так сразу перестал быть "заминусованным мнением".
Еще раз, мнение есть у каждого, и просто высказанное — оно чрезвычайно малоинтересно. Сильно более интересен анализ фактов, меньше — просто факты, еще меньше, но всё еще "пойдет" — подробная аргументация. А написать "я считаю что N" — невелика ценность.
Ага, nin-jin прекрасный пример эрудированного умного человека с токсичными soft-skills. Но т.к. человек в теме и умеет очень глубоко копать, то несмотря на тонну хейтерства в его адрес (часто заслуженную), он вписывается нашу экосистему "токсичных лузеров" и радует нас прекрасными нетленками (это не ирония, я очень рекомендую его статьи и многие комментарии). И это не смотря на то, что nin-jin открыто хейтит почти всё, что не $mol. Но ведь аргументировано хейтит. Со многими аргументами сложно спорить.
как только перешел от статьей "один я в белом пальто" к статьям "рассмотрим детально вот эти и эти аспекты фронт-разработки (а еще один я в белом пальто)" — так сразу перестал быть "заминусованным мнением".
Да нет, моя карма болталась около нуля, пока я не хайпанул статьёй про поисковики, где была куча вбросов о наболевшкм и минимум технических деталей.
Не боитесь, что с таким отношение к авторам комментировать скоро будет нечего?
Я на хабре давно. Так было всегда. И ничего. Схема не идеальна, но она работает. Это не коммунизм, который идеален, но его нигде нет. Это как капитализм. Куча критики, куча недостатков, но как-то работает. Жизнеспособная схема.
Или останется только группа людей которая друг другу нахваливает тайпскрипт
Аргументированную статью против TS тоже заплюсуют и она тоже выйдет в тренды (такое вроде уже не раз было). Просто будет ниже в рейтинге. Ей будет сложнее пробиться. Например Климов топит против TS. Напиши он свои мысли здесь с той же аргументацией что в его видео, я уверен, это будет блокбастером недели на хабре. Я хоть и не согласен с Климовым, но в его рассуждениях есть зёрна истины и его доводы валидны. И они у него есть. В общем было бы что писать.
мобикс и не видит других мнений
Ну вот наш mobX тролль уже скоро 3 аккаунт будет регистрировать, из-за своих безапеляционных нападок на всё что не mobx. Пример регулирования кармы в действии. Система сопротивляется троллям как может.
Профессиональный React стек для создания сложных приложений в 2022 году