что быстрее, мутабельность или иммутабельность?

Мутабельность.

Мутабельность.

мне тут нашептали, что мутабельные операции затратнее

мне тут нашептали, что мутабельные операции затратнее

Изменить объект всегда дешевле, чем создать новый. Минус в том, что управлять всем этим очень сложно, поэтому проще создавать новый.

Так и есть

есть кто mobx-state-tree щупал?

мне тут нашептали, что мутабельные операции затратнее

Зависит от подхода, разные ситуации бывают

Чем проще и предсказуемее конструктор объекта и стабильнее его тип — тем быстрее иммутабельные операции

Чем проще и предсказуемее конструктор объекта и стабильнее его тип — тем быстрее иммутабельные операции

можешь объяснить про предсказуемость и стабильность?

Чем проще и предсказуемее конструктор объекта и стабильнее его тип — тем быстрее иммутабельные операции

Вот тоже сейчас смотрю про это, удивился, что иммутабельные данные бывает быстрее.

function Point(label, x, y) { this.label = label this.x = +x || 0 this.y = +y || 0 } const point = new Point('text','10')

не смотря на то, что этот код работает нормально, из-за того, что мы один раз передали строку и undefined, в другой раз два числа передадим и т.д. V8 не сможет эффективно конвертировать такую функцию в низкоуровневый типизированный код и заинлайнить её

Привет! А подскажите, пожалуйста, как подружить eslint-airbnb-config и VSCode?

Но это уже из области таких экономий на спичках, что редко кто доходит до такого уровня оптимизации — чтобы уже аж под движок затачиваться

Но это уже из области таких экономий на спичках, что редко кто доходит до такого уровня оптимизации — чтобы уже аж под движок затачиваться

Как-то читал, что оптимизация - это изучение документации компилятора, но это не про жс вроде было.

Как-то читал, что оптимизация - это изучение документации компилятора, но это не про жс вроде было.

оптимизиация это перманетные бенчмарки)

Как-то читал, что оптимизация - это изучение документации компилятора, но это не про жс вроде было.

Про жс тоже, в принципе

Иммутабельные данные дают предсказуемость, а следовательно легче можно тестировать. Какие ещё можно вещи использовать, как аргумент в сторону использования иммутабельных данных вообще в JS? В React необходимость понятна, по причиине shouldComponentUpdate.

Иммутабельные данные дают предсказуемость, а следовательно легче можно тестировать. Какие ещё можно вещи использовать, как аргумент в сторону использования иммутабельных данных вообще в JS? В React необходимость понятна, по причиине shouldComponentUpdate.

Да собственно как и везде, можно делать дешёвые проверки на наличие изменений. Плюс, есть алгоритмы изначально больше подходящие для иммутабельности: в парсере/лексере компилятора можно перебирать ветки вариантов, откатываясь назад в случае неудачи. С мутабельными данными потребуется обновление текущего объекта, что может быть затратно

Спасибо за пояснения.

Приветы) У меня вопрос околохоливарный. Не кажется ли вам, что использование es6 classes - это шаг назад по сравнению с createClass? )

мне тут нашептали, что мутабельные операции затратнее

смотря какие. Если тебе надо хранить историю изменений объекта, то иммутабельные выигрывают и по памяти и в алгоритмической предсказуемости

Приветы) У меня вопрос околохоливарный. Не кажется ли вам, что использование es6 classes - это шаг назад по сравнению с createClass? )

А аргументы?)

.bind ?)

Так не нужен же

руками. в 2к17 ))

М? Выпилили?

Ну class properties значения в бинде не нуждаются

Приветы) У меня вопрос околохоливарный. Не кажется ли вам, что использование es6 classes - это шаг назад по сравнению с createClass? )

есть хороший видос где рассказывают что class быстрее react create class

такой вопрос можно ли вручную вызывать лайфсайкл методы в реакт?

А есть ссылка?

Ну class properties значения в бинде не нуждаются

а, речь об этом: class MyClass { a: (args) => {..} } ?

такой вопрос можно ли вручную вызывать лайфсайкл методы в реакт?

да, можно

да, можно

стоит?

а, речь об этом: class MyClass { a: (args) => {..} } ?

Ну так ты сейчас просто тип описал, но вообще да class MyClass { a = (args) => {..} }

