CSS модули генерируют название класса исходя из названия компонента, где он находится. То есть, вместо прописывания руками .SomeModule_item в компоненте SomeItem, просто прописываешь item к нужному элементу. Поэтому найти его в коде так же легко как и бэм класс, а человеческий фактор в нейминге классов сходит на нет
В 2018 решил попробовать react native и запилить что нибудь для души. Сделал небольшую игру-тест, выкладывал только на андроид, из монетизации только гугловая Adsense, которая выскакивала после каждого пройденного теста. Удалось за год заработать аж 23$)
Есть много разных околобюджетных и бюджетных организаций не перейдут в облако в обозримом будущем по целому ряду "потому что". Плюс текущая политическая ситуация как бы намекает нам о том, что шансы быть отрезанными от внешнего мира с их SaaS вовсе не нулевые.
Эт я к тому, что всё, что делает мобх это "добавляет реактивности" нативному js классу. На мой взгляд, такой подход интуитивно более понятен, чем разучивать новые парадигмы в которых живëт тот или иной стейт менеджер.
декораторы можно не использовать, это дело вкуса. Вообще не понимаю, чего все вы так к декораторам прицепились, можно и без них писать. В любом случае в большинстве проетов стоят свои настройки сборщика и именно у вас на проекте все будет работать как и задумывалось изначально. А runInAction это алиас для action, в чём его спорность?
чуждый апи людям не знающим redux
Конечно, можно разобраться в архитектуре flux. Можно все время держать в голове, что у вас иммутабельность, и нельзя мутировать данные, можно делать flat store, потому что архитектура плохо работает с вложенными данными, можно писать много лишнего кода на пустом месте(селекторы) и тд и тп. А можно просто использовать инструменты, которые не налагают своих ограничений и позволяют сконцентрироваться на бизнес-логике это дело лично каждого.
про космические оптимизации вы конечно же загнули
Если в моем сторе есть данные вида User.details.personal.firstName и есть какой-то компонент который подписан только на firstName, он будет перерендериваться ТОЛЬКО если поменяется firstName. Effector так может из коробки?
Тут вопрос даже не в количестве кода, а в том, насколько понятно, что там вообще происходит. У Mobx нет никакой философии, это просто JS класс, который обычно используется как Singleton. То есть, если убрать из этого класса observable, action и computed, то в коде смогут разобраться даже далёкие от js люди. И всё это добро идёт вместе с космической оптимизацией, которую ни один immutable стейт менеджер априори не сможет дать без лишних телодвижений. Effector же как и Redux пытается как и редакс привнести какую-то свою идеологию или чуждый АПИ, который, скорее всего, понадобится только при работе с этим конкретным менеджером. Вот и возникает вопрос: зачем делать плохо, если можно сделать хорошо?
По опыту на разных проектах могу сказать, что глубоко вложенное поле может пройти путь через несколько селекторов, при этом они его будут модифицировать и в итоге задача на 5 минут легко растянется на час, учитывая, что дебажить селекторы ещё то удовольствие. И наличие такого кода есть минус самой архитектуры, которая позволяет такое накрутить.
Тоже использую, удобно, когда во время выполнения чего — либо надо показать юзеру модалку и дальше продолжать исполнение в зависимости от ответа, такой вот кастомный confirm, как вы и сказали.
Ее главная задача – адаптировать площадку, изначально заточенную на китайский лад, к реалиям Рунета и сделать ее понятнее и проще для русскоязычных пользователей.
А я тут было подумал, что на российских пользователях просто хотят заработать, а тут эвоно как, «понятнее и проще».
Вы удвоите скорость написания кода, если отрефакторите код в повторно используемые строительные блоки.
Искусство быстрого разработчика – это искусство писать повторно используемые строительные блоки.
Тут речь о том, что надо писать ВСЕ компоненты так, чтобы их можно было переиспользовать много раз в коде, с чем я искренне не согласен. Если ваше приложение чуть сложнее чем каталог продукции или личный блог, этот путь развития никуда вас не приведёт.
Этот компонент является монолитом, потому что он был спроектирован и написан для использования в одном месте в одном приложении только один раз.
И чё в этом плохого конкретно для этого компонента?
Искусство быстрого разработчика – это искусство писать повторно используемые строительные блоки.
Чем больше возможностей для повторного использования ваших компонентов и функций, тем вы быстрее.
Ну давайте тогда все компоненты делать переиспользуемыми, с десятками пропсов и сотнями if else внутри, чтобы потом красноглазить по вечерам и фиксить там баги.
По поводу мобилок хороший аргумент, по поводу кита не совсем согласен. На проекте может быть штук 7 разных шрифтов, это значит неизбежно появление small, superSmall, extraSmall и тд.
CSS модули генерируют название класса исходя из названия компонента, где он находится. То есть, вместо прописывания руками .SomeModule_item в компоненте SomeItem, просто прописываешь item к нужному элементу. Поэтому найти его в коде так же легко как и бэм класс, а человеческий фактор в нейминге классов сходит на нет
Этот хук не будет работать как ожидается без проверки статуса ответа
В 2018 решил попробовать react native и запилить что нибудь для души. Сделал небольшую игру-тест, выкладывал только на андроид, из монетизации только гугловая Adsense, которая выскакивала после каждого пройденного теста. Удалось за год заработать аж 23$)
Можно посмотреть в сторону cockpit headless cms, несколько лет назад он мне показался более выгодным по сравнению со strapi
Переезжать за лучшей жизнью в Крым на данный момент, как минимум, спорное решение)
Есть много разных околобюджетных и бюджетных организаций не перейдут в облако в обозримом будущем по целому ряду "потому что". Плюс текущая политическая ситуация как бы намекает нам о том, что шансы быть отрезанными от внешнего мира с их SaaS вовсе не нулевые.
А можете аргументировать, в чем заключаются недостатки классов и ООП?
Эт я к тому, что всё, что делает мобх это "добавляет реактивности" нативному js классу. На мой взгляд, такой подход интуитивно более понятен, чем разучивать новые парадигмы в которых живëт тот или иной стейт менеджер.
Конечно, можно разобраться в архитектуре flux. Можно все время держать в голове, что у вас иммутабельность, и нельзя мутировать данные, можно делать flat store, потому что архитектура плохо работает с вложенными данными, можно писать много лишнего кода на пустом месте(селекторы) и тд и тп. А можно просто использовать инструменты, которые не налагают своих ограничений и позволяют сконцентрироваться на бизнес-логике это дело лично каждого.
Если в моем сторе есть данные вида User.details.personal.firstName и есть какой-то компонент который подписан только на firstName, он будет перерендериваться ТОЛЬКО если поменяется firstName. Effector так может из коробки?
А я тут было подумал, что на российских пользователях просто хотят заработать, а тут эвоно как, «понятнее и проще».
Тут речь о том, что надо писать ВСЕ компоненты так, чтобы их можно было переиспользовать много раз в коде, с чем я искренне не согласен. Если ваше приложение чуть сложнее чем каталог продукции или личный блог, этот путь развития никуда вас не приведёт.
И чё в этом плохого конкретно для этого компонента?
Ну давайте тогда все компоненты делать переиспользуемыми, с десятками пропсов и сотнями if else внутри, чтобы потом красноглазить по вечерам и фиксить там баги.
Фантастический уровень самоиронии. Всем тем, «кому с Redux жить хорошо», на заметку
По поводу мобилок хороший аргумент, по поводу кита не совсем согласен. На проекте может быть штук 7 разных шрифтов, это значит неизбежно появление small, superSmall, extraSmall и тд.
Всё пытаюсь понять чем же запись p fontSize=15 более ужасна и менее понятна, чем Title size="small"