UI 작성하기

rsx!, 위젯, 이벤트

Dioxus를 써 봤다면 대부분 익숙할 것입니다. 컴포넌트, 훅, 시그널, rsx!는 다른 렌더러에서와 똑같이 동작합니다. 이 프로젝트에만 있는 것은 닫힌 위젯 스키마, 키 이벤트를 소비하는 방식, 그리고 조합 중인 텍스트가 경계를 넘지 않는다는 규칙입니다.

앱의 뼈대

애플리케이션은 Element를 돌려주는 함수 하나와 launch 호출입니다. prelude가 위젯과 훅, 매크로를 함께 가져옵니다.

use dioxus_compose::prelude::*;

fn app() -> Element {
    let mut count = use_signal(|| 0i32);

    rsx! {
        Column {
            fill_max_width: true,
            Text { text: format!("count: {}", count()) }
            Button {
                text: "increment",
                on_click: move |_| count += 1,
            }
        }
    }
}

fn main() {
    dioxus_compose::launch(app);
}

launch는 LaunchBuilder::new().launch(app)의 축약입니다. 빌더가 갖는 설정은 지금은 루프 모드 하나입니다.

LaunchBuilder::new()
    .with_mode(LoopMode::Renderer)  // 데스크톱·iOS: Rust main이 렌더러를 돌립니다
    .launch(app);

LoopMode::Renderer가 기본값이고, 지금 실제로 도는 유일한 모드입니다. Android나 브라우저가 루프를 소유하고 Host를 불러 주는 LoopMode::Platform은 프로토콜에 정의만 되어 있고 구현은 없습니다.

위젯 집합

스키마는 의도적으로 닫혀 있습니다. 렌더러는 정확히 이 여덟 가지만 해석하고, 모르는 타입을 받으면 크래시 대신 ProtocolError 이벤트를 보냅니다. 위젯을 추가한다는 것은 Rust 스키마, Kotlin 인터프리터, 코드젠을 함께 넓히는 일입니다.

rsx! {
    dioxus_compose::Box {
        fill_max_width: true,
        Text { text: "qualified Box" }
    }
}

Modifier

Modifier는 값의 리스트로 직렬화됩니다. 예를 들면 [Padding(16), FillMaxWidth, Background(argb), Clickable(handler_id)]이고, 렌더러가 이것을 Compose Modifier 체인으로 되돌립니다. 지금 프로토콜에 있는 변형은 Empty, Padding, FillMaxWidth, FillMaxHeight, Width, Height, Size, Background, Clickable입니다.

이벤트 핸들러

핸들러는 평범한 Rust 클로저입니다. 그리고 동기로 호출됩니다. 렌더러가 자기 UI 스레드에서 Host를 부르고, 핸들러가 실행되고, diff가 계산되고, 그 결과 배치가 같은 호출에서 돌아옵니다. 큐에 쌓이는 것은 없습니다.

핸들러는 UI 스레드에서 돌기 때문에 가벼워야 합니다. PTY 읽기, 네트워크, 파일처럼 막히는 작업은 Host 워커 스레드의 몫입니다. 워커는 시그널만 갱신하고, 프레임 요청은 Host가 알아서 합니다. 경계 함수를 직접 부를 일은 없습니다.

이벤트 소비: Enter와 Shift+Enter

채팅 입력창에서는 Enter가 전송이고 Shift+Enter가 줄바꿈이어야 합니다. 그러려면 이 키를 처리했는지를 렌더러에게 동기로 알려 줘야 합니다. 웹의 preventDefault(), Compose의 PointerInputChange.consume()과 같은 모델입니다.

Dioxus 0.7의 핸들러는 반환값이 없습니다. 그래서 소비 표시를 이벤트 객체에 남기고, 경계가 그 값을 읽어 렌더러에 돌려줍니다. 렌더러 쪽에서는 Modifier.onKeyEvent가 처리됨으로 보고합니다.

TextField {
    placeholder: "Write a message",
    multiline: true,
    on_value_change: move |value| draft.set(value),
    on_key_down: move |event: KeyEvent| {
        if event.key() == Key::Enter && !event.shift_key() {
            let message = draft().trim().to_owned();
            if !message.is_empty() {
                messages.write().push(message);
                draft.set(String::new());
            }
            event.consume();   // 렌더러의 onKeyEvent가 true를 반환합니다
        }
    }
}

KeyEvent는 key(), shift_key(), ctrl_key(), alt_key(), meta_key()와 consume(), consumed()를 제공합니다. Key 열거형에는 지금 Key::Enter 하나뿐입니다. M0 스키마가 나르는 유일한 키이기 때문이고, 키를 늘리는 것은 앱 코드가 아니라 스키마를 고치는 일입니다.

비제어 TextField

TextField에는 value 속성이 없습니다. 편집 버퍼와 선택 영역, 조합 상태는 렌더러의 것입니다. Rust는 이벤트로만 변화를 알게 됩니다.

• on_value_change, 디바운스된 현재 텍스트 알림입니다.
• on_submit, 확정된 값입니다.
• on_focus_lost, 포커스를 잃었습니다.

이것은 단순화가 아니라 설계의 핵심입니다. 조합 중인 텍스트를 Host로 왕복시키면, 한글 한 글자를 만드는 동안의 모든 입력이 렌더러를 떠났다가 되돌아오며 조합을 리셋합니다. 한글은 자모를 모아 글자를 만들기 때문에 조합 도중의 리셋은 입력 자체를 망가뜨립니다. 일본어와 중국어 입력도 마찬가지입니다. 버퍼를 Kotlin에 두면 이 실패가 드문 일이 아니라 불가능한 일이 됩니다.

Host가 정말로 텍스트를 바꿔야 할 때, 전송 후 입력창을 비우거나 임시 저장한 초안을 되돌릴 때, 는 명시적인 SetText(node_id, text, selection) 명령을 쓰고, 렌더러는 조합이 끝날 때까지 적용을 미룹니다. Rust 쪽에서는 Host::set_text이며, 컴포넌트에서 부르는 API가 아니라 경계 표면의 일부입니다. 컴포넌트 코드에서 입력창을 비우는 보통의 방법은 필드에 새 정체성을 주는 것으로, 다른 Dioxus 렌더러에서와 같습니다.

상태는 어디에 있나