У каждой записи на этой странице одна и та же форма: сборка зелёная, аудит чистый, консоль молчит, а на экране пусто или не то, что вы задумывали. Компилятор этих ошибок не видит, потому что каждая из них — корректная программа, просто описывающая другой компонент. Найдите заголовок, похожий на то, что вы видите; под ним причина и лечение.
Имя в view.tree и имя метода в классе разошлись, чаще всего регистром: exchange_form в дереве, exchangeForm в классе. Это два разных свойства. Классовое никто не вызывает, древесное остаётся со значением по умолчанию, и никто об этом не сообщает.Имена везде snake_case и должны совпадать буква в букву. После правки .view.ts проверьте, что каждое переопределение по-прежнему называет существующее свойство; список для сверки — сгенерированный -view.tree/*.view.tree.d.ts рядом с деревом.
Это свойства $mol_string: hint — placeholder, enabled — выключенное состояние, type — тип поля. Задавайте их там, где поле используется:1<= Password $mol_string2 hint \Password3 type \password4 enabled <= can_edit true5 value?<=> password?\Любое другое свойство любого другого компонента ищется так же: откройте его .view.tree, как показывает раздел Как читать исходники.attr* нужен для настоящих DOM-атрибутов, которые компонент ещё не моделирует, и у него своя ловушка: блок, у которого первой строкой не идёт ^, заменяет весь словарь атрибутов базы, так что написанный этак $mol_button теряет disabled, role и tabindex. Начните блок с ^, чтобы унаследовать, а потом добавляйте свои ключи:1attr *2^3 data_kind \primary
Строку передали туда, где ожидается список, и её растащило по символам. Строки начинаются с \, списки — с /. Обычный случай — sub, это список:1sub /<= label \Hello
Переопределение выпало из .view.ts. Дерево даёт каждому свойству значение по умолчанию, поэтому, когда класс перестаёт переопределять rows(), TypeScript доволен, а список рендерится пустым. Тесты, проверяющие только модель, остаются зелёными, потому что с моделью всё в порядке.На каждое переопределение, от которого зависит экран, пишите тест, читающий то, что видит пользователь: rows(), sub(), title() под-вью или DOM. Тестирование показывает и то, и другое.
Метод с @ $mol_mem вернул промис в качестве значения: fetch(uri).then(...), async-метод или результат $mol_wire_async(this).load(). Промис в ячейке читается всеми как «всё ещё вычисляется», а когда он разрешается, ячейка пересчитывается и выдаёт свежий промис. Сеть работает, вью результата не видит никогда.Правильная форма синхронная: вызовите this.$.$mol_fetch.json(uri) внутри ячейки и верните разобранное значение. Фибра приостановится, пока не придёт ответ, и перезапустит ячейку, так что промис в вашем коде не появляется вовсе. Там, где асинхронная работа всё-таки должна происходить в стороне, кладите её результат в отдельную ячейку состояния, а эффект пусть возвращает флаг или ключ, но не промис.Вторая причина — проглоченная ошибка: try/catch внутри ячейки, который ловит приостановку заодно с настоящими сбоями. Перебрасывайте всё, что является Promise, или пользуйтесь $mol_fail_catch, который делает эту проверку за вас.
