const [data, updateData] = useState({}) updateData({ ...data, other: 'hello' })

updateData(d => ({...d, a, b, c}))

Рудукс лучше мобх ?

Но используются для одного и того же если не ошибаюсь

Рудукс лучше мобх ?

Хм, гляну, не знал что есть ещё библиотеки для работы со сторами;) как всегда спасибо

А как useReducer в работе со структурами помогает?

Позволяет не писать вот такое каждый раз, когда хочешь поменять стейт, а вынести эту логику в отдельный редьюсер. setState({ ...state, first: { ...state.first, second: { ...state.first.second, [action.someId]: { ...state.first.second[action.someId], fourth: action.someValue } } } })

Чот похоже нужен хелпер к useState по типу const [value, ...mutate] = useState(initialState, ...mutators)

Или просто использовать подходящие инструменты?

Позволяет не писать вот такое каждый раз, когда хочешь поменять стейт, а вынести эту логику в отдельный редьюсер. setState({ ...state, first: { ...state.first, second: { ...state.first.second, [action.someId]: { ...state.first.second[action.someId], fourth: action.someValue } } } })

Да, к примеру реатом какой-нибудь)

Или redux :)

Я возможно не прав... Но на сколько помню на счёт useReducer, то его рекомендуют использовать, когда нужно изменять несколько значений одновременно. т.е. когда на какое-то событие нужно затронуть несколько состояний, то имеет смысл в useReducer.

Ну сам посмотри — можно использовать несколько useState в одном компоненте, каждый со своим значением и типом. Они всё равно зачем-то питают в один стейт всё. Если в стейте массив, то гораздо удобнее повторяющуюся логику «иммутабилизации» не повторять, а вынести в редьюсер. Разве я не прав?

Я не говорил, что ты не прав :) Я просто про "основной поинт" в useReducer. Вроде в презентации хуков говорили про это.

Хз, что там рекомендуют, не помню рекомендаций. Просто здравый смысл. Я чуть не заплакал от счастья, когда узнал, что наконец-то можно не хранить в стейте обьекты. А у редьюсера много ситуаций для применения можно придумать. Батчить изменения — да. Если логика компонента настолько сложная, что в стейте компонента нужна структура, то редьюсер может забрать с собой много бойлерплейта и кода «подготовки к изменению» — тоже да.

Да, к примеру реатом какой-нибудь)

Если нужен тяжелый локальный стейт, useReducer достаточно

Если у вас тяжёлый локальный стейт, то вы что-то делаете не так.

Если я пишу библиотечный компонент? Например, таблицу с сортировкой, пагинацией и фильтрацией. Ну или формик свой.

Если нужен тяжелый локальный стейт, useReducer достаточно

Кстати Reatom дружит с useReducer ) const increment = declareAction() const decrement = declareAction() const atom = declareAtom(0, on => [ on(increment, state => state + 1), on(decrement, state => state - 1) ]) ... const [state, dispatch] = useReducer(atom) dispatch(increment())

Тогда разделяешь логику и view и проблем нет. + я не вижу проблемы засунуть в сложный компонент стейт менеджер.

Кек. Серьезно? Я бы писал библиотеки с наименьшим количеством зависимостей. Ты бы поставил в свой радужный проект с реатомом компонент, написанный на чистом реакте или на реакте с мобыксом и реакт-мобыксом?

Кек. Серьезно? Я бы писал библиотеки с наименьшим количеством зависимостей. Ты бы поставил в свой радужный проект с реатомом компонент, написанный на чистом реакте или на реакте с мобыксом и реакт-мобыксом?

Ну речь наверное про проектные компоненты

Что такое "проектные компоненты"?

те, которые на уровне проекта, а не в либе. Но я уже походу сплю и потерял цепочку диалога )

Ты её потерял)

Ну речь наверное про проектные компоненты

То что ты руками пишешь тот же код, что есть в зависимостях, не значит что ты уменьшаешь количество зависимостей. А в чём проблема подключить компонент с другим стейт менеджером?

Проектные компоненты могут лежать в приватном npm и использоваться между проектами в одной компании. Я про такие, да.

