🚀 [React] React16과 Suspense, 직접 구현해보기 2

리팩토링

이제 내부 구현은 완료했으니, 이 유틸을 좀 더 쉽게 사용할 수 있도록 훅으로 만들어보자.

• Promise의 status와 result(error), suspender를 하나로 묶어 map 자료구조에 저장
  • createCustomPromise 를 통해 위 정보들을 구조화
• useFetch 에서는 customPromise의 상태에 따라 suspender를 던질지(pending), 에러를 던질지(rejected), 결과를 반환할지(fulfilled) 결정한다.
  • 이 때 suspender를 던지게 되면 pending이 Suspense에 갖히게 되는데, 이를 구분하기 위해 status의 초깃값을 null로 지정했다.
  • 이를 통해 처음에는 suspender를 던지고, 이후에 status가 pending이 감지되는 경우는 Suspense가 pending을 제대로 가두지 못한 상황으로 판단하고 에러를 던진다.

const PROMISE_STATUS = {
  PENDING: "pending",
  SUCCESS: "fulfilled",
  FAIL: "rejected",
};

const promiseStoreMap = new Map();

const createCustomPromise = (asyncFunction) => {
  const customPromise = {
    status: null,
    result: null,
    error: null,
  };

  const suspender = async () => {
    // 기존 suspender 부분
    try {
      customPromise.status = PROMISE_STATUS.PENDING;
      customPromise.result = await asyncFunction();
      customPromise.status = PROMISE_STATUS.SUCCESS;
    } catch (err) {
      customPromise.status = PROMISE_STATUS.FAIL;
      customPromise.error = err;
    }
  };

  customPromise.run = suspender;
  return customPromise;
};

function useFetch(key, asyncFunction) {
  if (!promiseStoreMap.has(key)) {
    promiseStoreMap.set(key, createCustomPromise(asyncFunction));
  }

  const customPromise = promiseStoreMap.get(key);
  if (customPromise.status === null) {
    throw customPromise.run(); // suspender
  } else if (customPromise.status === PROMISE_STATUS.FAIL) {
    throw customPromise.error;
  }

  if (customPromise.stauts === PROMISE_STATUS.PENDING) {
    // status의 초기 상태는 null이고 이후에 pending으로 바뀐 뒤, fulfilled 혹은 rejected가 된다.
    // pending일 경우 suspense에 갖히게 될 텐데, 여기서 감지될 경우는 suspense의 동작이 잘못된 것
    throw new Error("Suspense Error");
  }

  return { data: customPromise.result };
}

export default useFetch;

QueryKey를 고도화 할 수 있지 않을까?

react-query와 같이 queryKey를 배열로 넘긴다던가, 캐싱 등을 구현할 수 있지 않을까에 대한 생각이 스쳐 지나갔다.

우선 첫 번째로 queryKey를 배열로 넘길 수 있도록 변경했다.

이를 위해서 map.has()와 map.get()을 key 가 배열일 경우에도 사용할 수 있도록 변경이 필요했다. lodash의 isEqual을 통해 배열이 같은 배열인지 비교하고 필요한 값을 반환한다.

const hasKey = (key) => {
  let isExist = false;
  promiseStoreMap.forEach((value, _key) => {
    if (_isEqual(_key, key)) {
      isExist = true;
    }
  });
  return isExist;
};

const getByKey = (key) => {
  let mapValue = null;
  promiseStoreMap.forEach((value, _key) => {
    if (_isEqual(_key, key)) {
      mapValue = value;
    }
  });
  return mapValue;
};

function UserListAxios() {
  const ids = [1, 1, 3, 4, 5, 6];
  return (
    <div>
      <h3>유저 프로필 리스트입니다.</h3>
      {ids.map((id) => {
        return (
          <div key={id}>
            <AsyncBoundary
              pendingFallback={<div>로딩중...</div>}
              rejectedFallback={(e) => <div>에러 발생!!!{e.message}</div>}
            >
              <UserItemAxios id={id} />
            </AsyncBoundary>
            <hr />
          </div>
        );
      })}
    </div>
  );
}

export default UserListAxios;

이 경우에 동일한 쿼리 키를 넘겨받을 경우 아래 화면과 같이 에러가 발생해버리는데,

우리는 동일한 쿼리 키가 넘어왔을 때는 이전에 캐싱된 값을 반환하도록 변경해줄것이다.

에러는 왜 발생할까?

useFetch 하단에 추가한 바로 아래 부분에 걸려서 에러를 throw 하게 된 것인데, 동일한 queryKey로 호출했을 경우 두 번째는 당연히 첫 번째에서 던진 suspender가 있기 때문에 pending 상태가 된다.

  if (customPromise.stauts === PROMISE_STATUS.PENDING) {
    // status의 초기 상태는 null이고 이후에 pending으로 바뀐 뒤, fulfilled 혹은 rejected가 된다.
    // pending일 경우 suspense에 갖히게 될 텐데, 여기서 감지될 경우는 suspense의 동작이 잘못된 것
    throw new Error("Suspense Error");
  }