стоит?

В среднем нет, но ты же зачем-то спросил?)

Ну так ты сейчас просто тип описал, но вообще да class MyClass { a = (args) => {..} }

а, ну да. а если очень надо в this достучаться, то без вариантов?

а, ну да. а если очень надо в this достучаться, то без вариантов?

Так у тебя сразу метод с биндом получается. Можешь свободно вызывать в нём this

В среднем нет, но ты же зачем-то спросил?)

да интересно стало использует ли кто нить это и возможно ли так делать

Так у тебя сразу метод с биндом получается. Можешь свободно вызывать в нём this

эм.. а в таком случае this === экземпляр класса?

Да, это просто синтаксический сахар. Важно понимать, что у стрелочных функций нет своего контекста (this), поэтому при объявлении они сразу "биндятся" к контексту родителя, это фича

Можно посмотреть во что компилит это всё бабель

Да, это просто синтаксический сахар. Важно понимать, что у стрелочных функций нет своего контекста (this), поэтому при объявлении они сразу "биндятся" к контексту родителя, это фича

да это понятно. а вот про контекст родителя-класса сразу не понятно. Ну это ладно, я дальше погуглю. Ох, ироды, со всеми этими ES6)))

class MyClass { a = (args) => this.props } class MyClass { constructor() { this.a = args => this.props; } }

Ну, вообще мой пойнт в копилку createClass заключался в том, что всё это там не нужно))

вот видос где чувак рассказывает что createClass говно

https://www.youtube.com/watch?v=PnpfGy7q96U&feature=youtu.be

да это понятно. а вот про контекст родителя-класса сразу не понятно. Ну это ладно, я дальше погуглю. Ох, ироды, со всеми этими ES6)))

Ну кстати наоборот наконец то нормальный воркфлоу делается) Нужно объявление полей в теле класса — пишешь в теле, типы там же и т.д., как у нормальных людей короч

вот видос где чувак рассказывает что createClass говно

спасибо)

Ну, вообще мой пойнт в копилку createClass заключался в том, что всё это там не нужно))

Можно вообще обойтись только компонентами-функциями)

Можно вообще обойтись только компонентами-функциями)

а для них уже мемоизация работает искоропки?)

В плане? ? Компилируются в обычные реакт-компоненты, ну как будто из всего класса оставили только метод render и пропсы

Есть recompose для всяких shouldComponentUpdate, lazy и более специфичных оптимизаций

В плане? ? Компилируются в обычные реакт-компоненты, ну как будто из всего класса оставили только метод render и пропсы

ну, насколько я понимаю, основная идея functional components заключается в том, что компонент становится функцией своих аргументов. Если договориться о том, что он действительно функция своих аргументов, и не использует сторонние вызовы, создающий побочные эффекты (мы же не можем в JS никак гарантировать истинную чистоту функции), то результаты его работы вполне себе можно мемоизировать. Ну и жить дальше по табличке.

Ну а там уже в свою очередь, доступна вся магия ускоренных сравнений поддеревьев, например. Например путём сравнения предвычисленного хэша или еще чего подобного, сводящегося к одной операции сравнения.

class MyClass { a = (args) => this.props } class MyClass { constructor() { this.a = args => this.props; } }

При лямбдах из дочерних классов такие методы недоступны

ну, насколько я понимаю, основная идея functional components заключается в том, что компонент становится функцией своих аргументов. Если договориться о том, что он действительно функция своих аргументов, и не использует сторонние вызовы, создающий побочные эффекты (мы же не можем в JS никак гарантировать истинную чистоту функции), то результаты его работы вполне себе можно мемоизировать. Ну и жить дальше по табличке.

Покажите стикер про мемоизацию порфавор человеку

Ну а там уже в свою очередь, доступна вся магия ускоренных сравнений поддеревьев, например. Например путём сравнения предвычисленного хэша или еще чего подобного, сводящегося к одной операции сравнения.

Просто возьми recompose)

Покажите стикер про мемоизацию порфавор человеку

?

При лямбдах из дочерних классов такие методы недоступны

Почему?? Они создаются раньше любых методов потомка

Почему?? Они создаются раньше любых методов потомка