Обычно старают подбирать один стек на компанию (например поисковые серсивы Яндекс), чтобы сотрудников проще было перекидывать между проектами. Если внедрение стейт менеджера в либу упрощает её, то почему бы и нет.

Ты, мне кажется, уже споришь ради того, чтобы спорить. Ну вот представь, в компании KEK incorporated есть два проекта — Foo и Bar. Один на мобыхе, второй на эффекторе. Я пишу охренеть какой умный компонент, который будет использоваться в обоих проектах (а потом ещё в пяти), какой на какой стейт-менеджер мне сделать вендор-лок? И зачем? Давай оставим стейт-машины для управления логикой приложения? М?

Обычно старают подбирать один стек на компанию (например поисковые серсивы Яндекс), чтобы сотрудников проще было перекидывать между проектами. Если внедрение стейт менеджера в либу упрощает её, то почему бы и нет.

Если внедрение стейт-менеджера — это подходящий компромисс по объёму бандла, и поддержке, то почему бы и нет.

Поэтому я и топлю в сторону того, что ВСЁ должно находиться в стейт менеджере. Абсолютно всё.

Да, речь именно про это. Тем более если все N проектов используют один и тотже СТМ, то на выходе можно получить более меньший бандл чем каждый раз писать свои "костыли".

Значения инпутов, ховеры, открытость модалок, сортировку таблицы,вот это всё? Ладно, топи. Не согласен с твоим мнением, но признаю твоё право его высказывать.

Рудукс лучше мобх ?

Да, вместо того, чтобы иметь 3-4 разных апи(redux/mobx/..., this.setState, useState, useReducer) по работе со стейтом можно оставить 1 и не пилить костыли на каждый их узко специфичных случаев.

Да, вместо того, чтобы иметь 3-4 разных апи(redux/mobx/..., this.setState, useState, useReducer) по работе со стейтом можно оставить 1 и не пилить костыли на каждый их узко специфичных случаев.

Например, можно использовать нативное апи реакта, а выбор сторонних библиотек оставить на совести пользователя компонента.

Еее, использовать нативное кривое апи.

Ты наверно и с нативным new Date работаешь.

Конечно, ведь люди, разрабатывающие реакт, по умолчанию кривее напишут, чем многоуважаемые авторы реатома.

Конечно, ведь люди, разрабатывающие реакт, по умолчанию кривее напишут, чем многоуважаемые авторы реатома.

Звучит как укор и навешивание ярлыка на реатом. Никто не говорил, что авторы реатом пишут лучше, чем авторы React.

Ненене, к вашей команде у меня нет претензий. Просто Андрей говорит, что реакт кривой, он лучше в каждой своей внутренней библиотеке сделает вендор лок на реатом (например). Объективно, команда реакта больше, у них точно не перегорит мейнтейнер, они точно будут поддерживать и развивать свой продукт.

Ну удачи 100500 раз решать те же проблемы, что были уже решены авторами реатом или эффектора. Зато в package.json не будет лишней строчки.

Ну если библиотека — это только лишняя строчка, то бог с тобой. Мне-то нужно будет поддерживать её, обновлять вовремя, решать проблемы, когда в проекте две версии реатома, вот это вот всё. Объяснять преемнику, что такое реатом и как поддерживать эту библиотеку.

ребята как можно сделать select и input в одном? Мог в ручную набирать и можно рядом с инпут сделать кнопку при нажатии выбирать что есть?

Ну вот как ты описал так и делай)

я к тому, что есть ли готовые решения и т.д.

я к тому, что есть ли готовые решения и т.д.

https://react-select.com/home пожалуйста. В целом такие штуки называются autocomplete или select with autocomplete

посоветуйте доклад про доступность или статьи какие нибудь

Всем привет, подскажите какое-нибудь готовое решение для реализации поля ввода текста как в google docs (с одновременным редактированием и подсветкой пользователей) Не могу ничего нагуглить на эту тему

Что значит “подсветка пользователей”? Вам нужен многопользовательский онлайн-редактор?

Всем привет, подскажите какое-нибудь готовое решение для реализации поля ввода текста как в google docs (с одновременным редактированием и подсветкой пользователей) Не могу ничего нагуглить на эту тему