따라서 해당 조건문에 들어왔을 때 이미 던져진 suspender가 있다면 바로 그 suspender를 똑같이 던지면 된다.

이 때 주의해야 하는 부분은 pending일 때 throw 하는 suspender는 이전에 던진 suspender여야 한다는 점이다. throw customPromise.run()을 해버리면 새로운 proimse가 실행되기 때문에 network 탭에서 보면 불필요하게 요청이 한 번 더 가는 것을 확인할 수 있다.

수정한 코드는 아래와 같다.

if (customPromise.status === null) {
    // 같은 queryKey 값으로 불렸을 경우, 같은 promise를 바라볼 수 있도록 cache에 실행한 suspender(.run())를 담아준다.
    customPromise.cache = customPromise.run(); // 추가된 부분
    throw customPromise.run(); // suspender
  } else if (customPromise.status === PROMISE_STATUS.FAIL) {
    throw customPromise.error;
  }

  if (customPromise.status === PROMISE_STATUS.PENDING) {
    if (customPromise.cache) {
      // 캐시된 값이 있을 경우 해당 suspender를 다시 던지고 이외의 경우에는 에러로 판단
      throw customPromise.cache; // 추가된 부분
    }
    throw new Error("Suspense Error");
  }

다른 수정 사항으로는 배열로 받은 queryKey를 그대로 map 의 key 로 사용하지 않고 JSON.stringify를 해서 string 타입의 key로 쓸 수 있게 변경했다. (배열을 key로 쓸 경우, set, get, has 등에서 원하는대로 동작하지 않아 따로 만들어 줬어야 했음)

완성된 코드는 아래와 같다!

const PROMISE_STATUS = {
  PENDING: "pending",
  SUCCESS: "fulfilled",
  FAIL: "rejected",
};

const promiseStoreMap = new Map();
window.promiseMap = promiseStoreMap;

const createCustomPromise = (asyncFunction) => {
  const customPromise = {
    status: null,
    result: null,
    error: null,
    cache: null,
  };

  const suspender = async () => {
    // 기존 suspender 부분
    try {
      customPromise.status = PROMISE_STATUS.PENDING;
      customPromise.result = await asyncFunction();
      customPromise.status = PROMISE_STATUS.SUCCESS;
    } catch (err) {
      customPromise.status = PROMISE_STATUS.FAIL;
      customPromise.error = err;
    }
  };

  customPromise.run = suspender;
  return customPromise;
};

function useFetch(key, asyncFunction) {
  const parsedKey = JSON.stringify(key);
  if (!promiseStoreMap.has(parsedKey)) {
    promiseStoreMap.set(parsedKey, createCustomPromise(asyncFunction));
  }

  const customPromise = promiseStoreMap.get(parsedKey);

  if (customPromise.status === null) {
    // 같은 queryKey 값으로 불렸을 경우, 같은 promise를 바라볼 수 있도록 cache에 실행한 suspender(.run())를 담아준다.
    customPromise.cache = customPromise.run();
    throw customPromise.run(); // suspender
  } else if (customPromise.status === PROMISE_STATUS.FAIL) {
    throw customPromise.error;
  }

  if (customPromise.status === PROMISE_STATUS.PENDING) {
    // status의 초기 상태는 null이고 이후에 pending으로 바뀐 뒤, fulfilled 혹은 rejected가 된다.
    // pending일 경우 suspense에 갖히게 될 텐데, 여기서 감지될 경우는 suspense의 동작이 잘못된 것
    if (customPromise.cache) {
      // 캐시된 값이 있을 경우 해당 suspender를 다시 던지고 이외의 경우에는 에러로 판단
      throw customPromise.cache;
      // throw customPromise.run();
    }
    throw new Error("Suspens Error");
  }

  return { data: customPromise.result };
}

export default useFetch;

결론

react-query가 아닌 다른 비동기 데이터 패칭 시에도 사용할 수 있는 훅을 만들어보며, Suspense의 기본 원리에 대해서 이해할 수 있었다.

ErrorBoundary가 throw 한 Error를 감지하듯 Suspense는 throw 한 Promise를 감지한다.

때문에 데이터 패칭 시에 Promise의 상태에 따라 response를 리턴하거나 error를 던지거나, pending일 경우 promise를 던질 수 있는 구조를 추가한 것 만으로 promise를 suspense에 가둘 수 있게 되었다.

→ react-query의 suspense 옵션과 React.Suspense를 사용하는 것은 문제가 되지 않을 것 같다.

또한 SSR을 지원하기 위해 SSRSuspender를 만들었는데, 여기서는 mount 되지 않았을 때 fallback을 내려주도록 하는 부분만 추가하는 것으로 개발할 수 있었다.

• BOJ 36
• Algorithm 12
• CodingTest 11
• Web 9
• Javascript 8
• Vue 7
• React 7
• DBProject 4
• Python 3
• Tech-interview 3
• Express 3
• Next 3
• Github 2
• Django 2
• C 1
• C++ 1
• WebGame 1