[ FE ] 우리가 홈페이지를 만들 때 고려해야할 사항은 뭘까?-2

4. 서버와의 데이터 교환을 제어합니다.

WWW가 구상되었을 당시 클라이언트와 서버 간의 데이터 교환은 몇 가지 방법으로 제한되었습니다.

• 링크를 클릭하면  GET 새 페이지가 나타나고 새 페이지가 렌더링됩니다.
• 양식을 제출하면   새 페이지가 렌더링됩니다 POST . GET
• 이미지나 객체를 포함하면  GET 비동기적으로 렌더링됩니다.

 

허나, 여기에는 2가지 문제점이 있습니다. 새 페이지로만 데이터를 보낼 수 있으며 무엇보다도 뒤로 가기 버튼을 할 수 없다는 것이다.

데이터를 보낼 때마다 새 페이지를 불러오기
뒤로 가기 버튼이 제대로 동작하지 않는 문제 발생

이와 같은 문제는 Javascript와 AJAX를 통해서 해결 가능해집니다. 다시 말해 사용자 경험이 좋아집니다. 이걸 React 관점으로 바꾸면

 

비동기 데이터 처리

import { useState, useEffect } from "react";
import axios from "axios";

const FetchDataComponent = () => {
  const [data, setData] = useState(null);
  const [loading, setLoading] = useState(true);
  const [error, setError] = useState(null);

  useEffect(() => {
    const fetchData = async () => {
      try {
        const response = await axios.get("/api/data");
        setData(response.data);
      } catch (err) {
        setError(err.message);
      } finally {
        setLoading(false);
      }
    };

    fetchData();
  }, []);

  if (loading) return <p>Loading...</p>;
  if (error) return <p>Error: {error}</p>;

  return <div>{JSON.stringify(data)}</div>;
};

 

webSocket을 이용한 실시간 데이터 처리

 

import { useEffect, useState } from "react";

const WebSocketComponent = () => {
  const [messages, setMessages] = useState<string[]>([]);

  useEffect(() => {
    const socket = new WebSocket("wss://example.com/socket");

    socket.onmessage = (event) => {
      setMessages((prev) => [...prev, event.data]);
    };

    socket.onerror = () => {
      console.error("WebSocket error");
    };

    return () => {
      socket.close(); // Clean up WebSocket connection
    };
  }, []);

  return (
    <div>
      {messages.map((msg, idx) => (
        <p key={idx}>{msg}</p>
      ))}
    </div>
  );
};

 

 

5. 역사를 깨지 말고, 역사를 강화하세요

양식 제출은 제쳐두고, 하이퍼링크만으로 최신 웹 애플리케이션을 디자인한다면, 완벽하게 기능하는 뒤로/앞으로 탐색 기능을 갖추게 될 것입니다.

예를 들어, 전형적인 "무한 페이징 시나리오"를 생각해 보세요. 일반적으로 구현되는 방식은 JavaScript로 클릭을 캡처하고, 데이터/HTML을 요청하고, 주입하는 것입니다.  history.pushState 또는  replaceState 호출을 하는 것은 선택 사항이지만, 불행히도 많은 사람이 취하지 않습니다.

이제 JavaScript로 기록을 제어할 수 있게 되어 기록을 향상시킬 수 있는 새로운 기회가 생겨났습니다. 그러한 기회 중 하나는 다니엘 피피우스가  Fast Back 이라고 명명한 것입니다 .

빠르게 돌아올 것입니다. 사용자는 데이터가 크게 변경되었을 것으로 기대하지 않습니다.

 

캐싱 동작을 제어할 수 없는 경우가 몇 가지 있습니다. 예를 들어, 페이지를 렌더링한 다음 타사 웹사이트로 이동하고 사용자가 다시 클릭하는 경우입니다. 서버에서 HTML을 렌더링한 다음 클라이언트에서 수정하는 애플리케이션은 특히 이 미묘한 버그의 위험이 있습니다.

