Ember.js: cada entrada se rompe en claves que contienen un punto en 3.8.0-beta.1

@jasonmit ¿ podrías enviar un PR con la prueba fallida?

Definitivamente deberíamos raíz de esto, pero no estoy seguro de que esto se considere un error al final. Específicamente, get(obj, 'hello.world') buscará obj.hello.world no obj['hello.world'] ...

Sí, estoy bastante seguro de que esa es la razón, cada uno de los usos get, así que esto es una especie de duplicado del boleto get con dot path. Tal vez, en este caso específico, no necesitamos usar get in here después de aterrizar getters ES5 porque esto probablemente no funcione con proxies de todos modos.

Específicamente https://github.com/emberjs/ember.js/blob/master/packages/%40ember/-internals/glimmer/lib/utils/iterable.ts#L128

Estoy de acuerdo, no estoy seguro de si esto se considera un error y si solucionarlo ahora causará problemas en otros lugares o en el futuro

Sí, y de hecho creo que hacemos cosas diferentes según la heurística del objeto que se itera aquí:

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

Algunos de esos iteradores usan get ( ObjectIterator.fromIndexable ) y otros no ( ObjectIterator.fromForEachable , MapLikeNativeIterator.from )

Estamos viendo el fromIndexable en este caso. Creo que el único problema de no usar get es pojos con cps

@chancancode - ya, solo lo señalo porque solucionar el problema haciendo que el objeto implemente Symbol.iterable

@jasonmit ¿ podrías enviar un PR con la prueba fallida?

Definitivamente, lo haré ahora y vincularé el problema.

ya, solo lo señalo porque solucionar el problema haciendo que el objeto implemente Symbol.iterable

Gran idea, lo probaré como una solución alternativa.

En caso de que sienta curiosidad por saber por qué tenemos puntos en la clave, las claves del objeto sobre el que se itera son cadenas ISO (es decir, 2011-10-05T14:48:00.000Z ) y tienen puntos antes del desplazamiento UTC.

¿Me pregunto cuál es el estado de esto? Gracias a todos

@ amk221 No creo que esto se haya resuelto, terminamos refactorizando nuestra aplicación para evitar el punto en la clave, pero obviamente no es una solución ideal para todos.

Hola a todos, hice un PR para este, pidiendo una revisión: D

¿Hay algo que pueda hacer para que esto avance? Realmente necesitamos esto 🤞

@ amk221 puede agregar un ayudante. Así es como resolví el problema.
Pero conviene que esto es fundamental.

Perdí un par de horas en esto, soy súper nuevo en Ember y esto fue completamente sorprendente.

Para mi aplicación, estoy rastreando el estado de un grupo de hosts, por lo que introduzco un hash por IP o nombre de dominio. Regresaba indefinido para todo excepto localhost y me estaba volviendo loco tratando de resolver esto.

@ devop911 se preocupa por compartir su ayudante 😁

@ amk221 No es el que estás preguntando, pero terminé usando esto un montón:

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);

Acabo de abordar este problema también. ¿Alguna actualización?

No estoy seguro de que podamos solucionar este problema sin hacer una regresión del caso de uso común de get . Si podemos obtener un punto de referencia que muestre que la regresión no es mala, entonces probablemente esté bien agregar esto a get , pero si no es así, tendríamos que construir la corrección directamente en each-in . Sospecho que sería una regresión decente.

Podríamos verificar manualmente los proxies y usar unknownProperty en el objeto si fuera un proxy, y de lo contrario usar la sintaxis get normal específicamente al iterar un objeto usando each-in , que puede funcionar como se esperaba.

Los accesorios de seguimiento a largo plazo no pueden llegar lo suficientemente pronto 😩

En resumen: cambia a cualquier otra cosa que no sea Ember. No vale la pena tanto esfuerzo.

Comentarios de @ devop911 como ese no son muy constructivos ni útiles. Queremos resolver este problema, pero tampoco queremos que el rendimiento de las aplicaciones del usuario retroceda en un caso extremo que es relativamente poco común. Es una situación difícil como mantenedor.

Encontraremos una solución para esto a tiempo, solo necesita un poco más de trabajo que un problema típico y nos hemos centrado en las funciones de envío de Octane. Estoy de acuerdo, aunque esto es importante.

@pzuraq
Dejar que los usuarios decidan cómo nombrar sus claves nunca puede ser un caso extremo.

@pzuraq Creo que al menos deberíamos tener una advertencia si la clave de each-in incluye un punto. Sin embargo, no hay una gran solución sin introducir regresiones, tienes razón

@ devop911 mi evaluación de que es un caso de borde se basó en el hecho de que hemos visto muy pocos informes de este error en general desde que se abrió este problema. Si este fuera un comportamiento en el que se basaran todas las aplicaciones de Ember, habría sido una solución de mayor prioridad, absolutamente, pero parece que no muchas personas usan puntos en sus claves.

Por otro lado, recibimos muchas quejas cada vez que disminuimos el rendimiento. Si este no fuera un camino caliente, la solución definitivamente habría llegado mucho antes. Como dije, es una situación difícil como mantenedor, especialmente cuando estás tratando de hacer las cosas 😩 Veré qué podemos hacer para que alguien trabaje en esto más temprano que tarde

@ rwwagner90 Creo que podemos corregir el comportamiento, así que prefiero no comenzar a advertir, pero si no podemos solucionarlo, estoy de acuerdo en que definitivamente deberíamos advertir a los usuarios.

Corregido por https://github.com/emberjs/ember.js/pull/18296

Gracias a todos por idear una solución ❤️