250322_WIL | 블로그 만들기 + headless 고찰

250322_WIL

이번주 한 일

• 블로그 만들기 진행중!
• 회사 컴포넌트 Headless로 교체하기!

블로그 만들기 진행중

next로 블로그 만들기 진행중이다. 현재의 깃블로그의 경우 지킬 + 구글링으로 얼렁뚱땅 만들었었고, 게시물들도 사실 양질의 컨텐츠라기 보단 구글링한 내용을 짜깁기한 부분에 가까워서 새로운 블로그를 만들어야겠다는 생각이 들었고 next appRouter의 경험이 필요할 것 같다는 생각이 들어 새로운 프로젝트로 진행 중이다. 목표는 다음주까지 완성하기..!

블로그 만들면서 생긴 이슈들

1. 제일 큰 문제는 next 서버 라우팅을 1도 모른다는 것..
2. mdx 불러오는 라이브러리를 사용했는데 사용하려고 할때마다 500에러가 발생

next 몰라 개발자의 블로그 만들기

일단 어떤 라이브러리를 선택할지 고민했고, 결론은 nextJs, tailwind를 주로 작업하기로 했다. 둘다 거진 초면이지만 이렇게라도 안하면 안써볼 것 같았다.
둘다 최근 트렌드한 패키지이기도 하고, tailwind는 코드는 지저분해보일 수 있으나 막상 써보면 편하다는 후기와 코드가 지저분해보인다거나, emotion의 역할도 필요하다면 twin.macro를 사용한다는 게시물을 많이 발견했다.
일단 tailwind에 익숙해지는게 우선인 것 같아 써보고 필요하다면 twin.macro에 도전해볼 에정이다.

디시 본론으로 돌아와서 생각중인 개발 진행 순서는 아래와 같다.

1. next 공식문서 와 D5BL5G님 nextJs 블로그 만들기 게시물 을 주로 참고해서 진행했다.
2. MDX 불러오는 게 제일 큰 문제일 것 같아 pageRouter 이긴 하나 next 한글 문서(커뮤니티)의 markdown 글 문서와 D5BL5G님 nextJs 블로그 만들기 게시물 내용 + ChatGPT를 함께 사용해서 MDX 동작을 확인했다.
3. 피그마에 디자인 추가 (예정!)
4. 디렉토리 구조 정리 (예정!)
5. 스크린 제작 (예정!)

2번까지는 완료해서 주말 중에 4번까지 완료하는 걸 목표로 하고 있다! 방통대 편입을 한 상태라 학교 공부도 같이하려고 하다보니 조금 부담된다.

mdx 라이브러리

next-mdx-remote 라이브러리를 사용하여 MDXRemote를 통해 mdx contents를 보여주려고 했으나 해당 코드를 사용하기만 하면 server 500에러가 발생했다.
알고보니 next-mdx-remote 공식 문서 내에 이슈 발생 시 next.config.js에 아래의 코드를 추가해야한다! 공식문서를 생활화하자

const nextConfig = {
+  transpilePackages: ['next-mdx-remote'],
}

위 코드를 추가하고 나니 바로 정상동작! 야호!

회사 컴포넌트 Headless로 교체하기!

회사에서는 현재 모노레포(TurboRepo)를 적용하여 서비스들를 관리 중인데, 이번에 새로운 프로젝트가 추가되면서 이슈가 발생했다.
기존의 서비스들은 WEB Admin 기반으로 하여 동일한 스크린 + 컴포넌트를 적용 중이나, 이번에 추가된 서비스의 경우 APP 디자인 시스템을 바탕으로 하다보니 컴포넌트가 모두 기존의 컴포넌트들을 사용할 수 없는 이슈가 발생했다.

• UI랑 기능을 분리하는 작업을 진행했는데, 구글링해서 나오는 방법들은 대부분 Headless 라이브러리를 사용하는 경우가 대다수라, 사내 프로젝트에 적용하려면 조금 다른 방법으로 진행해야했다. 방법은 크게 아래의 3가지였다

1. Compound-component
2. Children
3. Custom hook

위의 세가지 방법을 융합해서 사용했다. 컴포넌트에서 사용한 방식은 아래와 같다.

1. Compound-component
   • 컴포넌트가 가지고 있는 상태를 사용해야하는 경우로 아토믹 패턴 기준으로 Atom에 해당하는 컴포넌트의 조합으로 이루어진 컴포넌트인 경우 이 방법을 주로 사용했다.
   • 예를 들어 PasswordInput 이나 Tab 같은 경우 이 방법을 사용할 수 밖에 없었다. Children 구조로 가져가기엔 코드를 반복적으로 사용해야하는 경우가 많아 어쩔 수 없었다.
2. Children
   • 아토믹 패턴 기준으로 봤을 떄 Atom에 해당하는 컴포넌트로 단순 Input이나 Button 같은 경우, LoadingSpinner가 필요할 때 이 방법을 사용했다.
   • LoadingSpinner는 기능보다는 UI적인 요소가 강하나. 프로젝트마다 다른 style이 필요한 경우 어쩔 수 없었다.
3. Custom hook
   • 위 2가지 외에 특이한 경우가 부분적으로 있었는데, 기존 공용 컴포넌트가 props로 하위 컴포넌트에 상태를 넘겨주는 경우에 이 방법을 사용했다 (생각해보니 compound-component 방식도 가능했을 것 같다.)

새로운 정보!

register의 정체… value를 같이 쓰면 안된다고..?

• 사실 이론적인 요소를 평소에 생각을 잘 하지 않고 코드를 짜다보니 생긴 이슈였는데, 이번에 우리팀에 들어온 인턴분이 해당 이슈를 발견해주었다.
• 문제 사항만 말하자면 React-hook-form의 경우 비제어 컴포넌트로 불필요한 리렌더링을 방지하고자 하고 RHF의 일부인 register도 비제어의 일부이나 팀 내에서는 value 관리를 위해 아래와 같이 코드를 작성하고 있었다.

const Input = () => {
  const { watch, register } = useForm();

  return <input value={watch("value")} {...register} />;
};

이 경우 watch로 value를 관리하고 있다보니 값을 입력할 때 리렌더링이 일어나는 이슈가 있었고, 동작 시에도 일부 경우 value에 원하는 포매팅이 적용안되는 이슈가 있었다.
이것 또한 제어(value) + 비제어(register)를 섞어서 쓰다보니 생긴 이슈가 아닐까 하는 게 팀 내 결론이었고, 추후 value에 값을 직접 산입하는 경우는 지양하기로 결론 지었다.
(혹시나 포매팅이 필요한 경우 register 내에서 처리하는 방법으로 하는게 맞을 것 같다는 결론이 나왔지만 관련해서 조금 더 찾아보는 게 맞는 것 같다)

---

거의 1년만에 작성하는 게시물이라 기분이 미묘하다. 꾸준히 작성하려고 했건만 귀찮음을 이유로 기록하는 것을 잊어버렸던 것 같다. nextJs로 블로그 만들고 나면 이전 후 주 1회 wil을 목표로 하고 있으나 이제는 결심은… 작심삼일인라는 것을 알게 되었기때문에 일단 블로그 먼저 빨리 만드는 걸로..!
빠른 이전 기원 :)