2022.09.11 개발자 이야기 (8월은 재정비의 달)

7월 말 라이브 배포를 끝마치고, 8월은 공식적으로 재정비에 들어가는 달이었습니다. 

일도 쉬엄쉬엄하고 몸도 마음도 회복하는 시기었죠.

 

운동

저는 7월 24일부터 아침 헬스를 시작하였고, 거의 일주일에 5~6번은 꾸준히 나가고 있습니다.

몸과 마음이 지치고 생각이 복잡할때 운동만한 것이 없더군요.

운동할 때만큼은 잡생각을 하지 않고 지금 이순간의 운동에만 집중할 수 있어서 참 좋은 것 같습니다.

끝나고 나면 정말 개운하기도 하고 성취감도 있고요.

이제 겨우 1달 하고도 조금 더 했는데 걸을 때나 계단 올라갈때 훨씬 힘이 나네요. 몸도 건강하고 좋아지니 더 당당해진 기분입니다.

 

운동은 3분할로 쪼개서 밀기/당기기/하체를 돌아가면서 하고 있고, 운동 기록이나 메모는 번핏 어플로 기록하고 있습니다.

저는 엄살이 심해서 운동 사이의 휴식 시간 타이머를 사용하지 않으면 안되는 스타일이라서 어플이 참 도움이 됩니다.

 

모임

그리고 소모임 어플 통해서 개발자 모임도 새로 등록했습니다.

아무래도 동일 업종 내 네트워킹을 무시할 수가 없기 때문이죠. 서울에서 친구도 만들고 싶기도 하고요.

사실 오프라인 모임에서 프론트엔드 분들과 모여서 같이 이야기 나누고 싶은데 왜이렇게 프론트엔드 분들은 오프라인 활동을 안나오시는지 모르겠네요😅 백엔드 사람들이 외부 활동에 훨씬 더 적극적인 것 같습니다. ㅠㅠ

 

그 외에도 한 번도 해본 적 없었던 독서 모임이나 영화 모임 등에도 나가보았습니다.
최근 들어서 다른 사람들의 생각을 좀 들어보고 싶고 이야기도 나눠보고 싶은 생각이 많이 들더라고요. 너무 일만 하다보니 내향성이 

문토라는 모임 어플을 사용했는데 이용자 수도 꽤 많고 모임도 다양해서 좋았고, 당근마켓 처럼 매너 온도가 있어서 영 이상한 사람을 경계하고 피할 수 있어서 좋았습니다. (광고아니에요 ㅋㅋ)

 

코딩의 질을 한 단계 업그레이드

마냥 쉬기만 할 수 없으니 쉬어가는 기간동안 코딩의 질을 한 단계 업그레이드 하는 시간을 가졌습니다.

완전 새로운 기능을 만드는게 아니라 기존에 만들어둔 것을 혁신적으로 개선해보려고 노력해보았습니다.

 

1. URL 기반의 서브페이지 관리 체계 도입 

https://11001.tistory.com/195

리액트 URL Hash기반의 서브페이지 관리 체계 도입

 

2. 모듈 조립식 라우터 도입

별도로 포스팅하기엔 내용이 좀 적어서 고민중이긴한데 여기에 간단히 소개해보겠습니다.

라우터별로 Main, SideBar, Header, Footer 등 레이아웃 별로 원하는 컴포넌트를 children 으로 넣어서 조립하는 방식입니다.

 

이렇게 만들게 된 이유는 간단합니다.

기존에는 라우터별로 한 컴포넌트 안에 필요한 컴포넌트들이 우겨넣어진 상태로 사용했었습니다.

문제는 거의 똑같은 코드를 사용하는 파일이 2개가 있는데 나중에 내용이 달라질 것을 생각하니 하나로 합치지도 못하고, 그대로 두기에는 매번 변경사항을 두 파일에 적용하기엔 귀찮고, 심지어 한쪽을 업데이트 안해줘서 이원화 되어버리기도 하는 문제가 있었기 때문입니다.

 

