Comments 38
А почему сразу не дать людям которые начинают писать на реакте дружеский совет?
Использовать сразу MobX для управления любым состоянием в приложении, как глобальном так и локальном. Вместо того, чтобы зарывать себя и писать лютый говнокод, который не избежен когда используешь useState и useReducer.
Если не заниматься ерундой по типу добавления мешанины из простейших хуков без разделения на составные четко выраженные логические части в один компонент, оборачивать все подряд в useCallback и думать, что вы делаете производительный код, добавлять новый state там, где его нет (либо он напрямую зависит от другого state-а), передавать 100500 пропсов через 10 уровней вложенности, не зная, что такое контекст, заниматься копипастом и раздувать компоненты на 200 строк и более строк... Тогда да, это будет лютый говнокод. Да, я тоже раньше предпочитал MobX, но со временем смог оценить подход хуков, когда научился все разносить. Винить инструмент не надо, надо просто уметь им пользоваться. Вот вы умеете пользоваться MobX - и прекрасно, пользуйтесь! Я лично для себя сейчас больше предпочитаю хуки и пока не вижу кейсов использования MobX для себя. Хуки прекрасно декомпозируются, как и обычные функции: есть входные параметры, есть выходные, а дальше комбинируй как как нужно. Прекрасно отделяется view от логики, если это использовать правильно.
А так, дайте пример задачи на хуках, где нельзя будет не наговнокодить. Этим вы докажете свои доводы.
Мда, печально, что вы на полном серьезе так думаете. Вы можете разность хуки как угодно, но сам этот подход, управление состоянием приложения таким способом изначально убог и обречен быть лютым говнокодом. Такое чувство что вы пробовали это на Hello world, а не на реальном проекте который дошел до прода.
Приведите тогда пример, где хуки не подойдут. Какой смысл говорить, когда можно это доказать? В говнокод можно превратить все при недостатке квалификации, либо времени. Пока я вижу, что вы якоритесь (когнитивное искажение) на этом, как-то давно поняв/увидев по каким-то примерам, что хуки = говнокод.
Ну а проект - я не знаю, можно ли это называть Hello world-ом этот пет-проект (https://www.youtube.com/watch?v=6ia1rkQ--sU) + мобильное приложение с одновременной записью нескольких треков с бекендом тоже мои. Есть трансляция в реалтайм. Писалось потому, что было нужно в личных целях и альтернативы не нашел.
Так покажите тогда ваш не говнокод с хуками.
Весь код показать не смогу, т. к. не собирался делать его открытым, но некоторые полезные хуки, которые могут оказаться полезными, смогу показать, конечно. Сегодня, либо на неделе смогу что-то показать, думаю.
Ждёмс
Некоторые хуки, которые используются в проекте: https://learned-dungeon-cb7.notion.site/ddf1044de9e940b5b732926736b7b2f6
Код не раздувается таким образом, всегда есть возможность улучшить еще, с жизненным цикла реакте проблем нет, с производительностью проблем нет, подключаются хуки удобно, unmount с отписками также очень удобный. Лично для себя проблем не вижу, хотя раньше я тоже предпочитал MobX, когда не умел работать с хуками.
Что-то хуки с той страницы вообще не относятся к управлению состоянием. Какое отношение они имеют к обсуждению mobx vs useState?
Эмм, меня попросил человек скинуть пример своих хуков, я скинул, в чем проблема? Если мы говорим об управлении состоянием, то что именно вы под этим подразумеваете? Нужен конкретный пример задачи. Состояние - слишком абстрактное понятие, useState/MobX - слишком конкретное. Я не вам отвечал, как вы могли заметить. "Ничего не понятно, но минус поставлю" называется
5 страниц с формами по 20 полей допустим, у каждого поля есть валидация, отправка на бэк данных из этих полей. Всевозможные флаги типо показать скрыть какой-то блок. Вот в таком роде банальные задачи фронта как вы решаете. А то что вы скинули выше как заметил mayorovp не имеют отношения к управлению состоянием приложения и вообще никакого отношения не имеет к контексту useState vs MobX
С большими формами работал только на Vue (но там полей могло и больше 100 быть).
Для начала, я бы не стал писать велосипед: https://react-hook-form.com/
2-е. Если бы скрытие блоков начало превращаться в говнокод и скрывать надо было бы много всего + поля, которые скрыты, могли бы либо отправляться, либо не отправляться на бекенд, то придумал бы решение. Если бы была форма больше, подумал бы над разделением на блоки и над тем и думал бы, как лучше провайдить форму. Хуки рефакторить кто-то запрещает?
Все зависит от задачи и для разных проектов подойдут разные решения с разным уровнем абстракции той или иной части.
Т.е. вы никогда не имели реального опыта и практики писать самые распространенные задачи в различных вэб приложений на ректе, зато утверждаете что хуки(имеем ввиду управления состоянием с использованием useState) это круто, более того как минимум ни чем не хуже чем MobX, ещё и якобы вы раньше предпочитали MobX, но в реальности на реакте у вас и опыта получается что нет. Т.е. вы в своих фантазиях уже нафантазировали как все устроено, а к практике так и не перешли, но зато с удовольствием транслируете свои фантазии.
Огорчу, когда вы на практике начнете писать реальное вэб приложение, прямо типовое, и буду использовать для управления состояние реакт, т.е. useState вы просто ахренеете от жизни, насколько все получается громоздко, неудобно и вообще на все это без крови из глаз не взглянешь. Боже упаси если в этом коде обнаружится баг или нужно будет внести изменения в бизнес логику. Поэтому любой опытный разработчик который давно с React'ом использует его только в связка с MobX и никак иначе. Извращенцев, мазохистов и тех кто в танке в расчет не берем.
То, что вы взяли рандомную библиотеку в качестве react-hook-form(опять же огорчу, это такая-же полная хрень как и Formik и множество ему подобных, которая вставляет много палок в колеса и заставляет вокруг себя лепить тонны костылей) и якобы тем самым считаете что поступили правильно и не изобретаете велосипед, при чем в реальности в с ней даже ни разу не работали. Вообще все это говорит лишь о том, что вы только только вступили на путь разработчика, но уже ошибочно считаете себя опытным и прожженым.
Вы сейчас пытаетесь сделать вывод о моем опыте при недостатке информации. Так делать не надо, т. к. на ваши выводы влияет куча когнитивных искажений, которые искажают понимание. Я не пытаюсь делать никаких выводах о вас, т. к. понимаю, что я ничего про вас не знаю. Также, я не хочу сказать, что MobX хуже, просто лично я его предпочитаю меньше чем хуки. Точно также, при выборе Redux-MobX, я выберу MobX из этих двух для глобального состояния.
Перехода на личности от меня не ждите, т. к. я прекрасно понимаю, что квадратик с ником рядом и комментарием ничего не говорит о личности.
Поэтому, чтобы не заниматься ерундой и не разводить демагогию о том, у кого какой опыт (по комментарию же опыт определить проще всего, конечно же), приведите пример задачи, в которой нельзя будет ненаговнокодить, если ее делать на хуках. Не можете? Ну и о чем тогда говорить? Может быть, вы в итоге окажетесь правы - кто знает? Если вы так усердно говорите, что на хуках одну лапшу можно писать, приводите пример.
Похоже, примера не будет, только балакать умеем.
Возможно вы слепой, но я писал выше кейс где обсирается реактовский встроенный стейт менедмент в плане неудобного говно/лапше кода в итоговой реализации, вот ссылка на комментарий — https://habr.com/ru/post/660573/#comment_24266633
Вы сейчас тёплое с мягким сравнили. MobX лучше подходит для глобального состояния, useState и useReducer — для локального.
useState и useReducer — для локального.
Нет. Для локального MobX все равно гораздо лучше.
Чем оно лучше-то?
Рассмотрим простейший пример (если я ничего не перепутал):
function Foo() {
const [value, setValue] = useState();
return <>
<div>{value}</div>
<input onchange={e => setState(e.target.value)} />
</>;
}Куда вы сюда MobX засунете и зачем?
Вы привели синтетический пример из Hello World. В реальной жизни все далеко не так просто и такой банальщины нет.
Вот уже реальная жизнь:
function Foo() {
const [state] = useState(() => new FooState());
return <>
<div>Имя:{state.formFields.firstName.value}</div>
<Input formField={state.formFields.firstName} title="Имя" />
<Input formField={state.formFields.lastName} title="Фамилия" />
<Input formField={state.formFields.zip} title="Индекс" />
<Input formField={state.formFields.city} title="Город" />
<Button onClick={state.submit}>Сохранить</Button>
</>;
}Где FooState
export class FooState {
formFields = {
firstName: new FormField(''),
lastName: new FormField(''),
zip: new FormField(''),
city: new FormField(''),
}
submit = async () => {
// ..
validateFormFields(this.formFields);
const formData = getFormFieldsData(this.formFields);
// ..
}
}И этой логики обычно в рамках одного комонента на примере формы гораздо больше, с описанием валидациий и тд и тп. Описывать всё это используя хуки, это адская лапша и говнокод. Про то, что при каждом рендере все будет создаваться по новой, а не просто будут неизменные ссылки на объекы это вообще смешно и нелепо. Про заворачивание всего в useCallback/useMemo это так же смешно и нелепо писать лишний говнокод из-за того, что сам себя сознательно загнал в ловушку.
А описать все это используя обычный экземплрял JS класса гораздо читаемее, понятнее и оптимальнее.
Я вижу у вас не локальное состояние, а разделяемое, как минимум между двумя компонентами (Foo и Input), а реально тут наверняка будет их гораздо больше.
Кстати, обратите внимание, что вы тоже не смогли полностью отказаться от useState
Я вижу у вас не локальное состояние, а разделяемое, как минимум между двумя компонентами (Foo и Input), а реально тут наверняка будет их гораздо больше.
FooState это локальное состояние компонента Foo.
Кстати, обратите внимание, что вы тоже не смогли полностью отказаться от useState
Другого аналога constuctor'a у функционального компонента нет. Поэтому useState используется чисто для того чтобы создать и получить ссылку на экзмепляр класса который является локальным состоянием текущего компонента, который не будет пересоздаваться при каждом рендере.
Попробуйте написать эту форму на хуках и мы посмотрим, какая там будет лапша и вместе ее съедим :)
Я, кстати, не забыл, скоро вы сможете посмотреть на мой "говнокод" формы с хуками. Я не делаю супер-сложную форму, стараюсь вместить нюансы в маленькую (скрытие полей/блоков, валидацию, изменяемый список (массив) полей), форму в форме, кастомные контролы.
В целом я не считаю, что хуки победят по чистоте кода - думаю, можно и там, и там хорошо написать. Посмотрите на альтернативный подход, может, предложите свои идеи для улучшения/усложнения для задачи
Также для себя, может, что-то найдете и не будете так категорично относится к управлению состоянием на хуках.
Ждёмс
Готово)
Форма небольшая, но я постарался вместить туда основные моменты - валидацию, разделение на отдельные блоки, скрытие полей, форма в форме, массив полей и кастомные поля с валидацией.
В качестве библиотеки форм взял react-hook-form.
По итогу:
Никаких onChange/value, достаточно добавить только name для поля, но для этого надо заранее подготовить контролы.
Нет лишних перерендеров. Я подробно не изучал, но как понимаю, там внутри механизм publish/subscribe работает.
Легко перемещать блоки - достаточно просто перенести блок в разметке.
Демо: CodeSandbox
И этой логики обычно в рамках одного комонента на примере формы гораздо больше, с описанием валидациий и тд и тп. Описывать всё это используя хуки, это адская лапша и говнокод.
Предлагаю сделать вам эту форму на MobX. Миф, что на хуках обязательно будет лапша, я постарался разрушить. Подход масштабируется, так что размер формы не важен. Хотя я вполне допускаю, что могут быть какие-то подводные камни - Они всегда могут быть где-либо.
Если вкратце, то всё очень плохо и очень не очевидно. Да и подход слишком "реактовский" и это огромнейший минус, т.к. реакт годится только на рендера HTML'a, но ни как не на управление состоянием.
Если вкратце, то всё очень плохо и очень не очевидно
Что конкретно для вас неочевидно и очень плохо? В чем конкретно минусы моего подхода?
Чем:
<Input formField={state.formFields.firstName} title="Имя" />
очевиднее, чем это?
<FormControls.Input name="firstName" title="Имя" />
Проблема вашей краткости в том, что это очень удобно - сказать, что все плохо, но что именно плохо - не сказать. Это говорит либо о том, что вы не можете сказать ничего конкретного, либо то, что вы даже не попытались потратить хоть какое-то время, чтобы немного вникнуть.
Что здесь для вас не очевидно? У формы 2 блока, каждый блок описан отдельным компонентом. Лишние рендеры отсутствуют, т. к. в библиотеке позаботились о том, как правильно хранить состояние формы.
<FormBlock name="personalInfo" title="Персональная информация">
<PersonalInfo />
</FormBlock>
<FormBlock name="cart" title="Корзина">
<DrinksList name="drinks" drinkValidate={drinkValidate} />
</FormBlock>
Я бы очень хотел посмотреть, как эта форма будет выглядеть на MobX в вашем видении. Возможно вы действительно понимаете, как можно сделать красивее, был бы рад увидеть это, а не только услышать критику без аргументов.
подход слишком "реактовский" и это огромнейший минус, т.к. реакт годится только на рендера HTML'a, но ни как не на управление состоянием.
Это слишком сильное заявление. Может быть подход не годится именно для вас? Какие конкретно проблемы моего решение перед решением на MobX? То, что прокси не используется? Надо на практике сравнивать производительность. То, что выглядит неочевидно? Сделайте лучше на MobX!
@markelov69 Ждем ответ по существу :)
Там в свежей версии новых хуков завезли. Вот про них бы почитать.
И для такого "изложения" найдутся читатели. Я редко обращаюсь к react и бывают моменты, в которые нужно быстро закрыть какой то маленький вопрос, когда мне недостаточно понятны формулирови и стиль официальной документации, и замечательно что, я могу найти почти то же самое но написанное немного в другом стиле. И, бывает, я экономлю достаточное значительное количество времени найдя такое "альтернативное изложение".
Так что - больше статей хороших и разных :)
Заходя на статью про реакт, обожаю почитать комменты mobXеров 😀. Ребята никогда не подводят своими вбросами какой mobX классный и как им нужно везде обмазываться 😊
Все хуки и концепты React в одной статье