Każdy wpis na tej stronie ma ten sam kształt: build jest zielony, audyt czysty, konsola milczy, a ekran jest pusty albo pokazuje nie to, o co ci chodziło. Kompilator nie widzi tych pomyłek, bo każda z nich to poprawny program, który akurat opisuje inny komponent. Znajdź nagłówek brzmiący jak to, co widzisz; pod nim jest przyczyna i naprawa.
Nazwa w view.tree i nazwa metody w klasie różnią się, najczęściej wielkością liter: exchange_form w drzewie, exchangeForm w klasie. To dwie właściwości. Tej z klasy nikt nie wywołuje, ta z drzewa zostaje przy wartości domyślnej i nic tego nie zgłasza.Nazwy wszędzie są w snake_case i muszą zgadzać się co do litery. Po edycji .view.ts sprawdź, czy każde nadpisanie nadal nazywa istniejącą właściwość; wygenerowany -view.tree/*.view.tree.d.ts obok drzewa to lista do porównania.
To właściwości $mol_string: hint na placeholder, enabled na stan wyłączenia, type na typ pola. Ustaw je tam, gdzie pole jest użyte:1<= Password $mol_string2 hint \Password3 type \password4 enabled <= can_edit true5 value?<=> password?\Każdą inną właściwość dowolnego innego komponentu znajduje się tak samo: otwórz jego .view.tree, jak pokazuje Jak czytać źródła.attr* służy do prawdziwych atrybutów DOM, których komponent jeszcze nie modeluje, i ma własną pułapkę: blok bez ^ w pierwszej linii zastępuje cały słownik atrybutów bazy, więc $mol_button napisany w ten sposób traci disabled, role i tabindex. Zacznij blok od ^, żeby odziedziczyć, a potem dodaj swoje klucze:1attr *2^3 data_kind \primary
Ciąg znaków trafił tam, gdzie oczekiwana jest lista, i został rozłożony znak po znaku. Ciągi zaczynają się od \, listy od /. Typowy przypadek to sub, które jest listą:1sub /<= label \Hello
Nadpisanie wypadło z .view.ts. Drzewo daje każdej właściwości wartość domyślną, więc gdy klasa przestaje definiować rows() na nowo, TypeScript jest zadowolony, a lista renderuje się pusta. Testy sprawdzające sam model zostają zielone, bo z modelem wszystko jest w porządku.Dla każdego nadpisania, od którego zależy ekran, napisz test czytający to, co widzi użytkownik: rows(), sub(), title() podwidoków albo DOM. Testowanie pokazuje oba sposoby.
Metoda @ $mol_mem zwróciła jako wartość obietnicę: fetch(uri).then(...), metodę async albo wynik $mol_wire_async(this).load(). Obietnica w komórce czyta się dla wszystkich jako „wciąż liczę”, a gdy się rozwiąże, komórka przelicza się i produkuje świeżą obietnicę. Sieć działa; widok nigdy nie zobaczy wyniku.Właściwy kształt jest synchroniczny: wywołaj this.$.$mol_fetch.json(uri) wewnątrz komórki i zwróć sparsowaną wartość. Włókno zawiesza się do nadejścia odpowiedzi, a potem uruchamia komórkę jeszcze raz, więc obietnica w ogóle nie pojawia się w twoim kodzie. Tam, gdzie praca asynchroniczna musi dziać się gdzie indziej, odłóż jej wynik do osobnej komórki stanu, a efekt niech zwraca flagę albo klucz, nigdy obietnicę.Druga przyczyna to połknięty błąd: try/catch wewnątrz komórki, który łapie zawieszenie razem z prawdziwymi awariami. Przerzuć dalej wszystko, co jest Promise, albo użyj $mol_fail_catch, które robi to sprawdzenie za ciebie.
