9월 5주차

0 views

📌 처음으로 기획자분과 같이 일하게된 소감

기획자분이 월요일에 들어오셨다. 개발중인 앱을 사용하고 후기를 남겨주셨는데, 읽고나서 느낀점은

기본적으로 글을 잘쓰신다.
서비스를 글로 잘 풀어낸다. 평론가 같다는 느낌이 들었다.

그동안 내가 개발을 하면서 어렴풋하게 갖고 있던 생각들을 글로 표현했다면 아마 이렇게 작성하지 않았을까 싶다. 그만큼 많이 공감됐다. 그리고 지금까지의 개발은 항해사 없이 노만 젓는 느낌이었다면, 이제는 든든한 항해사가 들어온 느낌이었다.

📌 Date 함수 사용하기

githru에서 날짜로 commit 내역들을 필터링을 했을 때 , 특정 commit들이 보여지지 않는 문제가 있었다. 원인은 두가지였다.

첫번째 원인은 toISOString의 사용이었다. 다음과 같이 new Date의 인자로 한국 시간을 보내도, toISOString을 호출하는 경우 utc가 출력된다.

console.log(
  new Date('Fri Sep 09 2022 18:33:02 GMT+0900 (Korean Standard Time)'),
) // Fri Sep 09 2022 18:33:02 GMT+0900 (한국 표준시)

console.log(
  new Date(
    'Fri Sep 09 2022 18:33:02 GMT+0900 (Korean Standard Time)',
  ).toISOString(),
) // 2022-09-09T09:33:02.000Z

두번째로 filtering 하는 로직의 문제였는데, 다음과 같이 new Date의 인자로 YYYY-MM-DD를 전달하게 되는 경우, 오전 9시의 GMT가 출력된다.

console.log(new Date('2022-09-13')) // Tue Sep 13 2022 09:00:00 GMT+0900 (한국 표준시)

위와 같은 YYYY-MM-DD를 전달하면서 날짜를 비교해야하는 로직의 경우, 다음과 같이 적절한 시간을 같이 전달해주면 해결된다.

const fromDate = '2022-04-28'
const toDate = '2022-09-06'

if (
  new Date(targetDate) >= new Date(`${fromDate} 00:00:00`) &&
  new Date(targetDate) <= new Date(`${toDate} 23:59:59`)
) {
  // ...
}

그런데 서버로부터 utc 시간만 받아와서 사용하다가 GMT 시간을 다루게 된 것은 처음인데, 차이점좀 조사해서 코드에 녹여야겠다. 🤮

📌 useEffect 걷어내기

문득 githru 코드를 리펙토링 하다가 다음과 같은 구조의 코드를 보게됐다.

const ComponentFunction = () => {
   const [a, setA] = useState('a');
   const [b, setB] = useState('b');
   const [c, setC] = useState('c');

   const handleClickButton = () => setA('aa');

   useEffect(() => {
      setB('bb');
      setC('cc');
   }, [a])

   return (
      ...
   )
}

click로직과 useEffect로직이 떨어져 있어서 상태 추적이 어려운 코드다. 더불어서 setA가 호출되면서 리렌더링이 한번 발생하고, setB와 setC가 호출되면서 리렌더링이 한번 발생해서, 총 두번의 리렌더링이 발생한다. 만약 이를 다음과 같이 수정하면, 상태 추적도 쉬워지고 리렌더링도 한번만 발생하게 된다.

const ComponentFunction = () => {
  const [a, setA] = useState('a')
  const [b, setB] = useState('b')
  const [c, setC] = useState('c')

  const handleClickButton = () => {
   setA('aa');
   setB('bb');
   setC('cc');
  }

  return (
   ...
  )
}

📌 husky, lint-staged, nx 도입

금주에 마크업 관련 작업을 다 끝냈다. 이제 다음 할 업무를 고민하던 도중, 일전에 develop 브랜치에 에러가 존재하는 코드가 섞여 들어간 히스토리가 있어서 팀장님께 husky, lint-staged 도입을 말씀드렸다.

도입 과정이 조금 어려웠던 부분은 정상적이지 않은 repository 구조였다. repository가 아래와 같이 monorepo를 구현하려다가 만 구조인데,

.git
web
   ㄴ package.json
   ㄴ ...
webview
   ㄴ package.json
   ㄴ ...

다행히 이러한 multipackage 폴더 구조에서 husky를 셋업하는 가이드를 찾을 수 있었다. 그리고 nextjs 가이드 문서를 보고 lint staged를 같이 셋업한 결과 stackoverflow에서 말하는 문제에 부딪히게 되었다. 동작은 하는데, 빌드가 오래걸리고 재귀적으로 hook이 호출되는 느낌 🤯

현재 문제를 해결해도 monorepo를 셋업하면 결국에는 husky와 lint-staged를 다시 셋업해야할 것 같아서, 우선은 monorepo 셋업 후 다시 진행하려고 한다.

📌 금주 읽은 문서

1. Jamstack

Gatsby를 사용하다가 Jamstack이라는 아키텍쳐를 보게되었다. 프로그래머스 데브코스를 수강할 때도 Jamstack이라는 단어를 들었던 기억이 있어서 리서치를 하고 있는데, 너무 두리뭉실하다. 명쾌하게 정리가 안되는 느낌. 조사하다보니 Jamstack의 비교대상으로 CMS가 나와서 추가적으로 관련 문서를 읽어보았다.

Jamstack 공식문서

What is Jamstack?

Traditional CMS vs Headless CMS (1)

Traditional CMS vs Headless CMS (2)

Traditional CMS vs Headless CMS (3)

2. SOLID

요새 오며가며 JAVA 객체지향 디자인 패턴 UML과 GoF 디자인 패턴 핵심 10가지로 배우는 책을 재미있게 읽고 있는데, SOLID를 프론트엔드에서도 적용이 가능한가 싶어서 리서치하다가 읽게되었다.

Can you apply SOLID principles to your React applications ?