Comments 39
Использовать React Context вместо стейт менеджера здорового человека(MobX'a) это конечно нелепость вселенского масштаба.
Ну почему же?) есть маленькие проекты, есть большие. есть проекты где правильно изолируют логику. Есть то где плохо разделяют логику от интерфейса. каждому своё.
Данный подход используется повсеметсно. но тот же Redux используется чаще. Но его в понимающих кругах не любят. как и Mobx.
Тот же effector очень хорошо, НО имеет нереальный порог входа)
Остаётся или редакс или контекст. и в большинстве случаев выбор падает на контекст. но работать с ним умееют еденицы. Библиотека и решает те проблемы с которым сталкивается каждый!
Но его в понимающих кругах не любят. как и Mobx.
Не любят MobX? В поминающих кругах? Вы может сделали опечатку и хотели сказать в не понимающих или в кругах любителей write-only кода?
Вообще что за странное утверждение в котором адекватные люди не любят MobX.
а вы однако однолюб :)
В кругах в которых понимают минусы каждого из подхода. если вы ещё не дошли до осознаний минуса библиотеки. Вам это ещё предстоит. нет единого решения - в каждом есть свои минусы и плюсы.
В кругах в которых понимают минусы каждого из подхода
И какие же минусы у MobX? Настоящие, а не бред сивой кобылы только, по типу он якобы весит много(ничтожный процент по сравнение с весом целого приложения real world), якобы дебажить приложение сложнее(если руки из жопы, то ничего не спасет конечно)
Вам это ещё предстоит
С 2016 года использую React + MobX и что-то как-то больше нет альтернатив, только лютый говнокод в виде голого react'a, redux(и похожего шлака), effoector, recoil и т.д. и т.п. А я предпочитаю писать нормальный код, человеко-понятный, и не бороться с проблемами которые сами себе создают те, у кого redux головного мозга.
Вы наверное из мира джавы пришли, где обмазываетесь декораторами и наследованием классов.
Сделайте комбайн сторов или зависимый стор на мобх (спойлер, такого не получится)
Так что не надо говорить про человеко-понятный код на мобх, где куча доп утил, которые работает когда им захочется (autorun,makeAutoObservable)
Коммуникацию между сторами так вообще говорят обходить надо и это считается нормальным решением?
>>This is library help u with solve problem with rerenders and simplify DI to your pages.
Ребят, вы серьёзно?
>>// @ts-ignore const useBlabla
Это, извините, детский сад какой-то.
хоть кто то нашёл пасхалку)
а по поводу // @ts-ignore я написал что типы не описаны до конца, есть возможность помочь. не хватает времени и в опен сорс и проекты писать.
а про серьёзность темы оптимизации не очень ясно в чём консёрн? есть вариант лучше оптимизировать работу с контекстами велком с предложениями) а так выглядит больше как сюр какой то а не комментарий.
Сюр это ваш английский язык, вообще-то. Я бы постеснялся такое писать, неужели гугль транслейт не помог?
Нет, просто у вас предложение составленно некорректно. Ну это ладно, я сейчас в пример залез и пока что мне из примера не очень понятно где же все-таки плюсы по сравнению с классическим Redux?
Этот подход лучше чем классический контекст — если ваш контекст делает больше чем 1 действие (что бывает достаточно чаще если у вас приложение сложнее чем калькулятор) то например если вы храните в глобальном контексте, юзера, количество нотификаций и например тему. при обновление ЛЮБОГО из этих параметров у вас будут рисоваться ВСЕ слушатели (например пользователь в шапке + нотификации + все компоненты что используют тему). данный подход избегает этих ререндеров. внутри библиотеки есть простой кейс который на 2х параметрах сравнивает скорость работы в 1000 кликов.
чем больше данных и слушателей тем больше разрыв.
И второе преимущество, вам не нужно искать среди сотни ваших хуков какие же внутри зависимости. здесь они указываются явно. Чистые функции всегда лучше)
Ну и третье преимущество, контекст не является стором. мы это исправляем функцией createStore которая реализовывает весь бойлер плейт по генерации контекста и стейта который мы потом спускаем вниз. тем самым создавай «подобие стора»
если же говорить про редакс. этот способ сильно отличается от редакса так как связан напрямую с поведением реакта. но так же позволяет описывать бизнесс логику вдали от UI.
При сравнение скорости работы — я уверен что будет плюс минус одинаково. но тут скорее важна чистота и понятность. Что достаточно субъективная штука. но от боейлер плейта редакса не деться) по этому выбирать редакс в 2022 уже как то плохо.
Эффектор классный НО имеет нереальный высокий порог входа. 95% если даже не больше НЕ знают эфектор.
Всё это имхо. Статья была написана чтобы поделится своим опытом кому это нужно. Если вы считаете что ваш опыт отличается — в этом нет ни чего плохого! мне или вам ещё стоит многому научится. Возможно я или вы не правы!)
По теме английского понял, возьму уроки английского! исправлю как будет время!
Неявный DI (неясно какие сторы есть на странице и какой из десятков хуков имеет зависимость на стор).
Не уверен, что эта проблема была исправлена. Пусть в хуках нет вызовов useContext, но ведь всё равно на странице будут компоненты, обернутые в connectContext, которые используются в других компонентах, и т.д. Вот так и получается, что где-то на странице есть обращения к тем или иным стейтам. Разницы с useContext никакой.
В неявном DI - вся суть контекста: компоненты с useContext на борту предполагают, что где-то выше по дереву значение будет предоставлено. Никаких контрактов, чтобы это гарантировать, нет (Реакт ещё и немного усугубил, возвращая дефолтное значение контекста, если вдруг забыли провайдер).
Да, поддерживаю что данное решение не гарантирует, что где то сверху есть объявленный провайдер. НО если взять за правило что у страницы указываются ВСЕ сторы что используются такой проблемы не будет!
Мы используем в рамках своего достаточно большого проекта десятки сторов в разных страницах. Если есть сомнения есть ли контекст. просто открываешь страницу где используется компонент и проверяешь) не надо искать десятки мест. всего одно.
Мы используем Next.JS в качестве основного фрейма. Полёт отличный на протяжение нескольких лет. просто решил запаблишить только сейчас. и стали активно развивать тоже только сейчас так как окончательно отказались от СТМ в пользу контекстов.
Ну то есть у вас проблема с неявными DI на самом деле решена строгим учетом используемых сторов/провайдеров?
Мы используем в рамках своего достаточно большого проекта десятки сторов в разных страницах. Если есть сомнения есть ли контекст. просто открываешь страницу где используется компонент и проверяешь) не надо искать десятки мест. всего одно.
Некоторые сторы могут быть и более глобальными, чем страница. Например, в типовом SPA провайдер вполне может быть выше по дереву, чем Router, чтобы сохранять данные между переходами.
если смотреть в структуру приложений next.js то там это _app.js который является глобальным. можно конечно же туда размещать все сторы - только большинство из них используются на определённых страницах. глобальные сторы по типу нотификаций и прочего мы конечно же размещаем там.
в будущих статьях я детальнее расскажу о решение тех или иных проблем с хранением или управлением данных. на самом деле у меня есть пет проект который я бы хотел выложить с учётом всех применимых решений в статьях и приложить финальный пример. боюсь просто что уйдёт много времени
А можете объяснить, почему вам не подошёл https://beta.reactjs.org/reference/react/useSyncExternalStore и было нужно именно Context-base хранилище?
Понадобилось управлять состоянием в небольшом проектике, взял storxy, не жалею
Удалённ.
А зачем это всё. Для маленького проекта есть множество различных маленьких менеджеров состояния.
На моей практике прекрасно себя показали: valtio, zustand, preact/signals, причём сейчас я больше склоняюсь к последнему.
У signals хороший коллектив авторов – создатели Preact (а значит, ничтожна вероятность того, что проект закроют, когда автору он надоест), у него отличные биндинги к React, отличная документация.
За 10 лет моей практике в 99% приложениях СТМ был лишним (Redux/Mobx/Effector) всё это можно было реализовать куда проще на стейте, и куда быстрее. и порог вода в проект снижается каласально.
Отсюда спустя время мы стали постепенно внедрять эту практику в компании.
И на данный момент полёт отличный, используем около 3х лет данный подход. Не рекомендую его использовать всем поголовно, это не серебряная пуля. но в большинстве случаев в моей практике этого было достаточно с головой, лишь на паре проектов у нас приложение сильно выростало, и нам приходилось всё это дело оптимизировать. из за чего и появилась данная библиотека. просто вначале появилась только у нас в репе. потом уехало в монорепу компании. и теперь в паблике :)
используем около 3х лет данный подход.
- Уверены что во множественном числе?) Может вы все таки один на проекте с таким подходом к написанию кода) Как бы управлять состоянием так, как это сделано в реакте и react-way подходе - это просто брать себя за голову и окунать в чан с говном. Поэтому всё адекватные люди уже много лет используют MobX в паре с ректом.
- Представляю какой там "красивый, понятный и поддерживаемый" код скопился с такими подходами)
И на данный момент полёт отличный
Да ладно? :D Это как "В принципе цены нормальные, если ничего не покупать"
За 10 лет моей практике в 99% приложениях СТМ был лишним (Redux/Mobx/Effector)
Да, если проекты реальные не писать, то стейт менеджер будет лишним, впрочем как и сам по себе код) HTML + CSS за глаза)
у нас приложение сильно выростало, и нам приходилось всё это дело оптимизировать
Вангую - разумеется это был не MobX, ибо там оптимизировать нечего, всё и так из коробки оптимизированно.
Там нечего учить. У Signals всего одна страничка, освоить которую можно за 15 минут. По поводу простоты – ну не знаю, куда проще-то. API из 4 (четырёх) функций, из которых вы постоянно будете использовать 1 (реже 2, а 2 остальных ну очень редко).
Зачем на любой чих создавать стейт, провайдера, оборачивать в этого провайдера поддерево (а если в стейте ссылочный тип данных, то для оптимизации ререндеров заворачивать эти данные в мемо), если можно просто создать вне дерева компонентов наблюдаемую переменную, и в любом месте приложения считывать её велью?
Не ругайтесь, я начинающий)
А чем людям redux не нравится, в чем его минусы?
Redux ведь подходит как и маленьким так и большим проектам?
А чем людям redux не нравится, в чем его минусы?
Redux ведь подходит как и маленьким так и большим проектам?
Это максимально убогое и не удобное решение, которое кроме лютого говнокода и костылей ни чего дать не может. Чтобы не тратить время в пустую просто используйте MobX и забудьте обо всех проблемах.
В целом уже ответили, по сабжу - высокий порог входа в проект, много бойлерплейт кода. Очень не удобный апи.
Mobx не решает всех проблем но решит часть проблем Redux.
Библиотека так же не решает всех проблем. Напротив имеет базовые проблемы которые есть на уровне хуков и контекста. Но она и не предназначена для того чтобы решить их все.
Mobx не решает всех проблем
Решает абсолютно все и каждую. Без вариантов. Если руки не из того места, то дело не в молотке и гвоздях.
вы в каждой бочке затычка? высказывайте своё мнение в одном треде, без спама. Тут уже все всё поняли.
Интересное решение. Плюс не большой порог входа. Тот же MobX который многие тут нахваливают могут не знать все в команде и там его изучение потребует больше времени. Можно взять всем известный редакс, но там свои минусы. Но к сожалению нет серебряной пули на все случаи потому тут всегда будут споры. Просто нужно совместно с командой выбрать то что подходит именно в вашем случае и вам.
Тот же MobX который многие тут нахваливают могут не знать все в команде и там его изучение потребует больше времени
Максимум максимумов это 1час и ты знаешь MobX. А вообще 20-30 минут и ты его знаешь.
Это конечно супер если в команде все так быстро схватывают, но не редко команды подбирают где есть те кому потребуется побольше времени. Ну и за 20 минут можно разве что доку пролистать быстро даже не почитав вдумчиво. Наверное о нормальном понимании за это времени речи не идет разве что узнать основы. Потому мне кажется важнее учитывать команду, а не подбирать технологию с которой всем нужно будет ознакомится. Даже если вся команда знает например редакс который мне не нравится. Скорее его выбрать будет правильнее чем ломать всех участников команды и мучая их примеру mobx.
Управление состоянием в React приложениях