api 로직 정리

[msdio]

@sumi-0011 @coolsmart2
api 요청 쪽을 정리해봤어요. 이렇게 스타일을 통일하면 어떨까 하는데, 의견 남겨주세요!
데이터 흐름 순으로 작성해봤습니다.

apis > index.ts
인터셉터에서 아래와 같이 에러를 일괄적으로 처리합니다.

async function (error: AxiosError) {
  const { response } = error;

  return await Promise.reject(response?.data);
},

전체 코드는 아래처럼 변경될 것 같아요.

const createApiWithoutAuth = () => {
  const _request = axios.create({
    baseURL: process.env.NEXT_PUBLIC_SERVER_URL,
  });

  _request.interceptors.response.use(
    function (data) {
      return data;
    },
    async function (error: AxiosError) {
      const { response } = error;

      return await Promise.reject(response?.data);
    },
  );

  return _request;
};

types > apiResponse.ts
api 응답을 위한 interface를 설계해 놓았습니다.

export interface ApiResponse {
  code: number;
  description: string;
  data?: Record<string, any>;
}

export interface ApiErrorResponse extends Error {
  code: number;
  description: string;
}

apis > someFile
인터셉터에서 에러 처리를 하고 있으므로, 여기서는 error를 throw 해주기만 하면 됩니다.

export const someAPI = async (props) => {
  try {
    const response = await requestWithoutAuth.get({...some args});

    return response.data as ApiResponse;
  } catch (error) {
    throw new Error(error);
  }
};

components > someComponent.tsx

const handlerFunction = async () => {
  try {
    const data = await someAPI(args);

    if (data.code === SUCCESS) { //여기 코드 상수처리한 부분은 아래에 적어놓을게요!
        //성공 시의 로직
    } else if (data.code === EMAIL_DUPLICATE) {
        //이 경우의 로직
    }
  } catch (error) {
    //typescript 4.4 버전 부터는 error 타입이 unknown이기 때문에, 아래와 같이 에러 타입을 단언해서 사용해야 합니다.
    const customError = error as ApiErrorResponse;
    alert(customError.description); //서버에서 내려주는 description을 바로 사용합니다.
  }
};

constants > responseCode.ts
서버에서 뿌려주는 에러 코드들은 아래와 같이 상수로 사용합니다.

const SUCCESS = 1000;
const EMAIL_DUPLICATE = 3001;

export { EMAIL_DUPLICATE, SUCCESS };

이렇게 일괄적으로 api를 사용하는게 어떤가 싶어요.
기존에 윤우님이 instanceof로 사용하는 것들은 서버에서 code와 description을 주는데도 프론트에서 한번 더 내려서 쓰는 느낌이라 코드도 길어지고 분기도 너무 많이 되는 것 같아요.

예를 들면, 아래와 같이 코드 양이 줄고 일괄적으로 처리할 수 있을 것 같아요. 의견 남겨주세요 🙂

[sumi-0011]

따로따로 후처리 하지않고도, 깔끔하게 처리될수 있는 방식이라 좋은것 같습니다!

그런데 이 방식을 사용한다면
에러메시지에 따라 클라이언트 상에서 다른 동작을 구현해야 할 경우는 처리할수 있을까요?

[msdio]

따로따로 후처리 하지않고도, 깔끔하게 처리될수 있는 방식이라 좋은것 같습니다!

그런데 이 방식을 사용한다면 에러메시지에 따라 클라이언트 상에서 다른 동작을 구현해야 할 경우는 처리할수 있을까요?

에러 메세지에 따라 동작을 구분해야 하는 경우는 에러 코드에 따라 분기처리를 하면 될 것 같아요.
ex)

} catch (error) {
  const customError = error as ApiErrorResponse;

  if (customError.code === error code) {
    /** some logic */
  }
}

하지만 에러 타입을 ApiErrorResponse로 정해놨기 때문에, 서버에서 내려주는 error와 description 이외의 다른 정보는 사용하기 어렵긴 할 것 같네요..🙄

[sumi-0011]

서버에서 내려주는 error로 처리할수 있다면 문제 없을것 같다고 생각합니다! 좋아요 👍🏻

[coolsmart2]

axios interceptors 내부 미들웨어? 함수의 경우 화살표 함수로가 아닌 함수 선언으로 해야되는건가요?

[msdio]

axios interceptors 내부 미들웨어? 함수의 경우 화살표 함수로가 아닌 함수 선언으로 해야되는건가요?

기존 코드가 수미님과 윤우님이 회의하면서 작성된 걸로 알고 있는데, 저렇게 작성된 이유가 있을 것 같아 동일하게 함수 선언으로 작성했습니다. 화살표 함수가 사용되지 않은 이유가 있을까요?

[coolsmart2]

interceptor는 수미님이 작성하신 것으로 알고 있습니다. 특별한 이유가 없다면 화살표 함수를 쓰면 좋을 것 같네요

[sumi-0011]

넵 특별한 이유는 없습니다!
저는 단순히 interceptor 가이드를 보고 한거라 화살표함수로 바꾸는게 좋을 것 같네요.

[msdio]

좋아요! 지금 있는 pr 머지한 후에 별도 pr로 처리할게요