cпасибо за статью. пользуюсь таким же подходом для генерации кода в проектах. хотим создать NPM репозиторий и вынести созданий страниц/экранов сущностей и фичей которые сейчас есть в проектах на основе Feature Sliced Design. стайл гайд может быть любым. мы генерируем сразу несколько разных файлов. компонент, типы, константы. всё отдельными файлами и структуру под них в зависимости от директории (фича, страница, сущность и т.д.) очень удобно!
cпасибо за статью. но на самом деле контекст статьи в сравнение двух библиотек управления запросами. и финал был сделан на основе библиотеки управления состоянием приложения vs состоянием запроса)
ну и redux приплели зря - этот вопрос касается не только redux и т.п
Хотел обратить ваше внимание что у вас при изменение любого из полей обновляется ВСЯ форма и если вы объявите форму где то в районе страницы это приведёт к большим проблемам с оптимизацией. Я бы рекомендовал реализовать работу формы через контекст и использованием инстанса формы для получения текущего состояния формы (трогали ли поле, упала ли валидация, если упала то какая из и взять её ошибку и в этом стиле) и компонент обёртки <Field> который бы расширял компонент чилдрена всякими onBlur и прочими эфектами в зависимости от типа тригера сам.
спасибо за статью! Возможно и мне хватит времени на реализацию библиотеки)
так обе части приложение пишутся в одном окружении - а в случае микрофронтов ты не знаешь куда встраивается твоё приложение по этой причине они должны быть изолированы
ну как же не влияет - первое приложение требует ресета стилей второе нет. вся суть проблемы что если одно приложение использует другое то они оба получат эти стили. в чанке обоих это будет существовать. и номральной изоляции кроме как вебкмпонентов и iframe в данный момент не существует)
Основная проблема как по мне не подсвечена. а как же изолирование приложений? если у вас допустим есть приложение главной страницы которое ресетит стили и есть часть другого приложения которому ресет стилей не нужен? тоже самое касается кода.
по работе со сторами я согласен что это проблема - но не такая большая. создаём стор хранения всех модулей и общаемся с ними через события не сообщая напрямую приложению что то а только лишь эфектами. тем самым нужные части приложения подхватят эти события. само собой слой стора должен быть обновляемый и доступен для редактированию всем членам команды и это тот самый 5 пункт. а так же очень низкая отказоустойчивая.
спасибо за статью, чуть ранее писал про удобное использование контекстов статью которая решает все эти проблемы. В целом ваш способ позволяет пошарить состояние из кастомного хука. но это не решает ни как проблему не явно DI. так как с таким подходом может быть хук в хуке внутри которого хук. и вы заколебаетесь искать виновника который рендерит ваш компонент)
Ни кто ни кого не вводит в заблуждение, я лишь указываю на факты - в которые вы по какой то причине не хотите верить. это ваше право. Но пытаться доказывать это другим не нужно.
В целом уже ответили, по сабжу - высокий порог входа в проект, много бойлерплейт кода. Очень не удобный апи.
Mobx не решает всех проблем но решит часть проблем Redux.
Библиотека так же не решает всех проблем. Напротив имеет базовые проблемы которые есть на уровне хуков и контекста. Но она и не предназначена для того чтобы решить их все.
тут речь о том что вам не нужен отдельный стм для маленького проекта. не нужно учить как работает та или иная библиотека! Вы просто пишите свой код как и писали раньше, просто оптимизируете его лучше.
За 10 лет моей практике в 99% приложениях СТМ был лишним (Redux/Mobx/Effector) всё это можно было реализовать куда проще на стейте, и куда быстрее. и порог вода в проект снижается каласально.
Отсюда спустя время мы стали постепенно внедрять эту практику в компании.
И на данный момент полёт отличный, используем около 3х лет данный подход. Не рекомендую его использовать всем поголовно, это не серебряная пуля. но в большинстве случаев в моей практике этого было достаточно с головой, лишь на паре проектов у нас приложение сильно выростало, и нам приходилось всё это дело оптимизировать. из за чего и появилась данная библиотека. просто вначале появилась только у нас в репе. потом уехало в монорепу компании. и теперь в паблике :)
К сожалению это событийная модель которая очень плохо дебажиться. Плюс писать код в событийной моделе достаточно тяжело. по этой причине проще использовать баховый подход который предлагает React.
если смотреть в структуру приложений next.js то там это _app.js который является глобальным. можно конечно же туда размещать все сторы - только большинство из них используются на определённых страницах. глобальные сторы по типу нотификаций и прочего мы конечно же размещаем там.
в будущих статьях я детальнее расскажу о решение тех или иных проблем с хранением или управлением данных. на самом деле у меня есть пет проект который я бы хотел выложить с учётом всех применимых решений в статьях и приложить финальный пример. боюсь просто что уйдёт много времени
Да, поддерживаю что данное решение не гарантирует, что где то сверху есть объявленный провайдер. НО если взять за правило что у страницы указываются ВСЕ сторы что используются такой проблемы не будет!
Мы используем в рамках своего достаточно большого проекта десятки сторов в разных страницах. Если есть сомнения есть ли контекст. просто открываешь страницу где используется компонент и проверяешь) не надо искать десятки мест. всего одно.
Мы используем Next.JS в качестве основного фрейма. Полёт отличный на протяжение нескольких лет. просто решил запаблишить только сейчас. и стали активно развивать тоже только сейчас так как окончательно отказались от СТМ в пользу контекстов.
Вас все еще не заблокировали? О.о
cпасибо за статью. пользуюсь таким же подходом для генерации кода в проектах. хотим создать NPM репозиторий и вынести созданий страниц/экранов сущностей и фичей которые сейчас есть в проектах на основе Feature Sliced Design. стайл гайд может быть любым. мы генерируем сразу несколько разных файлов. компонент, типы, константы. всё отдельными файлами и структуру под них в зависимости от директории (фича, страница, сущность и т.д.)
очень удобно!
шикарная статья! согласен почти со всем! спасибо большое что смогли так точно описать поворот не туда!
все аргументы из статьи почему 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 в качестве основного фрейма. Полёт отличный на протяжение нескольких лет. просто решил запаблишить только сейчас. и стали активно развивать тоже только сейчас так как окончательно отказались от СТМ в пользу контекстов.