Были ли Ember Computed Properties предназначены для использования с/содержать асинхронный код?

Я опытный разработчик Ember.js. В руководствах мы можем найти пример вычисляемого свойства с полным именем (синхронно, просто, зависит от имени и фамилии). Однако в дикой природе мы можем найти множество применений вычисляемых свойств в асинхронном режиме (например, установка себя после разрешения обещаний - в то время как первый запуск и получение возвращает undefined).

Чем больше я вижу эти асинхронные вычисляемые свойства, тем больше задаюсь вопросом: предназначались ли вычисляемые свойства для использования с асинхронным кодом? Разве это не напрашивается на неприятности?

Распространенной проблемой является то, что другое вычисляемое свойство (CP2) зависит от асинхронного CP1. CP2 получает CP1, но получает undefined (поскольку CP1 установит свое значение позже, поскольку он асинхронный). CP2 завершает расчет с неверным значением CP2 (undefined). CP1 устанавливает сам себя, но CP2 больше не пересчитывается (даже CP1 изменился), потому что CP2 не упоминается в шаблоне (что означало бы, что он связан, и его значение требуется все время, всегда пересчитывается при изменении CP1) - но вместо этого был на который ссылается какой-либо вызов JavaScript.

Реальным примером этого может быть расчет общей цены заказа (из интернет-магазина) на основе элементов в заказе. Вычисляемое свойство зависит от асинхронных отношений с элементами, которые могут содержать другие асинхронные отношения, например тип налога.


javascript asynchronous computed-properties ember.js ember-data
person Daniel Kmak    schedule 18.07.2017    source источник

Ответы (1)


arrow_upward
1
arrow_downward

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

Я также работал над сайтом электронной коммерции. Сначала я обнаружил, что многие вычисления не выполняются при рендеринге сайта. Причина в том, что я передал обещания в вычисляемое свойство (которое используется для расчета). Позже я понял, что должен разрешить все отношения, прежде чем передавать результаты в логику вычислений. Я сделал этот шаг в сервисе. Один пример, чтобы продемонстрировать, что я имею в виду:

Допустим, в заказе много позиций, и вы хотите рассчитать общую цену, цена — это поле в позиции.

Вместо:

total: Ember.computed("[email protected]", function() {
  return this.get("order.items").reduce((sum, obj) => {
    return sum + obj.get("price");
  });
});

Я делаю это:

total: Ember.computed("[email protected]", function() {
   return this.get("items").reduce((sum, obj) => {
     return sum + obj.get("price");
   });
});

где items передается как результат обещания где-то выше.

Я обнаружил, что этот сообщение довольно хорошо объясняет why-you-should-not.

Некоторое время назад у меня возник соблазн задать аналогичный вопрос. Очень хочется услышать больше идей по этому поводу.

person kasperite    schedule 19.07.2017
comment
Я не использовал [email protected] в этом формате, допустим ли он? [email protected] есть ли разница между этим ? - person Ember Freak; 19.07.2017
comment
О, это опечатка, должно быть @each :), вы правы - person kasperite; 19.07.2017
comment
Я не согласен с вашим решением, хотя остальную часть вашего ответа я считаю ценным. Подождем еще идей. :) - person Daniel Kmak; 19.07.2017