Честно хер знает. Попробую воспроизвести. Но сталкивался - пофиксил переписыванием на bind в конструкторе

ERROR: S client not available

Ну это скорее всего баг какой-нибудь

https://babeljs.io/repl/#?babili=false&evaluate=true&lineWrap=false&presets=react%2Cstage-2&targets=&browsers=&builtIns=false&debug=false&experimental=true&loose=false&spec=false&playground=true&code_lz=MYGwhgzhAECyCeBhcVoG8BQ1oAcBOA9jjALzpbbQEDWAXNAAwUC-FY0ZAFGHgOYQBKDgD5oAFwAWASwgA6fEQgZWGUJBiJpIACbQApgA8xegHbaYCZOvLZlGVQRMQx0YFt1kTegO7RNUnXtgRwgCED1ZEAJeTjcA7VkwTgEBeyA&stage=0

С телефона)

Иммутабельные данные дают предсказуемость, а следовательно легче можно тестировать. Какие ещё можно вещи использовать, как аргумент в сторону использования иммутабельных данных вообще в JS? В React необходимость понятна, по причиине shouldComponentUpdate.

C иммутабельностью сложно разработать некоторую бизнес-логику. Вот придумал такой кейс - у объекта юзера есть массив папок у каждой папки массив проектов у каждого проекта массив тасков и у каждого таска массив комментариев. И теперь юзер отредактировал какой-то комментарий - с мутабельностью все просто - берем и меняем на новое значение comment.text = newValue. А как с иммутабельностью? Нужно создать новый объект комментария, создать новый массив комментариев, перекопировать отстальные комментарии, создать новый массив тасков, перекопировать остальные таски, создать новый массив проектов, перекопировть остальные проекты и наконец создать новый массив папок, перекопировать и создать новый объект юзера. Это же медленнее в тысячи раз.

C иммутабельностью сложно разработать некоторую бизнес-логику. Вот придумал такой кейс - у объекта юзера есть массив папок у каждой папки массив проектов у каждого проекта массив тасков и у каждого таска массив комментариев. И теперь юзер отредактировал какой-то комментарий - с мутабельностью все просто - берем и меняем на новое значение comment.text = newValue. А как с иммутабельностью? Нужно создать новый объект комментария, создать новый массив комментариев, перекопировать отстальные комментарии, создать новый массив тасков, перекопировать остальные таски, создать новый массив проектов, перекопировть остальные проекты и наконец создать новый массив папок, перекопировать и создать новый объект юзера. Это же медленнее в тысячи раз.

линза

C иммутабельностью сложно разработать некоторую бизнес-логику. Вот придумал такой кейс - у объекта юзера есть массив папок у каждой папки массив проектов у каждого проекта массив тасков и у каждого таска массив комментариев. И теперь юзер отредактировал какой-то комментарий - с мутабельностью все просто - берем и меняем на новое значение comment.text = newValue. А как с иммутабельностью? Нужно создать новый объект комментария, создать новый массив комментариев, перекопировать отстальные комментарии, создать новый массив тасков, перекопировать остальные таски, создать новый массив проектов, перекопировть остальные проекты и наконец создать новый массив папок, перекопировать и создать новый объект юзера. Это же медленнее в тысячи раз.

не хранить все внутри друг друга?

не хранить все внутри друг друга?

тоже можно)

C иммутабельностью сложно разработать некоторую бизнес-логику. Вот придумал такой кейс - у объекта юзера есть массив папок у каждой папки массив проектов у каждого проекта массив тасков и у каждого таска массив комментариев. И теперь юзер отредактировал какой-то комментарий - с мутабельностью все просто - берем и меняем на новое значение comment.text = newValue. А как с иммутабельностью? Нужно создать новый объект комментария, создать новый массив комментариев, перекопировать отстальные комментарии, создать новый массив тасков, перекопировать остальные таски, создать новый массив проектов, перекопировть остальные проекты и наконец создать новый массив папок, перекопировать и создать новый объект юзера. Это же медленнее в тысячи раз.

ключевая идея в том, что не нужно столько всего копировать

не хранить все внутри друг друга?

Только не нужно предлагать нормализацию - я уже пробовал - это такие неудобства когда вместо того чтобы простись по ссылкам - comment.task.project.folder вся бизнес логика увешана лапшой вытаскивания нужного объекта по его айдишнику из глобального стора

