Cada entrada desta página tem a mesma forma: o build está verde, a auditoria está limpa, o console está calado, e a tela está vazia ou não é o que você queria. O compilador não enxerga esses erros porque cada um deles é um programa válido que, por acaso, descreve outro componente. Ache o título que soa como o que você está vendo; debaixo dele estão a causa e a correção.
O nome no view.tree e o nome do método na classe diferem, na maioria das vezes nas maiúsculas: exchange_form na árvore, exchangeForm na classe. São duas propriedades. A da classe nunca é chamada, a da árvore mantém seu padrão, e nada avisa.Os nomes são snake_case em todo lugar e precisam bater letra por letra. Depois de editar um .view.ts, confira se cada sobrescrita ainda nomeia uma propriedade existente; o -view.tree/*.view.tree.d.ts gerado ao lado da árvore é a lista com que comparar.
São propriedades de $mol_string: hint para o placeholder, enabled para o estado desabilitado, type para o tipo de entrada. Defina-as onde a entrada é usada:1<= Password $mol_string2 hint \Password3 type \password4 enabled <= can_edit true5 value?<=> password?\Qualquer outra propriedade de qualquer outro componente se acha do mesmo jeito: abra o .view.tree dela, como mostra Como ler os fontes.attr* é para atributos DOM de verdade que o componente ainda não modela, e tem uma armadilha própria: um bloco sem ^ na primeira linha substitui o dicionário de atributos inteiro da base, então um $mol_button escrito assim perde disabled, role e tabindex. Comece o bloco com ^ para herdar, e só então acrescente suas chaves:1attr *2^3 data_kind \primary
Uma string foi passada onde se espera uma lista, e a string foi espalhada caractere por caractere. Strings começam com \, listas começam com /. O caso de sempre é sub, que é uma lista:1sub /<= label \Hello
Uma sobrescrita caiu fora do .view.ts. A árvore dá a toda propriedade um padrão, então quando a classe para de redefinir rows(), o TypeScript fica satisfeito e a lista renderiza vazia. Testes que só checam o modelo seguem verdes porque o modelo está bem.Para cada sobrescrita de que a tela depende, escreva um teste que leia o que o usuário vê: rows(), sub(), title() das subviews, ou o DOM. Testes mostra as duas formas.
Um método @ $mol_mem retornou uma promise como valor: fetch(uri).then(...), um método async, ou o resultado de $mol_wire_async(this).load(). Uma promise dentro da célula significa, para todo mundo, «ainda calculando», e quando ela resolve a célula recalcula e produz uma promise nova. A rede funciona; a view nunca vê um resultado.A forma certa é síncrona: chame this.$.$mol_fetch.json(uri) dentro da célula e retorne o valor já parseado. A fibra suspende até a resposta chegar e então roda a célula de novo, então a promise nunca aparece no seu código. Onde o trabalho assíncrono precisa mesmo acontecer em outro lugar, ponha o resultado dele numa célula de estado separada e faça o efeito retornar uma flag ou uma chave, nunca a promise.Uma segunda causa é um erro engolido: um try/catch dentro de uma célula que captura a suspensão junto com as falhas de verdade. Relance tudo o que for uma Promise, ou use $mol_fail_catch, que faz essa checagem por você.
