cпасибо за статью. но на самом деле контекст статьи в сравнение двух библиотек управления запросами. и финал был сделан на основе библиотеки управления состоянием приложения vs состоянием запроса)
ну и redux приплели зря - этот вопрос касается не только redux и т.п
Хотел обратить ваше внимание что у вас при изменение любого из полей обновляется ВСЯ форма и если вы объявите форму где то в районе страницы это приведёт к большим проблемам с оптимизацией. Я бы рекомендовал реализовать работу формы через контекст и использованием инстанса формы для получения текущего состояния формы (трогали ли поле, упала ли валидация, если упала то какая из и взять её ошибку и в этом стиле) и компонент обёртки <Field> который бы расширял компонент чилдрена всякими onBlur и прочими эфектами в зависимости от типа тригера сам.
спасибо за статью! Возможно и мне хватит времени на реализацию библиотеки)
так обе части приложение пишутся в одном окружении - а в случае микрофронтов ты не знаешь куда встраивается твоё приложение по этой причине они должны быть изолированы
ну как же не влияет - первое приложение требует ресета стилей второе нет. вся суть проблемы что если одно приложение использует другое то они оба получат эти стили. в чанке обоих это будет существовать. и номральной изоляции кроме как вебкмпонентов и iframe в данный момент не существует)
Основная проблема как по мне не подсвечена. а как же изолирование приложений? если у вас допустим есть приложение главной страницы которое ресетит стили и есть часть другого приложения которому ресет стилей не нужен? тоже самое касается кода.
по работе со сторами я согласен что это проблема - но не такая большая. создаём стор хранения всех модулей и общаемся с ними через события не сообщая напрямую приложению что то а только лишь эфектами. тем самым нужные части приложения подхватят эти события. само собой слой стора должен быть обновляемый и доступен для редактированию всем членам команды и это тот самый 5 пункт. а так же очень низкая отказоустойчивая.
спасибо за статью, чуть ранее писал про удобное использование контекстов статью которая решает все эти проблемы. В целом ваш способ позволяет пошарить состояние из кастомного хука. но это не решает ни как проблему не явно DI. так как с таким подходом может быть хук в хуке внутри которого хук. и вы заколебаетесь искать виновника который рендерит ваш компонент)
Ни кто ни кого не вводит в заблуждение, я лишь указываю на факты - в которые вы по какой то причине не хотите верить. это ваше право. Но пытаться доказывать это другим не нужно.
В целом уже ответили, по сабжу - высокий порог входа в проект, много бойлерплейт кода. Очень не удобный апи.
Mobx не решает всех проблем но решит часть проблем Redux.
Библиотека так же не решает всех проблем. Напротив имеет базовые проблемы которые есть на уровне хуков и контекста. Но она и не предназначена для того чтобы решить их все.
тут речь о том что вам не нужен отдельный стм для маленького проекта. не нужно учить как работает та или иная библиотека! Вы просто пишите свой код как и писали раньше, просто оптимизируете его лучше.
За 10 лет моей практике в 99% приложениях СТМ был лишним (Redux/Mobx/Effector) всё это можно было реализовать куда проще на стейте, и куда быстрее. и порог вода в проект снижается каласально.
Отсюда спустя время мы стали постепенно внедрять эту практику в компании.
И на данный момент полёт отличный, используем около 3х лет данный подход. Не рекомендую его использовать всем поголовно, это не серебряная пуля. но в большинстве случаев в моей практике этого было достаточно с головой, лишь на паре проектов у нас приложение сильно выростало, и нам приходилось всё это дело оптимизировать. из за чего и появилась данная библиотека. просто вначале появилась только у нас в репе. потом уехало в монорепу компании. и теперь в паблике :)
К сожалению это событийная модель которая очень плохо дебажиться. Плюс писать код в событийной моделе достаточно тяжело. по этой причине проще использовать баховый подход который предлагает React.
если смотреть в структуру приложений next.js то там это _app.js который является глобальным. можно конечно же туда размещать все сторы - только большинство из них используются на определённых страницах. глобальные сторы по типу нотификаций и прочего мы конечно же размещаем там.
в будущих статьях я детальнее расскажу о решение тех или иных проблем с хранением или управлением данных. на самом деле у меня есть пет проект который я бы хотел выложить с учётом всех применимых решений в статьях и приложить финальный пример. боюсь просто что уйдёт много времени
Да, поддерживаю что данное решение не гарантирует, что где то сверху есть объявленный провайдер. НО если взять за правило что у страницы указываются ВСЕ сторы что используются такой проблемы не будет!
Мы используем в рамках своего достаточно большого проекта десятки сторов в разных страницах. Если есть сомнения есть ли контекст. просто открываешь страницу где используется компонент и проверяешь) не надо искать десятки мест. всего одно.
Мы используем Next.JS в качестве основного фрейма. Полёт отличный на протяжение нескольких лет. просто решил запаблишить только сейчас. и стали активно развивать тоже только сейчас так как окончательно отказались от СТМ в пользу контекстов.
а в статье не упоминается сравнение с редакс)
Этот подход лучше чем классический контекст — если ваш контекст делает больше чем 1 действие (что бывает достаточно чаще если у вас приложение сложнее чем калькулятор) то например если вы храните в глобальном контексте, юзера, количество нотификаций и например тему. при обновление ЛЮБОГО из этих параметров у вас будут рисоваться ВСЕ слушатели (например пользователь в шапке + нотификации + все компоненты что используют тему). данный подход избегает этих ререндеров. внутри библиотеки есть простой кейс который на 2х параметрах сравнивает скорость работы в 1000 кликов.
чем больше данных и слушателей тем больше разрыв.
И второе преимущество, вам не нужно искать среди сотни ваших хуков какие же внутри зависимости. здесь они указываются явно. Чистые функции всегда лучше)
Ну и третье преимущество, контекст не является стором. мы это исправляем функцией createStore которая реализовывает весь бойлер плейт по генерации контекста и стейта который мы потом спускаем вниз. тем самым создавай «подобие стора»
если же говорить про редакс. этот способ сильно отличается от редакса так как связан напрямую с поведением реакта. но так же позволяет описывать бизнесс логику вдали от UI.
При сравнение скорости работы — я уверен что будет плюс минус одинаково. но тут скорее важна чистота и понятность. Что достаточно субъективная штука. но от боейлер плейта редакса не деться) по этому выбирать редакс в 2022 уже как то плохо.
Эффектор классный НО имеет нереальный высокий порог входа. 95% если даже не больше НЕ знают эфектор.
Всё это имхо. Статья была написана чтобы поделится своим опытом кому это нужно. Если вы считаете что ваш опыт отличается — в этом нет ни чего плохого! мне или вам ещё стоит многому научится. Возможно я или вы не правы!)
По теме английского понял, возьму уроки английского! исправлю как будет время!
а по поводу // @ts-ignore я написал что типы не описаны до конца, есть возможность помочь. не хватает времени и в опен сорс и проекты писать.
а про серьёзность темы оптимизации не очень ясно в чём консёрн? есть вариант лучше оптимизировать работу с контекстами велком с предложениями) а так выглядит больше как сюр какой то а не комментарий.
все аргументы из статьи почему enum плох разваливаются об ТС5 (намберы пофиксили) или о понимание почему важно использовать Branding для перечисления.
const enum лучшее решение.
cпасибо за статью. но на самом деле контекст статьи в сравнение двух библиотек управления запросами. и финал был сделан на основе библиотеки управления состоянием приложения vs состоянием запроса)
ну и redux приплели зря - этот вопрос касается не только redux и т.п
Хотел обратить ваше внимание что у вас при изменение любого из полей обновляется ВСЯ форма и если вы объявите форму где то в районе страницы это приведёт к большим проблемам с оптимизацией. Я бы рекомендовал реализовать работу формы через контекст и использованием инстанса формы для получения текущего состояния формы (трогали ли поле, упала ли валидация, если упала то какая из и взять её ошибку и в этом стиле) и компонент обёртки <Field> который бы расширял компонент чилдрена всякими onBlur и прочими эфектами в зависимости от типа тригера сам.
спасибо за статью!
Возможно и мне хватит времени на реализацию библиотеки)
зависит от того как будут чанки собираться и на чём всё это будет работать. В целом решение вполне рабочее.
так обе части приложение пишутся в одном окружении - а в случае микрофронтов ты не знаешь куда встраивается твоё приложение по этой причине они должны быть изолированы
ну как же не влияет - первое приложение требует ресета стилей второе нет. вся суть проблемы что если одно приложение использует другое то они оба получат эти стили. в чанке обоих это будет существовать. и номральной изоляции кроме как вебкмпонентов и iframe в данный момент не существует)
Основная проблема как по мне не подсвечена. а как же изолирование приложений? если у вас допустим есть приложение главной страницы которое ресетит стили и есть часть другого приложения которому ресет стилей не нужен? тоже самое касается кода.
по работе со сторами я согласен что это проблема - но не такая большая. создаём стор хранения всех модулей и общаемся с ними через события не сообщая напрямую приложению что то а только лишь эфектами. тем самым нужные части приложения подхватят эти события. само собой слой стора должен быть обновляемый и доступен для редактированию всем членам команды и это тот самый 5 пункт. а так же очень низкая отказоустойчивая.
p.s сверху хейтеры у которых есть только redux/mobx и асинхронные сторы :)
у меня под статьёй так же насрали
спасибо за статью, чуть ранее писал про удобное использование контекстов статью которая решает все эти проблемы.
В целом ваш способ позволяет пошарить состояние из кастомного хука. но это не решает ни как проблему не явно DI. так как с таким подходом может быть хук в хуке внутри которого хук. и вы заколебаетесь искать виновника который рендерит ваш компонент)
Ни кто ни кого не вводит в заблуждение, я лишь указываю на факты - в которые вы по какой то причине не хотите верить. это ваше право.
Но пытаться доказывать это другим не нужно.
вы в каждой бочке затычка? высказывайте своё мнение в одном треде, без спама. Тут уже все всё поняли.
В целом уже ответили, по сабжу - высокий порог входа в проект, много бойлерплейт кода. Очень не удобный апи.
Mobx не решает всех проблем но решит часть проблем Redux.
Библиотека так же не решает всех проблем. Напротив имеет базовые проблемы которые есть на уровне хуков и контекста. Но она и не предназначена для того чтобы решить их все.
За 10 лет моей практике в 99% приложениях СТМ был лишним (Redux/Mobx/Effector) всё это можно было реализовать куда проще на стейте, и куда быстрее. и порог вода в проект снижается каласально.
Отсюда спустя время мы стали постепенно внедрять эту практику в компании.
И на данный момент полёт отличный, используем около 3х лет данный подход. Не рекомендую его использовать всем поголовно, это не серебряная пуля. но в большинстве случаев в моей практике этого было достаточно с головой, лишь на паре проектов у нас приложение сильно выростало, и нам приходилось всё это дело оптимизировать. из за чего и появилась данная библиотека. просто вначале появилась только у нас в репе. потом уехало в монорепу компании. и теперь в паблике :)
это полноценная библиотека по управлению состоянием - ещё и событийная. слишком много проблем можно получить вытекающих.
Не имеет смысла увеличивать порог входа на проект и увеличивать сложность проекта.
Опять же таки - моё имхо!
К сожалению это событийная модель которая очень плохо дебажиться. Плюс писать код в событийной моделе достаточно тяжело. по этой причине проще использовать баховый подход который предлагает React.
если смотреть в структуру приложений next.js то там это _app.js который является глобальным. можно конечно же туда размещать все сторы - только большинство из них используются на определённых страницах. глобальные сторы по типу нотификаций и прочего мы конечно же размещаем там.
в будущих статьях я детальнее расскажу о решение тех или иных проблем с хранением или управлением данных. на самом деле у меня есть пет проект который я бы хотел выложить с учётом всех применимых решений в статьях и приложить финальный пример. боюсь просто что уйдёт много времени
Да, поддерживаю что данное решение не гарантирует, что где то сверху есть объявленный провайдер. НО если взять за правило что у страницы указываются ВСЕ сторы что используются такой проблемы не будет!
Мы используем в рамках своего достаточно большого проекта десятки сторов в разных страницах. Если есть сомнения есть ли контекст. просто открываешь страницу где используется компонент и проверяешь) не надо искать десятки мест. всего одно.
Мы используем Next.JS в качестве основного фрейма. Полёт отличный на протяжение нескольких лет. просто решил запаблишить только сейчас. и стали активно развивать тоже только сейчас так как окончательно отказались от СТМ в пользу контекстов.
Этот подход лучше чем классический контекст — если ваш контекст делает больше чем 1 действие (что бывает достаточно чаще если у вас приложение сложнее чем калькулятор) то например если вы храните в глобальном контексте, юзера, количество нотификаций и например тему. при обновление ЛЮБОГО из этих параметров у вас будут рисоваться ВСЕ слушатели (например пользователь в шапке + нотификации + все компоненты что используют тему). данный подход избегает этих ререндеров. внутри библиотеки есть простой кейс который на 2х параметрах сравнивает скорость работы в 1000 кликов.
чем больше данных и слушателей тем больше разрыв.
И второе преимущество, вам не нужно искать среди сотни ваших хуков какие же внутри зависимости. здесь они указываются явно. Чистые функции всегда лучше)
Ну и третье преимущество, контекст не является стором. мы это исправляем функцией createStore которая реализовывает весь бойлер плейт по генерации контекста и стейта который мы потом спускаем вниз. тем самым создавай «подобие стора»
если же говорить про редакс. этот способ сильно отличается от редакса так как связан напрямую с поведением реакта. но так же позволяет описывать бизнесс логику вдали от UI.
При сравнение скорости работы — я уверен что будет плюс минус одинаково. но тут скорее важна чистота и понятность. Что достаточно субъективная штука. но от боейлер плейта редакса не деться) по этому выбирать редакс в 2022 уже как то плохо.
Эффектор классный НО имеет нереальный высокий порог входа. 95% если даже не больше НЕ знают эфектор.
Всё это имхо. Статья была написана чтобы поделится своим опытом кому это нужно. Если вы считаете что ваш опыт отличается — в этом нет ни чего плохого! мне или вам ещё стоит многому научится. Возможно я или вы не правы!)
По теме английского понял, возьму уроки английского! исправлю как будет время!
хоть кто то нашёл пасхалку)
а по поводу // @ts-ignore я написал что типы не описаны до конца, есть возможность помочь. не хватает времени и в опен сорс и проекты писать.
а про серьёзность темы оптимизации не очень ясно в чём консёрн? есть вариант лучше оптимизировать работу с контекстами велком с предложениями) а так выглядит больше как сюр какой то а не комментарий.