Comments 11
А где же хуки?
Какая разница, хуки или нет, суть не в этом.
Статья для начинающих же, почему бы и не показать, тем более и кода меньше получится.
И есть проблемы с асинхронным обновлением стейта.
Вот цитата со страницы реакта:
Вот ваш компонент на хуках:
Ну разве не красота?
И есть проблемы с асинхронным обновлением стейта.
Вот цитата со страницы реакта:
«Хуки не меняют ваши знания о концепциях в React. Вместо этого, хуки предоставляют более прямой доступ к API уже знакомых вам понятий: пропсов, состояния, контекста, рефов, и жизненного цикла. Мы также рассмотрим мощный способ компоновать эти понятия с помощью хуков.»
Вот ваш компонент на хуках:
const Form = () => {
const [name, setName] = useState("");
const handleNameChange = e => setName(e.target.value);
return (
<div>
<input
type="text"
value={name}
onChange={handleNameChange}
/>
</div>
);
}Ну разве не красота?
Ну разве не красота?
Нет) В реальной жизни при использовании реактовского стейт менеджмента получается убожество во всей красе.
А красота это вот: codesandbox.io/s/cool-leaf-xnh59?file=/src/App.tsx
Ну вот, вы же сами про реактовский стейт менеджмент статью писали (кстати форму валидировать самое то, разве нет? а после валидации и модель обновить. Да и переиспользуемые компоненты без локального стора сложновато написать. Да и бывают свойства в компоненте отвечающие чисто за косметику, не тянуть же их в глобальный стор), а хуки лично мне много приятнее использовать, в сравнении с классами (после них и мысли не возникает использовать классы). А теперь отходите в сторону. Я согласен, что есть решения для глобального стейта и получше (реакт же позиционируется как бы для презентаций), но раз пошел такой разговор, то еще лучшее mobx-state-tree. Там и патчи (очень помогает если вы свою модель с сервером синхронизируете, когда один документ редактируют несколько пользователей одновременно например), и снапшуты, и много чего еще вкусного.
Пример который я скинул, там именно локальный стейт компонента, а не глобальный. MobX заменяет идеально и тот и другой.
В mobx есть autorun и reaction — пожалуйста, синхронизируйтесь с чем угодно, хоть с сервером, хоть с query параметрами урла. Так же используя их делайте снапшоты сколько угодно и как угодно. mobx-state-tree не дает ничего крутого на самом деле, вам только может так казаться, но это связано с тем что попросту можете не знать возможности mobx'a. Вообщем mobx-state-tree нафиг не нужен, он только мешает и делает код придурковатым, вместо того чтобы писать код максимально простым и понятным. Любые ваши желания и фантазии можно с легкостью реализовать с помощью mobx'a. А для описания моделей более чем достаточно и более правильно использовать Typescript.
Я использую хук useState только для того, чтобы получить инстанс MobX класса, чтобы это был локальный стейт компонента, а не потому что я использую реактовский стейт менеджмент на хуках.
то еще лучшее mobx-state-tree. Там и патчи (очень помогает если вы свою модель с сервером синхронизируете, когда один документ редактируют несколько пользователей одновременно например), и снапшуты, и много чего еще вкусного.
В mobx есть autorun и reaction — пожалуйста, синхронизируйтесь с чем угодно, хоть с сервером, хоть с query параметрами урла. Так же используя их делайте снапшоты сколько угодно и как угодно. mobx-state-tree не дает ничего крутого на самом деле, вам только может так казаться, но это связано с тем что попросту можете не знать возможности mobx'a. Вообщем mobx-state-tree нафиг не нужен, он только мешает и делает код придурковатым, вместо того чтобы писать код максимально простым и понятным. Любые ваши желания и фантазии можно с легкостью реализовать с помощью mobx'a. А для описания моделей более чем достаточно и более правильно использовать Typescript.
Внимательнее глянул ваш пример, вы сами хуки пользуете. А новичкам предлагаете примеры с классами. Почему так?
Я использую хук useState только для того, чтобы получить инстанс MobX класса, чтобы это был локальный стейт компонента, а не потому что я использую реактовский стейт менеджмент на хуках.
MST реализовал все велосипеды, которые вы скорее всего напишете поверх mobX, если столкнетесь с более сложными структурами данных, кстати он тоже написан поверх mobX. Эти подходы идут по возрастании сложности данных: стейт реакта-> mobX-> MST. Кстати Typescript тоже поддерживается в MST.
Вот простой пример. Допустим у нас есть документ с данными, он хранится в массиве на сервере. С ним одновременно работают несколько человек в реальном времени. Один пользователь поменял у себя в модели какой-то элемент массива. Вопрос: как вы передадите изменения от этого пользователя всем остальным? как организовать удаление/обновление/создание новых элементов сразу у всех пользователей данного документа (будете писать экшены в духе редакса?)? а когда сложность и глубина структуры данных начнет расти?
MST знает о структуре данных, в отличие от mobX, что сильно упрощает работу с ними.
И про хуки. Ваша статья называется «Контролируемые и неконтролируемые компоненты в React не должны быть сложными». функции + хуки -> меньше кода, выше наглядность -> снижение сложности.
Вот простой пример. Допустим у нас есть документ с данными, он хранится в массиве на сервере. С ним одновременно работают несколько человек в реальном времени. Один пользователь поменял у себя в модели какой-то элемент массива. Вопрос: как вы передадите изменения от этого пользователя всем остальным? как организовать удаление/обновление/создание новых элементов сразу у всех пользователей данного документа (будете писать экшены в духе редакса?)? а когда сложность и глубина структуры данных начнет расти?
MST знает о структуре данных, в отличие от mobX, что сильно упрощает работу с ними.
И про хуки. Ваша статья называется «Контролируемые и неконтролируемые компоненты в React не должны быть сложными». функции + хуки -> меньше кода, выше наглядность -> снижение сложности.
Вот простой пример. Допустим у нас есть документ с данными, он хранится в массиве на сервере. С ним одновременно работают несколько человек в реальном времени. Один пользователь поменял у себя в модели какой-то элемент массива. Вопрос: как вы передадите изменения от этого пользователя всем остальным? как организовать удаление/обновление/создание новых элементов сразу у всех пользователей данного документа (будете писать экшены в духе редакса?)? а когда сложность и глубина структуры данных начнет расти?
Ну вообще это элементарно, когда под рукой есть Javascript и WebSocket's(не обязательно, но с ними гораздо лучше). И без разница какой уровень вложенности в ваших массивах и объектах.
MST знает о структуре данных, в отличие от mobX, что сильно упрощает работу с ними.
Typescript / Flow знает о структуре данных.
И про хуки. Ваша статья называется «Контролируемые и неконтролируемые компоненты в React не должны быть сложными». функции + хуки -> меньше кода, выше наглядность -> снижение сложности.
Это не моя статья =)
Вообщем в дальнейшей дискуссии не вижу смысла. И доказывать вам что-то, тоже не вижу смысла. Пользуйтесь чем угодно на здоровье и как угодно, все равно мне с вашим кодом не работать =)
P.S. в духе редакса я ничего не пишу и не делаю, этот «дух» мне противен и меня удивляет что до сих пор в новых проектах кто-то берет Redux и пишет эту кашу с лапшой.
Ну вообще это элементарно, когда под рукой есть Javascript и WebSocket's(не обязательно, но с ними гораздо лучше). И без разница какой уровень вложенности в ваших массивах и объектах.— я видимо недостаточно ясно выразился. с механизмом доставки нет проблем, сокеты или что-то еще. вопрос был про данные, как вы предлагаете отслеживать изменения в данных и обновлять небольшие их фрагменты, только то что изменилось средствами голого mobx? или будете передавать весь документ целиком, и не важно что некоторые пользователи уже тоже вносят изменения?
Typescript / Flow знает о структуре данных.— вы путаете мягкое и теплое, типизация не добавит вам более безопасных способов работы с данными, в отличии от MST, который и в рантайме будет это делать.
Вообщем в дальнейшей дискуссии не вижу смысла. И доказывать вам что-то, тоже не вижу смысла.т.е. вы видите смысл в разбрасывании голословными утверждениями вроде
Вообщем mobx-state-tree нафиг не нужен, он только мешает и делает код придурковатым, вместо того чтобы писать код максимально простым и понятным.не приведя никаких аргументов?
я тоже не собираюсь вам ничего доказывать, это комментарии для новичков, которые только начинают погружаться в реакт, но нахожу несколько странным вашу позицию вроде «статья не моя, я лишь перевел, и все равно что там написано — я не при делах, и вообще пишу код не так как предлагают в этой статье».
Внимательнее глянул ваш пример, вы сами хуки пользуете. А новичкам предлагаете примеры с классами. Почему так?
Sign up to leave a comment.
Контролируемые и неконтролируемые компоненты в React не должны быть сложными