[DeepFlow] 프로젝트 9주차 ~ 12주차 정리 및 느낀점 😀

안녕하세요! 오늘도 마찬가지로 이전까지 작성해오던 DeepFlow라는 개인 프로젝트의 9주차 ~ 12주차 동안의 활동 내용 및 느낀점을 작성해보도록 하겠습니다. 5주차 ~ 8주차 활동 글을 적은지도 별로 안된거같은데 벌써 한달이라는 시간이 지났다는게 빠르게 느껴집니다 🎃

해당 프로젝트는 2021학년도 3학년 1학기, 프로젝트 실습 과목 시간에 진행하는 프로젝트 입니다.

프로젝트 5주차 ~ 8주차 활동에 관한 글은 아래의 링크를 통해 볼 수 있습니다 😁
https://velog.io/@yiyb0603/DeepFlow-%ED%94%84%EB%A1%9C%EC%A0%9D%ED%8A%B8-5%EC%A3%BC%EC%B0%A8-8%EC%A3%BC%EC%B0%A8

1. 댓글 / 답글 입력 이미지 업로드 🖼

기존에 마크다운 문법을 이용하여 텍스트만 적을 수 있었던 댓글 / 답글 입력창에 이미지 업로드를 추가했습니다. 직접 이미지를 선택하여 업로드 하거나 입력창에 드래그 앤 드롭을 이용해서 이미지를 업로드 하는법을 추가하였습니다.

업로드 된 이미지는 Preview 탭에서 볼 수 있습니다.

2. 상수 선언문 수정 🎠

기존에 제가 선언하던 방식의 상수는 아래와 같습니다.

const GITHUB_ADDRESS: string = 'https://github.com';
const APP_NAME: string = 'DEEPFLOW';

물론 const로 선언하였기에 값이 변하거나 하는 문제는 없었지만 위의 방법보다 더 좋은 상수 선언 방식을 찾게되었고, 방식은 아래와 같습니다.

const GITHUB_ADDRESS = 'https://github.com' as const;
const APP_NAME = 'DEEPFLOW' as const;

위에서 보았던 상수는 그저 string 자료형을 가지고 있는 상수이지만, 아래의 코드를 보시면 변수의 끝에 as const 키워드를 붙임으로써 단순 string 자료형이 아닌 'https://github.com', 'DEEPFLOW' 라는 값만 들어올 수 있도록 지정해줄 수 있습니다.

3. Recoil Selector 추가 🧨

기존에 Recoil을 이용하여 전역상태관리를 할때 atom만을 이용하여 문제없이 상태관리 등을 진행했습니다. 하지만 큰 문제점이 있었습니다. 그것은 특정 액션이 실행될때마다 무분별하게 API가 호출 된다는 것이었습니다.

저는 이후로 API 값을 캐싱하는 방법에 대해서 알아보다가 Recoil의 기능중 하나인 selector가 이미 호출했던 API 값을 캐싱해주는 기능을 가지고 있다는 것을 알게되었고, 곧바로 도입하여 API 호출을 최적화 했습니다.

이에 대한 자세한 설명은 아래의 글을 참고해주세요!
https://velog.io/@yiyb0603/Selector%EB%A5%BC-%EC%9D%B4%EC%9A%A9%ED%95%98%EC%97%AC-%EB%8D%B0%EC%9D%B4%ED%84%B0-%EA%B0%92-%EC%BA%90%EC%8B%B1%ED%95%98%EA%B8%B0

추가적으로 API 호출을 불러주어야 할때는 각종 콜백 hooks들을 만들어서 특정 동작이 실행될때마다 콜백 함수를 호출하는 방식으로 데이터를 업데이트 해주었습니다.

4. Suspense 로딩 컴포넌트 추가 🎇

저는 Recoil 및 지연로딩 기법을 사용하기 때문에 <Suspense> 컴포넌트를 이용해서 렌더링이 되기전까지의 로딩 처리를 해주어야 하는데요, 지연로딩을 사용하면 화면 전체가 잠깐 깜빡 거렸다가 돌아오기 때문에 이를 괜찮게 커버해줄만한 로딩 방법을 찾고 있었습니다.

그러다가 구글 클래스룸의 로딩 화면이 떠올라서 보게되었고, 이 로딩바 방식이 마음에 들었던 저는 구글 클래스룸의 로딩바를 fallback loader로 추가했습니다.

구글 클래스룸 로딩바 화면

5. 테스트 코드 추가🧵

이전부터 저는 TDD 테스팅 기법, 컴포넌트 테스트, 테스트 코드 작성 등등.. 수많은 테스팅에 관한 글을 보면서 테스팅을 해보고 싶다는 생각이 자주 들었습니다.

결국 어느날 테스트 코드 작성을 해보고 싶어서 기초적인 테스트 코드 작성법에 대해서 공부를 해보았고, 이를 실제로 적용해보고 싶어서 DeepFlow 프로젝트에 테스트 코드를 작성하여 적용해봤습니다.

처음에는 Enzyme 라이브러리가 편해보여서 시도했지만, Enzyme는 리액트 컴포넌트를 테스팅 하는데만 최적화 되어있는 테스팅 도구인거 같아서 패스했습니다.

그러다가 testing-library/react라는 라이브러리를 보게되었고, 리액트 컴포넌트 뿐만 아니라 TypeScript 테스팅을 다루는 예제들과 가이드가 많아서 해당 라이브러리를 도입하게 되었습니다.

이를 통해서 컴포넌트 및 각종 유틸리티 함수들에 대해서 테스팅을 쉽게 할 수 있었습니다.

6. 코드 작성 방식 수정 🧧

얼마전, 저는 Velog 글을 보다가 아래의 글을 보게 되었습니다.

https://velog.io/@edie_ko/Mistakes-%EC%A3%BC%EB%8B%88%EC%96%B4-%EB%A6%AC%EC%95%A1%ED%8A%B8-%EA%B0%9C%EB%B0%9C%EC%9E%90%EC%9D%B8-%EB%82%B4%EA%B0%80-%EC%8B%A4%EC%88%98%ED%95%98%EA%B3%A0-%EC%9E%88%EC%97%88%EB%8D%98-%EA%B2%83

해당 글에서는 작성자님이 리액트 프로그래밍을 하면서 실수하거나 놓쳤던 점들에 대해서 작성하셨습니다. 이 글에 적혀있는 규칙들중에서 제가 지키지 않고 있었던 규칙들도 몇개 있었습니다.

string, boolean props에 브라켓을 붙이지 않기, early return 하기 규칙이 제가 이전까지 지키고 있지 않던 규칙들이었습니다.

그래서 바로 다음날, 위의 글을 보면서 올바른 코드 작성 방식으로 수정하게 되었습니다. 대표적으로 string, boolean props에 브라켓을 붙이지 않기 규칙은 평소에도 이렇게 적는게 맞는 방식일까? 하는 생각을 자주하고 있었는데, 이 글을 보고나서 궁금증이 해소 되었던것 같네요. :)

다음에 또 다른 프로젝트를 진행할때는 Promise.all() 함수 사용을 적극 고려해봐야겠습니다.

이 외에도 진행했던 커밋 내용에 대해서 아래 링크로 보실 수 있습니다 :)
https://github.com/yiyb0603/DeepFlow_Web/commits/main

7. 글을 마치며 🎃

어느새 프로젝트 총 16주차 중 12주차가 지나갔네요. 시간이 참 빠른것 같습니다 ㅋㅋㅋ 다음에는 12주차 ~ 16주차 후기 및 프로젝트 회고를 작성하는 시간을 가지도록 하겠습니다.
글 읽어주셔서 감사합니다!