Comments 77
Добавьте голосование чтоли=) Отдам голос за mobx
А GraphQL ещё актуален или уже всё?
Почитал и не понял почему стоит отказаться от Redux + Redux Toolkit в серьёзном продакшн если предположить, что команда в него уже умеет, а в Recoil нет, да и последний всё ещё в разработке.
Да, старое. Но это похоже единственный недостаток Redux. Зато хорошо поддерживаемое, стабильное и проверенное временем.
Не единственный. Redux создаёт тонны boilerplate. С эти можно бороться, если создать фабрику редьюсеров, но это ж надо сделать
Звучит как «ну чтобы нормально было, надо нормально делать». :)
Мы его ещё с reselect и immutability-helper используем.
Звучит как все настолько обленились что ищут какой-то идеальный инструмент который решил бы все их проблемы из коробки. Но думаю такого не бывает. Через год ждем статью почему я перешел с recoil на....
Не совсем. Если посмотреть на доки redux, то там именно предлагается копипастить. Не все же сразу знают про то, что бывают фабрики. По-умолчанию новичок будет именно следовать доке, т.е. безбожно попипастить.
Recoil — это не более, чем нескучный Mobx, потому что кому-то надо было Mobx, но не Mobx.
Но это похоже единственный недостаток Redux.
Редакс не умеет идиоматически описывать события — когда у вас что-то произошло, и вам просто надо сайдэффекты. В терминах редакса это всегда превращается в монстров, когда пишут в стейт какие-нибудь пустые объекты (для change detection), и запускают рендер компонентов, когда он по факту не нужен (редакс не умеет просто сообщить в реакт о факте изменения стейта, это обязательно сопровождается рендером).
Из-за этого всего неаккуратная попытка создания в редаксе сайдэффектов на какие-нибудь частые события (scroll, мыша) может очень легко отожрать весь процессор и привести к тормозам на ровном месте. При этом весь код будет написан "по заветам" официальной документации.
Минуточку, но редакс не для того. Не надо скролл в него писать.
Что значит "не для того"? Скролл так и вовсе очень легко бывает полноценной частью стейта, а не заглушкой чисто для сайдэффектов. Стейт-менеджер, в котором тут стейт, тут не стейт, а тут рыбу заворачивали?
Значит, что можно писать скролл в стейт, но нужно же ещё учитывать базовые особенности Javascript да и вообще правила хорошего тона (читай производительности).
Итак весь современный интернет тормозит. Посмотрите вокруг.
Да что далеко ходить, это форма ввода комментария, на самом специализированном сайте для разработчиков и то тормозит.
но нужно же ещё учитывать базовые особенности Javascript
А при чем тут "базовые особенности Javascript", если я могу взять тот же Mobx, минимальные знания о реакте (чтоб не запускать рендер на каждый scroll event), и у меня ничего тормозить не будет? Может, дело таки не в Javascript?
А уж если реакт исключить из уравнения, то и тем более, чтоб сделать откровенно тормозящую обработку скролла — придётся что-то особенное придумывать.
Вообще кстати (не сочтите это за персональный выпад, я это далеко не первый раз наблюдаю) очень показательно, что современные модные фронтэндеры частенько на голубом глазу заявляют что-то типа "JS тормозной, с ним нужно аккуратно!". Хотя по факту JS был очень даже неплох еще 15 лет назад, а в нынешнее время так и вовсе летает. Но обычно никто не хочет задумываться над тем, а сколько же именно кода выполняется в модных популярных библиотеках типа реакта, когда вы вроде бы почти совсем ничего не делаете.
Потому что причина "итак весь современный интернет тормозит" — она не в том, что JS медленный. Она в том, что "весь современный интернет" — он, типа, ничего особенного и не делает… ой, как это весь процессор сожрали?? Это не мы, мы ничего особенного не делаем!
Всё правильно Вы говорите, я тоже именно об этом и говорю.
Если мы говорим про современных модных фронтэндеров, то они даже не понимают как React устроен и во что компилируется их красивенький ES6 и как это работает в браузере.
В 2000-х был медленный интернет, медленные браузеры, и мало возможностей у JS, и люди писали аккуратный производительный код. То что пишут сейчас меня иногда повергает в ужас.
Ну вот тогда вы должны понимать, почему меня напрягает редакс, в котором принципиально нет человеческого способа доставить обновление стейта в компонент реакта без рендера. Способ придумать можно, но будет несколько… нечеловечески.
Толко что дошло.
А зачем доставлять стейт в компонент если не надо рендерить? Что-то мне подсказывает, что не место ему в компоненте в таком случае.
Затем, что показать в браузере вещи можно гораздо быстрее, чем это делает реакт. В некоторых случаях — в сотни и тысячи раз быстрее. При работе с вещами типа скролла это имеет первостепенное значение, и "не рендерить силами реакта" — это и в 2021 году самый распространённый момент, когда на реакт кладётся болт и руками проделываются необходимые манипуляции в DOM.
Еще лучше, конечно, просто не иметь реакта (и любых других квадратно-гнездовых библиотек и фреймворков), но в кровавом энтерпрайзе это скорее не выйдет, чем выйдет.
Зачем вам тогда Реакт-компонент?
Не стоит смешивать логику и отображение.
Не стоит смешивать реакт и нон-Реакт.
Зачем вам тогда Реакт-компонент?
Компонентная отрисовка UI (безотносительно реакта) — отлично масштабируемый подход. Поэтому если у вас интерфейс сложнее хеллоуворлд — нет никаких причин отказываться от компонентного подхода.
Не стоит смешивать логику и отображение.
Где в моих комментариях вы видите указание на смешивание логики и отображения?
Не стоит смешивать реакт и нон-Реакт.
Вежливо спрошу — сфигали?
Реакт не является цельным нерасширяемым решением для создания абсолютно любых веб-приложений.
Не стоит смешивать реакт и нон-Реакт.
Смешивать можно, эта одна из основных фич Реакта, google-map-react не даст соврать (и куча других подобных оберток). Подозреваю, что без такой возможности Реакт вообще бы не взлетел.
У меня у самого есть вопросы к реализации вычислимых полей через селекторы, равно как и использование чистых функций в языке без даже намека на ссылочную прозрачность.
Но конкретно для вашего примера сразу несколько вариантов приходит в голову
Просто импортировать стор в компонент вручную и вручную привязаться к стору через subscribe внутри компонента, один раз при создании компонента.
Написать свою обертку вокруг useSelector, которая будет принимать на вход селектор и колбек, который нужно дернуть при изменении результата селектора. Внутри обертки дергаем useSelector со вторым параметром
(prev, next) => {if(prev !== next) {setTimeout(()=>callback(next))};return true}Тупо мутировать стейт, но тогда не понятно как передавать информацию об изменении, и почему просто не использовать отдельный синглтон
Первые два способа может и не совсем стандартные, но вроде должны работать.
Я правильно понимаю, что в компоненте есть ref на какой-то внутренний элемент, и надо с этим элементом что-то делать при некоторых изменениях редуксового стора, но без перерендера самого компонента?
Угу, в общем случае картина именно такая.
Это "императивный" подход, который авторы редукса не приветствуют, потому готового хука конечно же не будет, но легко сделать свой, по описанию выше от @DarthVictor
Ммм. Странно что миллионы продакшнов об этом утверждении не знают и успешно делают деньги на связке React + Redux.
Странно что миллионы продакшнов об этом утверждении не знают
Это у вас такое оправдание не знания? Логика «если большинство дураки, значит это норма и мне тогда зачем быть лучше» так себе, не только в профессии, а вообще в принципе по жизни.
С Вами очень сложно вести диалог, потому что Вы передёргиваете и выдаёте свои мысли за мои слова.
Редакс не мертворожденный, а вполне успешный, неидеальный и проверенный временем проект.
Редакс не мертворожденный, а вполне успешный, неидеальный и проверенный временем проект.
Вы в каком мире живете? В каком месте он успешный? Если его кто-то там использует по сей день не говорит о том, что он успешный и не мертворожденный, это лишь выставляет их в плохом свете и диком легаси.
Неидеальный? Да куда там, он реально ущербный, без шуток. Ну это же очевидно. Если вы это не видите и по сей день используете React + Redux, то у меня для вас плохие новости.
А вот MobX реально отличная штука в рамках возможностей языка, проверенный временем проект. И сознательно его игнорировать просто смешно и абсурдно. React юзабилен только в связке с MobX'ом, в противном случае унылое Г.
Да куда там, он реально ущербный, без шуток.
Напишите, пожалуйста, хотя бы 3 проверяемых аргумента этого утверждения. Очень интересно.
Напишите, пожалуйста, хотя бы 3 проверяемых аргумента этого утверждения. Очень интересно.
1) Иммутабильность
2) Лапшекод
3) Бойлерплейт
4) Чистые функции
5) Вообще в целом большая избыточность кода, «спасибо» иммутабильности и чистым функциям.
6) Лишние перерендеры
7) Необходимость борьбы с библиотекой и подключение зоопарка в виде саг, санок, реселеков и прочей ереси.
В чистых функциях как таковых ничего плохого нет, те же компутеды в МобХ - чистые функции. Просто ФП-шники любят сооружать из этих самых функций какие-то немыслимые вещи, в которых хрен разберешься без барреля крепкого пива.
Иммутабельность тоже бывает местами удобна, просто Редукс её агрессивно навязывает там, где не надо. Лишних перерендеров в принципе можно избежать, но таки придется упарываться с реселектами и проч. Скажем так - оптимизация рендеров более дорогая, чем с МобХ.
Immutability - недостаток. Куда катится мир?
Очевидно, если такая абстракция состояния плохо решает проблемы приложения, то все же стоит рассмотреть различные альтернативы. А так, если команда знакома с этим подходом, умеет его применять и готова ко всем его ограничениям, то аргумент устаревания для библиотеки, состоящей из 5-6 функций, достаточно странно было бы рассматривать. То есть я бы вообще не стал выделять это каким-либо критерием.
Но недостатки у redux есть. Для меня это в первую очередь сложность, того пути, который он предопределяет, при совершенно неочевидной отдаче. И мне он вообще скорее видится, как нечто, что решает довольно узкий класс проблем. Нечто такое, к чему можно даже неосознанно прийти в ходе решения какой-то локальной проблемы. В глобальном плане не вижу причин сдерживать код такими ограничениями, это если рассматривать redux как один из способов комбинирования чистых функций.
Кстати про то что с ним нужно уметь работать, это с одной стороны справедливо. А с другой, как мне кажется, это может порождать некое искаженное восприятие у новичков. Так как интерфейсы редакса очень просты, и может казаться, что задача сводится к изучению этого интерфейса, плюс к изучению пары-тройки других библиотек, чтобы уж точно все уметь. Будет как минимум не очень эффективно перекладывать проблему применения инструмента на тех, кто просто не знает и не понимает как с ним работать. Сам инструмент при этом ничего не объясняет, да и не должен, и не мог бы, даже при желании.
Только MobX, альтернатив увы нет.
Redux вещь очень хорошая, MobX вещь замечательная, но проекты у меня маленькие, на БТР за пивом в магазин не ездят, по крайней мере вне РФ. Пользуюсь Zustand. Буду благодарен за любую его критику, т.е. плохой опыт с Zustand. Чего стоит опасаться, если вы в курсе?
Поставил минус, так как нет самого сильного стейт-менеджера - эффектора. Но в принципе не удивительно, автор не русскоязычный, у них там проблемы с СТМ - всё заполонили проекты-однодневки вроде jotai, zustand и т.д, у которых авторы популярные опенсурсеры, пиарящие друг-друга. Ну и в комментах конечно же знакомые лица - те же самые мобхсеры, что и под каждой статьей про стейт-менеджмент. Такое ощущение, что это боты и им кто-то платит за комментарии.
Поставил минус, так как нет самого сильного стейт-менеджера — эффектора.
Лол, так эта дичь ещё хуже Redux'a, казалось бы куда ещё хуже, но есть куда. Логично что его тут не.
С каждой новой подобной статьей все больше хочется перейти на Vue. Почему-то там один стейт менеджер справляется с задачами, для которых в React сообществе понапридумывали сотню стейт менеджеров и продолжают придумывать новые. Там нет избыточного и переусложненного Redux, который не нравится даже его авторам, и при этом на Vue делаются проекты любой сложности, причем быстрее.
В наши дни существует несколько библиотек, позволяющих наладить работу с серверными кешами. Самым популярным решением такого рода является React Query
Никогда не щупал и не видел в проде, но очень много слышу про React Query.
Подскажите пожалуйста какую проблему оно решает, чтобы тащить в проект 50кб? Какая у него киллер-фича?
Пишут, что мол кеширование апи-запросов… но я как-то не могу представить случай где мне может подойти результат какого-то предыдущего 3сек давности запроса. Всегда лучше самый свежий результат.
А если в каком-то специфичном случае нужно организовать кеш — то несложно написать логику для этого.
Ммм, а зачем запросы делать из под компонентов? Делать запрос за списком категорий должен "слой", который отвечает за эти категории (слой, который ничего не знает про react). А там хоть десять компонентов пусть читают и рисуют эти категории.
Получается React Query - это 50кб-ый костыль для тех, кто делает запросы из-под каждого компонента которому нужны данные.. так что ли?..))
Если ваш слой отвечает за то чтобы кешировать и не запрашивать 2 раза при вызове, это значит у него есть своё состояние, а это гемор с реализацией событийной модели в этом слое и подписки реката на эти события, чтобы он знал когда состояние меняется.
50кб это в исходном виде с комментами, а в минифицированном сильно меньше
я ориентируюсь на эти данные react-query v3.19.1 ❘ Bundlephobia
50кб - это уже минифицированный. Плюс это "пережевать/распарсить" нужно.
а это гемор с реализацией событийной модели в этом слое и подписки реката на эти события, чтобы он знал когда состояние меняется.
в контексте обсуждений - mobx как раз решает весь этот "гемор".)
А как же effector ?
А как же effector ?
Так он даже хуже редакса, его стыдно в список засовывать. Вы ещё скажите, а где же XState, так это ещё на 2 порядка хуже чем redux и effector.
XState - это же не стейт-менеджер, а машина состояний
И чем он хуже редакса? Тем что не шарашит по всем компонентам на перерисовку в случае изменения данных? Тем что позволяет хранить любые данные, в том числе и инстансы классов в отличие от редакса? Ну и видимо тем, что весь необходимый код лежит в одном месте, а не в куче файлов раскиданных по всему проекту. Ну и видимо ещё тем, что эффектор код легко найти по зависимостям в коде, а редакс надо искать по магическим строковым константам? Ах да, может эффектор ещё хуже потому, что не требует дополнительных библиотек для реализации сайд эффектов?
И чем он хуже редакса?
Код который получается на выходе в реальной жизни, ещё хуже читается и воспринимается, он не очевидный, каждый раз без бутылки водки не разберешься, рекомендуемые доллары в названиях переменных тоже бредятина. Этого уже достаточно чтобы быть обреченным на погружение ко дну.
А вообще они оба ущербные, просто используйте MobX (не MST, а просто MobX) и все проблемы с состоянием больше перестанут быть проблемами. Сделаете намного лучше для себя и для окружающих.
Ах да, может эффектор ещё хуже потому, что не требует дополнительных библиотек для реализации сайд эффектов?
В редаксе это тоже не обязательно, есть же функция dispatch.
Редукс - это "вариант по умолчанию". Весьма напоминает ситуацию с Интернет-эксплорером в нулевые. Самый хреновый браузер был самым используемым. Так и сейчас: на "курсах по хэтээмелю" впаривают редукс, потому что с ним много вакансий, а вакансий много, потому что большинство реактеров знают только редукс, и из-за этого его используют (ну и конечно же много старых проектов).
А где упоминания хотя-бы о Effector, MST и классику RxJS. А упоминание useState уже показатель, что статью дальше читать не стоит.
А где упоминания хотя-бы о Effector, MST и классику RxJS
Так всё это ещё хуже даже redux'a (эталона всего плохого), логично что этого нет в списке.
RxJS так вообще лютая дичь. Это эталон в мире жестоких извращений.
RxJS для событийного кода очень даже неплох. Проблема с ним в качестве стейт-менеджера — в том, что начинается натяжение совы на глобус, идиом для нормального стейт-менеджмента не хватает. Итого идёт попытка подписать абсолютно всё под потоки событий (даже то, что ими не является), и начинается жесть.
А упоминание useState уже показатель, что статью дальше читать не стоит.
useState упоминается абсолютно по делу - в кейсах, где стейт не надо хранить, где никто не прольёт слезу от его потери по анмаунту.
Страшно все же жить в мире, где каждые полгода мета меняется
Последние 4 года вообще без изменений, React + TS + MobX полет шикарный. Все максимально актуально, быстро и тп) А вообще с реактом уже 6 лет, первые 2 года с реактом были болью и страданиями из-за redux'a, но потом узнал что такое MobX и все как рукой сняло.
Не знаю что вы там учите каждые пол года)
Последние годы только React + Typescript + MobX, идеальное сочетание.
К этому списку еще добавлю парочку:
- Zustand https://zustand.surge.sh/
- Easy Peasy https://easy-peasy.vercel.app/
Небольшое сравнение на npm trends https://www.npmtrends.com/easy-peasy-vs-mobx-vs-recoil-vs-redux-vs-zustand-vs-effector
Ссылка на Overmind битая, хотел глянуть что там, но не фартануло
Уже 3 года использую React + Typescript + MobX. Чем больше узнаю MobX тем больше он мне нравится. Я так и не понял зачем юзают Redux.
Я так и не понял зачем юзают Redux.
Банально из-за не знания того, что есть MobX и из-за лени просто посмотреть на него. Т.к. эта категория людей которые пришли в профессию только зарабатывать деньги, а не потому что им нравиться разрабатывать. В них нету предрасположенности к профессии, поэтому они пишут одноразовый write-only говно код, вместо того чтобы думать головой и делать вещи. Самое страшное, что для них не очевидно что они пишут говно, они думают что все правильно делают и у них хорошо получается.
На последней работе хотел все переписать на Редакс (писал на нем несколько лет), но сначала решил посмотреть как оно работает на МобХ. На редакс не стал переписывать и дела с ним иметь больше не хочу. Добавил для мобикса несколько базовых классов для разных целей: данные, страница, диалог, итд, а также общий базовый класс для поддержки иерархии и инициализации. Теперь класс состояния не требует даже конструктора, только логика и состояние и те частично в базовых классах.
Альтернативы Redux в 2021 году