처음에는 정말 공통된 부분만 뽑아내고 서로 다른 부분은 각각의 하위 컴포넌트에 집어넣는 방법을 생각했었는데 또 다른 새로운 페이지를 추가해야 되었고, 다른 프로젝트의 컴포넌트를 가져와서 재활용 하는 상황을 고려하게 되면서, 차라리 최소 단위로 다 쪼개서 조립식으로 만들어보기로 결심했습니다.

 

결국엔 아래와 같이 공통프레임 내부에 필요한 컴포넌트를 레이아웃별로, (레이아웃에 관계없는 채팅 같은 것들은 별도로) 집어넣어서 조립시켰습니다. 

각 라우터 별로
<공통프레임>
    <채팅/>
    <사이드영역 title={'사이드바제목'}>
        <사이드영역 렌더링할것 />
    </사이드영역>
    <메인영역>
        <메인영역 렌더링할것 />
    </Galaxy>
</공통프레임>

 

3. 모듈별 ErrorBoundary & Suspense 도입

기존에는 데이터가 하나의 통합 API 로 받아온 뒤 여러 컴포넌트에 전달하는 방식이었고, 최상위 컴포넌트에 ErrorBoundary 를 설정해두어서 Error 발생하면 전체 화면의 에러 페이지를 보여주었습니다.

그런데 최근에는 통합 API를 각 모듈별 API로 쪼개는 작업을 진행하게 되면서 이제는 모듈별 ErrorBoundary를 도입할 때가 되었구나 싶었습니다.

 

이것 또한 시간되면 별도로 포스팅하게 될 것 같지만, 간단하게 과정을 작성해보겠습니다.

 

• API 공용 axios instance 제작 하고 제네릭 타입을 받아서 data 를 반환하는 공용 함수 생성
  
  • res.data.data가 아니라 res.data 를 뱉는 버전도 있고, AccessToken 받아서 헤더에 넘기는 버전도 만들었음.

export const request = <T>(url: string, data?: AxiosRequestConfig) =>
  axiosInstance.request<{ data: T }>({ url, ...data }).then(res => res.data?.data)

 

• API 파일 하나에 모든 API 를 정의하여 끌어다 쓸 수 있도록 개선 API 이름은 한글명 지어서 매우 직관적이게 만듬
• 모듈 이름의 폴더 만들어서 필요한 파일을 아래에 모아서 정리
  • 모듈.tsx
  • 모듈Skeleton.tsx
  • styles.ts
• 각 모듈 컴포넌트에서 React Query 를 통해 해당 모듈 API 호출하도록 변경. 캐싱 설정
• 로딩 상태에서는 모듈Skeleton.tsx 파일을 렌더링
• 에러 상태에서는 모듈 단위 ErrorBoundary 에서 Catch
  • 400 Error
    • 여러 모듈에서 Error 발생한 경우 한번에 새로고침 할 수 있도록 상위 컴포넌트로 에러를 throw 해주었습니다. 
    • 사용자 스스로 에러 상태에서 벗어날 수 있다고 가정하고, (상위 컴포넌트에) 새로고침 버튼을 주고, 페이지 새로고침 할 수 있게 하였습니다.
  • 500 Error
    • 사용자 스스로 에러 상태에서 벗어날 수 없다고 가정하고, 오류신고 버튼을 주었습니다. 현재는 구글 폼으로 연결되어 수동으로 에러 리포트를 작성해야하지만, 추후에는 자동 에러 리포트 전송되도록 개선 예정입니다.

대략 이런 과정들을 추가했고 이제 모듈들이 진정한 의미의 모듈이 되었습니다 ! 와 ! 다른 프로젝트에 가져가서 이식하기 정말 쉽겠네요!

 

그 외에도 자바스크립트->타입스크립트 마이그레이션 등을 꾸준히 진행하고 있기도 하구요

마음 같아선 빨리 타입스크립트 전환 끝내고 react18 도 도입해보고 싶습니다. 라이브러리 버전 문제로 머리아플것 같긴하지만요...

 

 

8월에 엄청 놀고 먹고 쉬었다고 생각했는데 되돌아보니 뭔가 많이 했네요.