Обнаружение изменений с помощью Observable vs Immutable

Итак, я прочитал эту статью об обнаружении изменений AngularJS 2, но после прочтения я стал более смущенным, поэтому я начал читать некоторые из комментарии, которые привели к большей путанице.

Неизменяемые объекты

Если компонент зависит только от его входных свойств, и они неизменный, то этот компонент может измениться тогда и только тогда, когда один из его изменения свойств ввода. Поэтому мы можем пропустить поддерево компонентов в дереве обнаружения изменений до тех пор, пока не произойдет такое событие. Когда это произойдет, мы можем проверить поддерево один раз, а затем отключить его до следующего изменения (серые поля показывают отключенные детекторы изменений).

Итак, если {{todo.text}} или todo.checked мы отмечаем наш todo: Todo, что произошло изменение Неизменяемые объекты

Но тогда, по моему мнению, мы можем создать каскад неизменных объектов.

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

каскадные неизменные obejcts

@Component({changeDetection:ChangeDetectionStrategy.OnPush})
class ImmutableTodoCmp {
  todo:Todo;
}

Итак, в этом случае любые изменения в {{todo.text}} или todo.checked не будут замечены правильно? только когда Todo будет нажата, мы увидим изменение?

Наблюдаемые объекты

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

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

Я не понимаю, как Observables сильно отличаются от Immutables и в этом конкретном случае приложения Todo, какой подход лучше?

Ответы

Ответ 1

Итак, как и мы с 5 лет.

Это JohnCmp. Джон - это компонент, который принимает два входа: name: {first: 'John', last: 'Smith'} и age: 20.

Что произойдет, если name изменено? Ну, кто-то может передать его John и держать ссылку на него. Так что Джон и ЛЮБОЕ число других объектов или служб могут содержать ссылку на этот объект name. Это означает, что они могут изменить его, скажем, сделать name.last = 'foo'. И теперь John изменил имя, но он не получил имя new. Он все еще имеет ссылку на этот объект name, но он мутировал.

Если мы хотим обнаружить, нам нужно агрессивно проверить имя, name.first, name.last и т.д. с каждым свойством каждого объекта, который мы передаем. Насколько проще было бы делать name === newName и просто сравнивать ссылки, эй? Если имя неизменно, нам не нужно сходить с ума и проверять каждое свойство, мы можем проверить ссылки и узнать, быстро ли изменяется объект.

Итак, теперь, представьте, что никто не ссылается на объект John name. Поэтому, если они хотят дать ему новое имя, они должны передать объект имени NEW. Затем John изменяет только, когда изменяется его ввод. Вот что здесь подразумевается:

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

Хорошо, так, чтобы основной случай был прав? Теперь нам не нужно беспокоиться о проверке каждого свойства, мы просто проверяем, что ссылки не изменились. Много улучшилось! НО объекты могут быть большими. Таким образом, массив people является неизменным Array of John s, которые являются неизменяемыми, из name, которые также неизменяемы. Итак, чтобы изменить имя Иоанна. вам нужно создать новое имя и новый Джон и массив новых людей.

Итак, все они меняются, все дерево нужно пройти. Итак, O(n). Отсюда этот небольшой комментарий:

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

НО

Это не тот случай, когда речь идет о наблюдаемых.

Почему tho?

Наблюдаемые испускают события. Им не нужно менять все, как непреложные, им просто нужно emit событие изменения. Поэтому в его примере у вас нет неизменяемого "массива", который нужно воссоздать и, следовательно, переоценить все изменения в дереве. Теперь у вас есть наблюдаемый people, который вызывает события, когда он изменяется. И John также получает видимый результат.

Итак, вы можете просто инициировать событие в John, сообщая ему, что его имя изменилось, БЕЗ запуска события в people или вещи такого типа. Избегайте повторного сканирования всех изменений, тем самым уменьшая сложность до O(log n), согласно этой цитате:

Как вы можете видеть, здесь компонент Todos имеет только ссылку на наблюдаемый массив todos. Таким образом, он не может видеть изменения в индивидуальных todos.

(основное внимание).

Надеюсь, что это поможет.

Ответ 2

Я не понимаю, как Observables сильно отличаются от Immutables и в этом конкретном случае приложения Todo, какой подход лучше?

Представьте, что у вас есть дерево узлов, и каждый node имеет бит, который говорит: "Возможно, я изменился". С Observable мы говорим о событиях, которые испускаются; событие отправляется вверх по дереву. Другими словами:

  • Todo_ChangeDetector будет помечен,
  • затем подойдя по дереву, Todos_ChangeDetector будет помечен,
  • затем подойдя по дереву, App_ChangeDetector будет помечен,
  • а затем нормальное обнаружение изменений в.

Представьте, что у вас есть 2 списка todo:

  • список продуктов.
  • список встреч (работа?) за день.

Какой список продуктов активен, который вы сейчас показываете, будет Observable; например раскрывающийся список, навигационные таблетки и т.д. Все предметы списка задач в этих двух списках могут быть Immutable; например вы не являетесь организатором собрания и не можете изменять собрания.