Ember.js: cada uma das quebras nas chaves que contêm um ponto em 3.8.0-beta.1

@jasonmit, você poderia enviar um PR com o teste de reprovação?

Devemos definitivamente causar isso, mas não tenho certeza se isso será considerado um bug no final. Especificamente, get(obj, 'hello.world') procurará obj.hello.world não obj['hello.world'] ...

Sim, tenho certeza que essa é a razão, each-in usa get, então isso é uma espécie de duplicata do bilhete get with dot path. Podeyyybe, neste caso específico, não precisarmos usar get in here após o desembarque ES5 getters, porque isso provavelmente não funciona com proxies de qualquer maneira?

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

Concordo, não tenho certeza se isso é considerado um bug e se corrigi-lo agora causará problemas em outro lugar ou no futuro

Sim, e eu realmente acho que fazemos coisas diferentes com base na heurística do objeto que está sendo iterado aqui:

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

Alguns desses iteradores usam get ( ObjectIterator.fromIndexable ) e outros não ( ObjectIterator.fromForEachable , MapLikeNativeIterator.from )

Estamos olhando para fromIndexable neste caso. Acho que o único problema de não usar get é pojos com cps

@chancancode - sim, só aponto porque @jasonmit poderia contornar o problema fazendo o objeto implementar Symbol.iterable

@jasonmit, você poderia enviar um PR com o teste de reprovação?

Definitivamente, farei isso agora e vincularei o problema.

sim, eu só aponto isso porque @jasonmit poderia contornar o problema tornando o objeto implementar Symbol.iterable

Ótima ideia, vou tentar isso como uma solução alternativa.

Caso você esteja curioso para saber por que temos pontos na chave, as chaves no objeto que está sendo iterado são strings ISO (ou seja, 2011-10-05T14:48:00.000Z ) e aquelas têm pontos antes do deslocamento UTC.

Apenas se perguntando qual é o status disso? Obrigado a todos

@ amk221 Não acredito que isso tenha sido resolvido, acabamos refatorando nosso aplicativo para evitar o ponto final na chave, mas obviamente não é uma solução ideal para todos.

Olá a todos, Fiz um PR para este, pedindo uma revisão: D

Algo que eu possa fazer para que isso continue? Nós realmente precisamos disso 🤞

@ amk221 você pode adicionar um ajudante. Foi assim que resolvi o problema.
Mas concordo que isso é fundamental.

Perdi algumas horas com isso - sou muito novo no Ember e isso foi completamente surpreendente.

Para o meu aplicativo, estou monitorando o status de vários hosts, portanto, digitando um hash pelo IP ou nome de domínio. Ele estava voltando indefinido para tudo, exceto localhost e eu estava me deixando louco tentando descobrir isso.

@ devop911 cuidado em compartilhar seu ajudante 😁

@ amk221 Não é o que você está perguntando, mas acabei usando um monte:

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

Acabei de abordar esse problema também. Alguma atualização?

Não tenho certeza se podemos consertar isso sem regredir o caso de uso comum para get . Se pudermos obter um benchmark que mostre que a regressão não é ruim, então provavelmente não há problema em adicioná-lo a get , mas do contrário precisaríamos construir a correção diretamente em each-in . Eu suspeito que seria uma regressão decente.

Poderíamos verificar manualmente os proxies e usar unknownProperty no objeto se fosse um proxy e, caso contrário, usar a sintaxe get normal especificamente ao iterar um objeto usando each-in , que pode funcionar conforme o esperado.

Adereços monitorados de longo prazo não podem chegar logo 😩

Resumindo a história: mude para qualquer outra coisa além do Ember. Não vale a pena todos os problemas.

Comentários @ devop911 como esse não são muito construtivos ou úteis. Queremos absolutamente resolver esse problema, mas também não queremos regredir o desempenho nos aplicativos do usuário para um caso extremo que é relativamente incomum. É uma situação difícil como mantenedor.

Vamos descobrir uma correção para isso com o tempo, só precisa de um pouco mais de trabalho do que um problema comum e estamos focados em recursos de envio para o Octane. Eu concordo, mas isso é importante.

@pzuraq
Deixar que os usuários decidam, como nomear suas chaves, nunca pode ser um caso extremo.

@pzuraq Acho que devemos ter pelo menos um aviso que é lançado se a chave para each-in inclui um ponto final. Não há uma ótima solução sem a introdução de regressões, você está certo

@ devop911 minha avaliação de ser um caso extremo baseou-se no fato de que vimos muito poucos relatórios desse bug em geral desde que este problema foi aberto. Se esse fosse o comportamento em que todos os aplicativos do Ember dependessem, seria uma correção de maior prioridade, com certeza, mas parece que muitas pessoas não usam pontos em suas chaves.

Por outro lado, _devemos_ receber muitas reclamações sempre que regredimos o desempenho. Se esse não fosse um caminho rápido, a correção certamente teria surgido muito antes. Como eu disse, é uma situação difícil como mantenedor, especialmente quando você está tentando fazer as coisas 😩 Vou ver o que podemos fazer para que alguém trabalhe nisso mais cedo ou mais tarde

@ rwwagner90 Acho que podemos consertar o comportamento, então prefiro não começar a avisar, mas se não pudermos consertar, concordo que devemos avisar os usuários.

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

Obrigado a todos por terem encontrado uma solução ❤️