Ember.js: каждый входной перерыв на ключах, содержащих точку в 3.8.0-beta.1

@jasonmit не могли бы вы отправить PR с провалом теста?

Мы определенно должны определить причину этого, но я не уверен, что это будет считаться ошибкой в ​​конце. В частности, get(obj, 'hello.world') будет искать obj.hello.world not obj['hello.world'] ...

Да, почти уверен, что причина в том, что каждый вход использует get, так что это своего рода дубликат билета get с точкой пути. Может быть, в этом конкретном случае нам не нужно использовать get in here после посадки геттеров ES5, потому что это, вероятно, все равно не работает с прокси?

В частности, https://github.com/emberjs/ember.js/blob/master/packages/%40ember/-internals/glimmer/lib/utils/iterable.ts#L128

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

Да, и я действительно думаю, что мы делаем разные вещи на основе эвристики объекта, который здесь повторяется:

https://github.com/emberjs/ember.js/blob/7df81ec411b2da73086f63bf6a26b113dfa5a1a2/packages/%40ember/-internals/glimmer/lib/utils/iterable.ts#L290 -L298

Некоторые из этих итераторов используют get ( ObjectIterator.fromIndexable ), а некоторые нет ( ObjectIterator.fromForEachable , MapLikeNativeIterator.from )

В этом случае мы смотрим на fromIndexable . Я думаю, что единственная проблема с неиспользованием get - это pojos с cps

@chancancode - да, я указываю на это только потому, что @jasonmit может обойти проблему, заставив объект реализовать Symbol.iterable

@jasonmit не могли бы вы отправить PR с провалом теста?

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

да, я указываю на это только потому, что @jasonmit может обойти проблему, заставив объект реализовать Symbol.iterable

Отличная идея, я попробую это сделать.

Если вам интересно, почему у нас есть точки в ключе, ключи в объекте, по которому выполняется итерация, являются строками ISO (то есть 2011-10-05T14:48:00.000Z ), и у них есть точки перед смещением UTC.

Просто интересно, каков статус этого? Спасибо всем

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

Всем привет, сделал себе пиар на эту, прошу обзор: D

Что я могу сделать, чтобы это продвинулось? Нам это действительно нужно 🤞

@ amk221 вы можете добавить помощника. Вот как я решил проблему.
Но согласитесь, это критично.

Просто потратил на это пару часов - я новичок в Ember, и это было совершенно неожиданно.

В своем приложении я отслеживаю статус множества хостов, поэтому хеширую по IP-адресу или имени домена. Он возвращал undefined для всего, кроме localhost и я сводил себя с ума, пытаясь понять это.

@ devop911 поделитесь своим помощником 😁

@ amk221 Не тот, о котором вы спрашиваете, но в итоге я использовал эту связку:

import { helper } from '@ember/component/helper';
import _ from 'lodash';

export function hashToArray([h]) {
  return _.map(h, function(value, key) {
    return {
      key: key,
      value: value,
    }
  });
}

export default helper(hashToArray);

Я тоже затронул эту проблему. Любые обновления?

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

Мы могли бы вручную проверить прокси и использовать unknownProperty для объекта, если это был прокси, а в противном случае использовать обычный синтаксис get, особенно при итерации объекта с помощью each-in , который может работать должным образом.

Долгосрочные гусеничные опоры не могут появиться в ближайшее время 😩

Вкратце: переключитесь на что-нибудь еще, кроме Ember. Это не стоит всех хлопот.

Подобные комментарии

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

@pzuraq
Пусть пользователи сами решают, как назвать свои ключи, никогда не может быть крайним случаем.

@pzuraq Я думаю, у нас должно быть хотя бы предупреждение, которое each-in включает точку. Однако нет отличного решения без введения регрессий, вы правы

@ devop911 моя оценка того, что это

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

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

Исправлено https://github.com/emberjs/ember.js/pull/18296

Спасибо всем за решение ❤️