[협업 프로젝트] 4주차 회고

협업 프로젝트 4주차 회고

한 것들

• 지난 주에 게시판을 완성하고 게시판 상세로 넘어왔다. 지난 주에 msw 연결할 때는 그냥 fetch 써서 기본적으로 제대로 데이터를 받아오는지, 그렇지 못한지를 파악하기만 했었다. 이번 주에는 axios 인터셉터를 사용해서 axios 객체를 만들어서 사용하는 방식으로 진행하기로 했다. 협업이기도 하고, 매번 로그인 토큰을 헤더에 설정하기는 참으로 번거롭기 때문에!

// src/api/apiClient.ts

import axios, { AxiosError } from 'axios';
import { Cookies } from 'react-cookie';

const API_BASE_URL = 'http://localhost:5173';

export const axiosPublic = axios.create({
  baseURL: API_BASE_URL,
  headers: {
    'Content-Type': 'application/json',
  },
});

const cookies = new Cookies();

export const axiosAccessFn = () => {
  const axiosAccess = axios.create({
    baseURL: API_BASE_URL,
    headers: {
      'Content-Type': 'application/json',
    },
  });

  axiosAccess.interceptors.request.use(
    async config => {
      try {
        const accessToken = await cookies.get('accessToken');
        if (accessToken) {
          config.headers.Authorization = `Bearer ${accessToken}`;
        }
        return config;
      } catch (error) {
        return Promise.reject(error);
      }
    },
    error => {
      return Promise.reject(error);
    },
  );

  axiosAccess.interceptors.response.use(
    response => {

      return response;

    },
    error => {
      const axiosError = error as AxiosError;
      return Promise.reject(axiosError);
    },
  );
  return axiosAccess;
};

• 일반적으로는 토큰이 항상 필요하므로 axiosAccess를 사용하고 회원가입과 로그인 시에만 axiosPublic을 사용.
• api 들도 따로 분리해서 파일로 만들었다. 협업에서는 참 디렉토리/파일 구조가 중요하다는 것을 느낀다. 모든 것을 내가 하던 대로, 내 방식 대로만 할 수는 없는 것이기 때문에 다른 팀원 분들께서 제안 해주신 것도 최대한 반영해서 적응하고 있다.

 

또 로그인 부분은 내 담당이 아니지만, 다른 팀원 분의 진행이 늦어져서 유저 데이터를 어떻게 관리해야 하는지에 대해서 고민을 좀 했다. 토큰에 대한 이해가 부족했던 탓에... 토큰 안에 사실 유저의 데이터가 담겨있고 유저 식별을 할 수 있는 건데 난 굳이 user데이터를 따로 받아와야 한다고 생각했다. 💦

기존 api 명세서 url에 userId를 넣은 항목도 있었어서(그냥 수정하면 되는데) 뭔가 굳이 그걸 받아야겠다고 생각을 했던 것 같다..

유저 데이터가 오지 않으면, 단순히 유저 데이터를 페이지에서 보여주지 않더라도 문제가 생기지 않나?
게시글을 클릭했을 때 이게 내가 쓴 글인지 아닌지에 따라서 수정 삭제 버튼이 보여질 수도 있고 아닐 수도 있다. 그리고 프로필에 접속해서 내 프로필을 불러올 때, api 주소에 유저 id를 보내야 하는데, 이 유저 id는 미리 우리가 전역 상태로든 어떻게든 관리를 하고 있지 않다면 보낼 수 있는 방법이 없다....

고 생각했는데

-> 게시글 클릭시 내 글인지 여부를 담은 필드를 따로 받기로
-> url에 보내기로 했던 userId는 다 빼기로

하였다!

 

이렇게 되면 남은 하나의 문제는 주소를 입력하지 않은 사용자가 게시판에 접근하는 경우!

에러를 활용하기로 했다. 백엔드에서 에러를 띄우면 -> onError에 프론트에서 프로필 수정 페이지로 리다이렉트하기로 했다!! 해결!!

그리고 참여 요청이나, 북마크 부분도 하고 있는데, 기존에는 내려오는 데이터가 postId 였다. 생각해보니 이 postId를 가지고는 할 수 있는 게 없다. 이 id를 가지고 또 한 번 api 요청을 보내는 게 맞나? 아니면 한 번에 postId 뿐 아니라 post에 대한 모든 정보를 요청하는 게 맞나? 사실상 정답은 없지만 내가 생각할 때는 한 번에 다 내려오는 게 낫다고 생각해서 수정을 요청 드렸다.

 

 

나도 협업이 처음이다보니 어디까지 백엔드에 요구해도 되는지, 어느정도가 무리한 부탁인지 파악하는 게 너무 어려웠다. 그런데 생각해보면 백엔드 분들도 그러시겠지. 이제 다음주면 진짜 백엔드와 연결해야 하고 슬슬 배포도 준비해야 한다..

 

 

 

느낀 것들

 

 

내 파트 뿐 아니고 프로젝트 전체에 대해 파악하는 것이 중요함을 다시 느낀다. 로그인, 회원가입 부분이 내 부분이 아니라고 그냥 무작정 내 부분만 하고 있었는데, 팀원 분의 진행 속도가 늦어지게 되면서 사실 내 파트에서도 유저의 로그인 상태, 유저 정보에 대한 부분이 쓰인다는 것을 뒤늦게 깨닫고 유저 정보를 어떻게 해야될지, api를 수정해야될지 를 생각해보게 되었다.

그리고 팀 프로젝트이고, 내가 팀장인 만큼 맞춰야 할 데드라인을 지킬 수 있게 팀원 분들을 독려하는 것.. 어렵지만 꼭 해야할 일이니까 해야지!! 마지막 주만 남기고 있는 만큼 이번 주 회의도 좀 당겨서 하려고 한다.