이 페이지의 모든 항목은 같은 모양입니다. 빌드는 초록이고, 감사는 깨끗하고, 콘솔은 조용한데, 화면은 비어 있거나 의도한 것과 다릅니다. 컴파일러가 이 실수들을 볼 수 없는 이유는, 하나하나가 유효한 프로그램이면서 다른 컴포넌트를 기술하고 있을 뿐이기 때문입니다. 지금 보고 있는 것과 비슷하게 들리는 제목을 찾으세요. 그 아래에 원인과 고치는 법이 있습니다.
view.tree의 이름과 클래스의 메서드 이름이 다릅니다. 대개는 대소문자 차이입니다. 트리에는 exchange_form, 클래스에는 exchangeForm. 이것은 두 개의 프로퍼티입니다. 클래스 쪽은 결코 호출되지 않고, 트리 쪽은 기본값을 지키며, 아무도 그것을 알려 주지 않습니다.이름은 어디서나 snake_case이고 글자 하나까지 일치해야 합니다. .view.ts를 편집한 뒤에는 모든 오버라이드가 여전히 실재하는 프로퍼티를 가리키는지 확인하세요. 맞춰 볼 목록은 트리 옆에 생성되는 -view.tree/*.view.tree.d.ts입니다.
모두 $mol_string의 프로퍼티입니다. 플레이스홀더는 hint, 비활성 상태는 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
오버라이드가 .view.ts에서 빠졌습니다. 트리는 모든 프로퍼티에 기본값을 주므로, 클래스가 rows()를 다시 정의하기를 멈춰도 TypeScript는 만족하고 리스트는 비어 있는 채로 렌더링됩니다. 모델만 확인하는 테스트는 모델이 멀쩡하므로 초록으로 남습니다.화면이 의존하는 모든 오버라이드에 대해, 사용자가 보는 것을 읽는 테스트를 쓰세요. rows(), sub(), 서브뷰의 title(), 또는 DOM입니다. 테스트가 그 둘 다 보여 줍니다.
@ $mol_mem 메서드가 promise를 값으로 반환했습니다. fetch(uri).then(...), async 메서드, 또는 $mol_wire_async(this).load()의 결과입니다. 셀 안의 promise는 모두에게 "아직 계산 중"으로 읽히고, 그것이 해결되면 셀은 다시 계산되어 새 promise를 만들어 냅니다. 네트워크는 동작하는데, 뷰는 결과를 한 번도 보지 못합니다.올바른 모양은 동기적입니다. 셀 안에서 this.$.$mol_fetch.json(uri)를 호출하고 파싱된 값을 반환하세요. 파이버는 응답이 들어올 때까지 중단했다가 셀을 다시 돌리므로, promise가 여러분의 코드에 나타나는 일은 없습니다. 비동기 작업이 다른 곳에서 일어나야 한다면, 그 결과를 별도의 상태 셀에 넣고 이펙트는 플래그나 키를 반환하게 하세요. promise는 결코 반환하게 하지 마세요.두 번째 원인은 삼켜진 오류입니다. 셀 안의 try/catch가 진짜 실패와 함께 중단까지 잡아 버리는 경우입니다. Promise인 것은 다시 던지거나, 그 검사를 대신해 주는 $mol_fail_catch를 쓰세요.
@ $mol_mem 메서드가 다른 셀에 썼거나, 자기가 읽었던 것을 결국 무효화하는 부수 효과를 일으켰습니다. 계산은 읽고 반환할 뿐입니다. 쓰기, 네트워크, 타이머, DOM은 @ $mol_action 핸들러에 속합니다. 같은 메시지의 또 다른 출처는 자식으로 가는 <=> 바인딩과, 바로 그 자식에게 위임하는 클래스의 메서드가 겹친 경우입니다. 다음 항목에서 설명합니다.
이것을 만드는 모양은 둘입니다. 첫째, 트리에서 자식에 tab?<=>tab?가 있고 클래스에 tab(){return this.Head().tab()}가 있는 경우입니다. 자식이 소유자에게 묻고, 소유자가 자식에게 묻습니다. 위임하는 그 자식으로 가는 <=>를 없애세요.둘째, 서브뷰의 타입을 여러분의 클래스로 바꾸었는데 그 클래스가 트리에 나열된 프로퍼티에서 super를 호출하는 경우입니다. 그 super는 기반 구현이 아니라 나열된 바인딩을 위해 트리가 생성한 스텁이고, 스텁은 소유자에게 도로 위임합니다. 대신 원래 구현에 명시적으로 위임하세요. 아래의 타입 재지정 항목을 보세요.
