Касательно готовых решений в облаке для готовых приложений. А что скажете про Voximplant? Насколько он обойдётся в копеечку по сравнению со встраиванием Janus'а или анта в свой сервер?
Возможно вы правы. Хотя не могу припомнить, что кроме пропсов остаётся у нодов не-примитивного, чтобы это пригодилось. Возможно ошибаюсь.
А вот для пропсов кстати это может оказаться очень полезным, как ниже писали. Не знаю, как в реакте, а во Vue для того, чтобы изменение было реактивным, нужно создавать новый объект. Вот там бы точно такое пригодилось и в пропсах, и в computed, и в стейтах Vuex.
Записи и кортежи дают удобные объекты, у которых сравнение работает быстрее, они гарантированно иммутабльны.
Так ведь получается, что если потомок иммутабелен, то должен быть иммутабелен его родитель, тем самым будет иммутабельным всё дерево. Если потомок-запись нужно обновить, то нужно обновить и родителя, ведь потомок-запись внутри него уже другая, так снизу до самого верха, и тем самым на каждый чих будет создаваться новое DOM-дерево. Великоватая плата за более быстрое сравнение.
Ключи никуда не денутся.
С учётом того, что сейчас ключи – желательный, но не обязательный момент, которым иногда любят пренебрегать из-за незнания/ненастроенного линтера/лени, всё это посыпется у кучи проектов, никакой обратной совместимости.
Только если сделать объект-обёртку, в котором будут запись с иммутабельными данными и объект с потомками и ивентами. Как я понял из статьи, вложить в запись объект или массив нельзя. А толку от задумки с такой обёрткой я лично не вижу, вопрос со сравнением никуда не денется.
Плюс, представим ситуацию, что у нас список из 10 одинаковых VNode, и нам нужно что-то сделать с одной конкретной. Если сейчас отсутствие ключа у узла влияет только на производительность при повторном рендере, то с записями это будет куча головной боли, потому что одинаковые узлы язык будет считать за одно и то же.
Может кто-нибудь подсказать живые примеры, где иммутабельные объекты и массивы могут пригодиться? На ум приходят только какие-нибудь константы и конфигурации, которые изначально прописаны в коде. В большинстве задач всё равно используются составные типы, в которых что-то меняется, и тут кортежи и записи не дают никакого выигрыша.
С учётом того, что во фреймворках и вообще по хорошему тону элементы перезаписываются локально, а не полностью обновляется весь DOM, сомневаюсь в этом.
А вот для пропсов кстати это может оказаться очень полезным, как ниже писали. Не знаю, как в реакте, а во Vue для того, чтобы изменение было реактивным, нужно создавать новый объект. Вот там бы точно такое пригодилось и в пропсах, и в computed, и в стейтах Vuex.
Так ведь получается, что если потомок иммутабелен, то должен быть иммутабелен его родитель, тем самым будет иммутабельным всё дерево. Если потомок-запись нужно обновить, то нужно обновить и родителя, ведь потомок-запись внутри него уже другая, так снизу до самого верха, и тем самым на каждый чих будет создаваться новое DOM-дерево. Великоватая плата за более быстрое сравнение.
С учётом того, что сейчас ключи – желательный, но не обязательный момент, которым иногда любят пренебрегать из-за незнания/ненастроенного линтера/лени, всё это посыпется у кучи проектов, никакой обратной совместимости.
Только если сделать объект-обёртку, в котором будут запись с иммутабельными данными и объект с потомками и ивентами. Как я понял из статьи, вложить в запись объект или массив нельзя. А толку от задумки с такой обёрткой я лично не вижу, вопрос со сравнением никуда не денется.
Плюс, представим ситуацию, что у нас список из 10 одинаковых VNode, и нам нужно что-то сделать с одной конкретной. Если сейчас отсутствие ключа у узла влияет только на производительность при повторном рендере, то с записями это будет куча головной боли, потому что одинаковые узлы язык будет считать за одно и то же.