Спасибо! Я скорее говорил о бизнес-кейсах. Пока что в голову пришло: - заполнение очень больших форм в огромном количестве и желание отменять изменения - функционал figma/miro
ну например ты делаешь таблицу в которой юзеры много меняют, и надо отправлять изменения батчем, таблица может быть огромной и её нельзя просто сохранить копией или каждый раз полностью кидать на сервак + клиенты платят за изменения в этой таблице(за задачу в очереди на сервере на изменение) и им не выгодно делать 300 задач на каждый инкримент одной ячейки таблицы
Приведи примеры кейсов для применения immer, стало интересно
иммер тебе позволяет тебе избавиться от написания reducers. в проекте, обновляя поля одной функцией, в общем уменьшение бойлерплейта чего-то прям вау в нем нет
иммер тебе позволяет тебе избавиться от написания reducers. в проекте, обновляя поля одной функцией, в общем уменьшение бойлерплейта чего-то прям вау в нем нет
ну это если ты не используешь его патчи ни для чего кроме иммутабельности, т.е. не используешь его основную фичу)
там кстати есть небольшое замечание в статье о проблеме патчей, она в том что патчи не отражают намерение об изменении состояния, а только само состояние, по этому нужно проектировать типы данных немного в необычном стиле) *тут должны быть 100500 ссылок, на другие варианты использования, но я свалил все пеперы в кучу и там ничего не найти*
там кстати есть небольшое замечание в статье о проблеме патчей, она в том что патчи не отражают намерение об изменении состояния, а только само состояние, по этому нужно проектировать типы данных немного в необычном стиле) *тут должны быть 100500 ссылок, на другие варианты использования, но я свалил все пеперы в кучу и там ничего не найти*
академические изыски которые будут слишком сложны для понимания рядового синьера фронтэндера это круто но в конечном итоге останутся уделом тех у кого вагон времени, денег или того и другого вместе