dioxus api 요청 방식 정리

🚀 Dioxus 비동기 API 요청 방식 비교 및 추천

Dioxus에서 비동기 API 요청을 처리하는 방식에는 use_future, use_coroutine, use_resource, use_signal + spawn_local 등이 있습니다.
각 방식은 사용 목적과 장단점이 다르므로, 어떤 상황에서 어떤 방식을 써야 하는지 정리해 보겠습니다.

---

✅ 1. use_future – 1회성 비동기 요청

📌 설명

• 특정 상태 변화가 있을 때 한 번만 비동기 요청을 실행하는 방식.
• React의 useEffect(() => fetchData(), [deps])와 비슷한 개념.

💡 사용 예제

#[component]
fn FetchDataWithFuture() -> Element {
    let data_future = use_future(|| async {
        get_server_data().await.unwrap_or_else(|_| "Failed to fetch data".to_string())
    });

    rsx! {
        div {
            match data_future() {
                Some(data) => rsx! { "Server Response: {data}" },
                None => rsx! { "Loading..." }
            }
        }
    }
}

✅ 장점

✔ 한 번만 실행됨 → 불필요한 API 요청 방지
✔ 단순한 데이터 가져오기에 적합

❌ 단점

✖ 수동 갱신이 어렵다 → 새로운 요청을 보내려면 use_future를 다시 생성해야 함
✖ 초기 렌더링에서 항상 실행됨

🔥 추천 상황

• 컴포넌트가 처음 렌더링될 때 API 요청이 필요한 경우
• 데이터 갱신이 거의 필요 없는 경우

---

✅ 2. use_resource – 데이터 로딩 및 자동 갱신

📌 설명

• 비동기 데이터를 자동으로 가져오고, UI와 연동하여 업데이트
• React의 useQuery(React Query)와 비슷한 개념

💡 사용 예제

#[component]
fn FetchDataWithResource() -> Element {
    let data_resource = use_resource(|| async {
        get_server_data().await.unwrap_or_else(|_| "Failed to fetch data".to_string())
    });

    rsx! {
        div {
            match data_resource() {
                Some(data) => rsx! { "Server Response: {data}" },
                None => rsx! { "Loading..." }
            }
        }
    }
}

✅ 장점

✔ 자동으로 데이터를 가져오고 관리 → 불필요한 수동 업데이트 필요 없음
✔ UI와 연동하여 변경 감지 가능

❌ 단점

✖ 새로운 요청을 보내려면 상태를 리셋해야 함
✖ 데이터 변경 시 갱신 로직이 필요할 수 있음

🔥 추천 상황

• 초기 데이터를 자동으로 불러오고, 필요하면 갱신할 수 있도록 해야 할 때
• UI 업데이트와 자동으로 동기화해야 할 때

---

✅ 3. use_signal + spawn_local – 명시적 API 호출

📌 설명

• use_signal로 상태를 관리하고, spawn_local을 사용하여 비동기 데이터를 명시적으로 가져옴
• React의 useState + useEffect 패턴과 비슷

💡 사용 예제

#[component]
fn FetchDataWithSignal() -> Element {
    let mut response = use_signal(String::new);
    let mut is_loading = use_signal(|| false);

    rsx! {
        div {
            button {
                class: "border p-2 rounded-sm",
                onclick: move |_| {
                    is_loading.set(true);
                    spawn_local(async move {
                        match get_server_data().await {
                            Ok(data) => response.set(data),
                            Err(_) => response.set("Failed to fetch data".to_string()),
                        }
                        is_loading.set(false);
                    });
                },
                "Fetch Data"
            }
            p { 
                if is_loading() { "Loading..." } else { "{response}" }
            }
        }
    }
}

✅ 장점

✔ 사용자가 원할 때 API 요청 가능 → 불필요한 요청 방지
✔ 로딩 상태 및 오류 처리 간편
✔ 버튼 클릭 등 특정 이벤트에서 요청하기 좋음

❌ 단점

✖ 자동 갱신 기능 없음 → 데이터 갱신을 원하면 직접 관리해야 함

🔥 추천 상황

• 사용자 액션(버튼 클릭 등)에 따라 API를 호출해야 할 때
• 로딩 상태와 오류 처리를 명확히 관리해야 할 때

---

✅ 4. use_coroutine – 이벤트 기반 비동기 처리

📌 설명

• 비동기 이벤트를 처리하는 스트림 기반 방식
• 실시간 데이터 흐름, WebSocket 연결 등 지속적인 데이터 감시에 유용
• React의 useEffect + WebSocket과 유사

💡 사용 예제

#[component]
fn FetchDataWithCoroutine() -> Element {
    let mut response = use_signal(String::new);
    
    let coroutine = use_coroutine(|rx| async move {
        while let Some(_) = rx.next().await {
            if let Ok(data) = get_server_data().await {
                response.set(data);
            }
        }
    });

    rsx! {
        div {
            button {
                class: "border p-2 rounded-sm",
                onclick: move |_| coroutine.send(()),
                "Fetch Data"
            }
            p { "{response}" }
        }
    }
}

✅ 장점

✔ 비동기 이벤트 기반 동작 가능 → 특정 이벤트 발생 시 데이터 요청
✔ 실시간 데이터 감시(WebSocket 등) 가능
✔ 여러 개의 요청을 효율적으로 처리할 수 있음

❌ 단점

✖ 일반적인 API 요청에는 오버킬
✖ 비동기 흐름 관리가 다소 복잡

🔥 추천 상황

• 주기적인 데이터 갱신이 필요할 때 (WebSocket, 실시간 업데이트 등)
• 여러 개의 API 요청을 연속해서 처리해야 할 때

---

🚀 Dioxus 비동기 API 방식 비교 정리

방식	사용 목적	장점	단점	추천 상황
use_future	1회성 API 요청	단순, 불필요한 재실행 방지	수동 갱신 어려움	초기 렌더링 시 API 요청
use_resource	자동 데이터 로딩	UI 자동 갱신, 유지보수 쉬움	새로운 요청 트리거 어려움	자동으로 데이터 가져오고 관리
use_signal + spawn_local	명시적 API 호출	로딩/에러 관리 쉬움, 요청 제어 가능	자동 갱신 없음	버튼 클릭 시 API 요청
use_coroutine	이벤트 기반 비동기 처리	실시간 감시 가능, 다중 요청 관리	일반적인 API 요청에는 불필요하게 복잡	WebSocket, 실시간 API 요청

---

🎯 결론: 어떤 방식을 선택할까?

• 한 번만 데이터를 불러오고 끝 → use_future
• 초기 로딩 후 자동 갱신 필요 → use_resource
• 버튼 클릭 등 사용자 이벤트 기반 요청 → use_signal + spawn_local
• 실시간 업데이트(WebSocket, 주기적 요청 등) → use_coroutine

⚡ 대부분의 경우 use_signal + spawn_local이 가장 유연하고 추천됨!
그러나 상황에 따라 적절한 방식을 선택하는 것이 중요합니다. 🎯