탐색을 중단하는 또 다른 방법은 스크롤 메모리를 무시하는 것입니다. 다시 한번, JS와 수동 기록 관리에 의존하지 않는 페이지는 이 문제가 없을 가능성이 큽니다. 하지만 동적 페이지는 보통 문제가 있습니다. 저는 웹에서 가장 인기 있는 두 개의 JavaScript 기반 뉴스피드인 Twitter와 Facebook을 테스트했습니다. 둘 다  스크롤 기억 상실증을 보였습니다 .

JavaScript로 URL 변경 없이 상태를 관리하는 경우, 탐색 기록과 상태 간의 불일치가 발생할 수 있습니다.

마지막으로, 기록을 탐색하는 동안만 관련성이 있는 상태 변경 사항을 인식하십시오. 주석 하위 트리 표시를 토글하는 이 예를 고려하십시오.

캐싱 및 빠른 탐색은 문제를 해결하기 위한 기회지만, 구현 방식에 따라 문제를 악화시킬 수도 있습니다.
예: 클라이언트에서 수정된 페이지가 서버의 HTML과 불일치하거나, 이전 상태를 제대로 복원하지 못할 수 있음.

 

6. 코드 업데이트 푸시

첫째, 가능한 오류에 대한 표면을 줄이고 신뢰성을 높입니다. 백엔드 API에 중대한 변경을 가하면 클라이언트의 코드를  업데이트 해야 합니다. 그렇지 않으면 새 데이터를 이해하지 못하거나 호환되지 않는 형식으로 데이터를 보낼 수 있습니다. 즉 백엔드 API 변경으로 인해 클라이언트와 호환되지 않으면 오류가 발생하거나 데이터를 잘못 처리할 수 있습니다.

또 다른 똑같이 중요한 이유는 원칙 #3의 구현과 관련이 있습니다. UI가 자체 업데이트되는 경우 사용자가 페이지 새로 고침을 트리거할 이유가 거의 없습니다. 페이지 새로고침 없이 코드와 데이터를 최신 상태로 유지하려면 효율적인 코드 업데이트 메커니즘이 필요합니다.

기존 웹사이트에서 페이지 새로 고침은 두 가지 일을 수행한다는 점을 명심하세요. 데이터 다시 로드와 코드 다시 로드입니다. 코드를 푸시할 메커니즘 없이 데이터를 푸시하는 메커니즘을 설정하는 것만으로는 충분하지 않습니다. 특히 단일 탭(세션)이 매우 오랫동안 열려 있을 수 있는 세상에서는 더욱 그렇습니다.

핫 코드 리로딩과 모듈식 아키텍처를 통해 특정 부분만 업데이트하고 부작용을 최소화할 수 있습니다.

 

7. 행동 예측

풍부한 JavaScript 애플리케이션은  최종 사용자 입력을 예측하는 메커니즘을 갖출 수 있습니다.

이 아이디어의 가장 일반적인 응용 분야는 액션이 ​​완료되기 전에 서버에서 데이터를 선제적으로 요청하는 것입니다. 하이퍼링크에 마우스를 올려놓으면 데이터를 페치하여 클릭할 때 준비가 되도록 하는 것은 간단한 예입니다.

 

React Suspense와 Data Fetching

• React의 Suspense를 사용하여 데이터를 선제적으로 로드.
• 예: 사용자가 특정 버튼에 마우스를 올리면 관련 데이터를 fetch하여 준비.

Prefetching 데이터

• React Query 또는 TanStack Query를 사용하여 링크나 버튼 호버 시 데이터를 미리 가져옴.
• onMouseEnter 이벤트를 활용해 사용자가 액션을 수행하기 전에 데이터를 로드.

예측 기반 Fetching

• 사용자 입력과 마우스 움직임을 분석해 예측.
• 예: 마우스 궤적을 감지하여 사용자가 클릭할 가능성이 높은 영역의 데이터를 선제적으로 로드.
• React 컴포넌트 내에서 onMouseMove 이벤트를 활용.

 

 

출처

 

7 Principles of Rich Web Applications