Я могу, возможно, попытаться дать больше информации:)
Я знаю, что использование Immutable.js вместе с redux широко распространено и является обычной практикой
Я быхотелось бы увидеть график этого.Могу поспорить, что с ES6 номера не идут вверх.
Когда модель неизменности начала распространяться во внешнем мире несколько лет назад, многие люди к этому не привыкли.Так что Immutable.js было здорово скрыть «сложность» за неизменяемостью и иметь дело только с хорошо известными структурами, очень оптимизированным способом.
Кроме того, когда я начал полтора года огромный проект Angularназад я должен был принять решение использовать Immutable.js или нет.Я решил пойти на это, потому что кажется, что представление было невероятным.Angular Cli генерирует проекты с помощью Typescript (и я рад, что это так!).Но несколько недель спустя я заметил, что Immutable.js действительно не очень хорошо играл с Typescript (возможно, он изменился за это время, честно говоря, не могу сказать, поскольку я никогда не использовал его снова).И я бы предпочел иметь хорошо типизированный код, а не библиотеку, посвященную неизменности для меняПоэтому после 2 месяцев разработки я решил создать рефактор huuuuge и удалить immutablejs для использования в основном чистого JS (map, filter, они возвращают новые ссылки).
Если вы возьмете, например, следующее (извеб-сайт immutablejs):
import Immutable from require('immutable');
var map1: Immutable.Map<string, number>;
map1 = Immutable.Map({a:1, b:2, c:3});
var map2 = map1.set('b', 50);
map1.get('b'); // 2
map2.get('b'); // 50
Если вы решили переименовать часть своего магазина, удачи вам найти все ссылки, например: map1.get('b');
Принимая во внимание, что с чистым JS вы 'у меня не возникнет никаких проблем, и Typescript выдаст ошибку, если вы забудете переименовать ее.
Это правда, что у меня появилось много распространенных объектов вокруг моей кодовой базы, и даже если бы она оказалась оченьлегко читаемый, хорошо это было "шаблонным".
Теперь, говоря о ngrx, они делают действительно хорошую библиотеку для решения большей части этой проблемы, которая называется @ngrx/entity.
Что касается perfs, я работал над двумя огромными приложениями, и с этим не было никаких проблем.Особенно после выпуска функции createSelector, которая применяет запоминание, чтобы избежать повторного вычисления всех селекторов при каждом изменении хранилища.
Так, когда вы говорите
Библиотека должна обрабатыватьнеизменяемые данные изменяются гораздо лучше, чем оператор распространения.
Я бы сказал, что вам не стоит беспокоиться.В самом деле.Попробуйте сами, создайте Stackblitz и попробуйте написать небольшой тест / тест с большим количеством объектов, которые вы добавляете / обновляете постоянно.Я сделал это с очень большим набором массивов / объектов несколько месяцев назад, и это было совершенно нормально.
В заключение, самая большая проблема - вывод типа.Но это также, что вы просто не нуждаетесь в этом, по моему мнению.Если вы боитесь что-то упустить из-за неизменности, вы должны просто использовать в режиме разработки https://www.npmjs.com/package/ngrx-store-freeze, который выдаст ошибку, если вы попытаетесь изменить объект из магазина.