ключевая идея в том, что не нужно столько всего копировать

а как по другому вернуть иммутабельный объект?

C иммутабельностью сложно разработать некоторую бизнес-логику. Вот придумал такой кейс - у объекта юзера есть массив папок у каждой папки массив проектов у каждого проекта массив тасков и у каждого таска массив комментариев. И теперь юзер отредактировал какой-то комментарий - с мутабельностью все просто - берем и меняем на новое значение comment.text = newValue. А как с иммутабельностью? Нужно создать новый объект комментария, создать новый массив комментариев, перекопировать отстальные комментарии, создать новый массив тасков, перекопировать остальные таски, создать новый массив проектов, перекопировть остальные проекты и наконец создать новый массив папок, перекопировать и создать новый объект юзера. Это же медленнее в тысячи раз.

в таком случае у тебя: 1. заменится твой комментарий 2. заменится таск, если в нём была прямая ссылка на коммент 3. массив проектов пересоберётся со всеми старыми объектами, и одним новым 4. ну и так дальше вверх.

Т.е. в таком случае у тебя все сестринские ноды в твоем дереве будут переиспользованы

Да, они упадут в новые контейнеры, но это достаточно быстро

Только не нужно предлагать нормализацию - я уже пробовал - это такие неудобства когда вместо того чтобы простись по ссылкам - comment.task.project.folder вся бизнес логика увешана лапшой вытаскивания нужного объекта по его айдишнику из глобального стора

Страшные sql запросы)

C иммутабельностью сложно разработать некоторую бизнес-логику. Вот придумал такой кейс - у объекта юзера есть массив папок у каждой папки массив проектов у каждого проекта массив тасков и у каждого таска массив комментариев. И теперь юзер отредактировал какой-то комментарий - с мутабельностью все просто - берем и меняем на новое значение comment.text = newValue. А как с иммутабельностью? Нужно создать новый объект комментария, создать новый массив комментариев, перекопировать отстальные комментарии, создать новый массив тасков, перекопировать остальные таски, создать новый массив проектов, перекопировть остальные проекты и наконец создать новый массив папок, перекопировать и создать новый объект юзера. Это же медленнее в тысячи раз.

Для этого есть https://en.wikipedia.org/wiki/Persistent_data_structure

Потому что в правильной реализации иммутабельных данных [a, b, c] и [a, b1, c], где b1 - это обновлённая версия b второй массив обычно не просто тупо массив, а специальный объект, который содержит только дельту

в таком случае у тебя: 1. заменится твой комментарий 2. заменится таск, если в нём была прямая ссылка на коммент 3. массив проектов пересоберётся со всеми старыми объектами, и одним новым 4. ну и так дальше вверх.

я писал перекопировать остальные комментарии а не пересоздать, все равно это в тысячи раз медленнее потому что нужно грубо говоря простись по всем объектам в массиве и создать ссылку в новом массива и это для каждого уровня вложенности

Бред

я писал перекопировать остальные комментарии а не пересоздать, все равно это в тысячи раз медленнее потому что нужно грубо говоря простись по всем объектам в массиве и создать ссылку в новом массива и это для каждого уровня вложенности

Не надо. Потому что в правильной реализации массива, замена одного элемента - это одна операция.

Я чуть выше написал

Как раз для того, чтобы не мудохаться с вложенностью и требуют нормализацию

Не надо. Потому что в правильной реализации массива, замена одного элемента - это одна операция.

массив то нужно новый создать

Не факт

массив то нужно новый создать

Это будет не совсем массив.

Ну точнее, тут уже детали реализации, но это может быть не совсем массив

Не надо. Потому что в правильной реализации массива, замена одного элемента - это одна операция.

Не одна

Т.е const updArr = arr.withUpdatedByIndex(index=1, value=b1); где updArr это не Array[String], нифига, а PatchedArray, который, грубо говоря, содержит информацию о том, что это всё, то же самое, что и arr, только элемент с индексом 1 теперь равен b1

Не одна

одно присваивание, не?)

В immutable массиве? Нет конечно

В immutable массиве? Нет конечно

1. создал ссылку на оригинал 2. запомнил смещение и новое значение Два присваивания и почти бесплатная ссылка