Design Pattern

[LeeMir]

@bucketressi

현재 프로젝트의 구조는

one-line-client
┃
┣ src/
┃ ┣ apis/       # fetch 함수
┃ ┣ assets/     # 이미지, 폰트
┃ ┣ components/ # 컴포넌트
┃ ┣ constants/  # 상수
┃ ┣ hooks/      # 커스텀 훅
┃ ┣ pages/      # 페이지
┃ ┣ routes/     # 라우트
┃ ┣ stores/     # 전역 상태 (Recoil)
┃ ┣ styles/     # 전역 CSS (Reset 등)
┃ ┣ types/      # 타입
┃ ┗ utils/      # 재사용 함수

로 이루어져 있고, Atomic을 간단하게 변형한 디자인 패턴을 사용중입니다.

디자인 패턴을 간략하게 소개하면
Page(logic), Template(view)을 pages/ 하나로 위임하고,
Organism, Molecule, Atom을 모두 components/로 위임한다음, Organism이나 Molecule 급으로 복잡한 컴포넌트는 하위 디렉토리를 만들어서 표현할 수 있도록 하는 방식입니다.

지금 상태에서는 잘 드러나지 않지만, Table이라는 컴포넌트가 있다고 가정하고 예시를 들면

components/
┣ Table/
┃ ┣ TableHeader/
┃ ┃ ┣ index.tsx
┃ ┃ ┗ style.ts
┃ ┣ TableRow/
┃ ┃ ┣ index.tsx
┃ ┃ ┗ style.ts
┃ ┣ index.tsx
┃ ┗ style.ts

Table/index.tsx에서 <TableHeader />와 <TableRow />를 호출하고, 페이지에서 <Table />을 호출하는 방식입니다.

커스텀 훅이 있는데 Page가 모든 로직을 가져야 하는 이유와 JSX에서 Template이 굳이 존재하는 이유에 대해서 고민하고,
모든 컴포넌트를 Organism Molecule Atom 세 단계로 나누는 것은 비효율적이라고 생각해서 고안한 패턴인데 어떻게 생각하시나요!

[bucketressi]

일단 아직 지식이 부족해서 그런지, Organism Molecule Atom 으로 설명한 용어가 무엇을 의미하는지 알기 힘들어 설명을 덧붙여줬으면 합니다.
더해서 예시로 들어둔 페이지 구조만 보았을 때는 크게 문제 없어보이는데, 몇가지 질문이 있습니다.

• context 관련 컴포넌트는 어떤 폴더에 추가되나요? 따로 두는 것이 관리하기 쉬울 것 같아서요.
• hook이 따로 빠져있는데 컴포넌트 하나와만 밀접하게 연계된 훅의 경우에도 저 공통 폴더에 포함시켜야 할까요?
• 폴더 내부에 관계된 컴포넌트를 묶어서 저장하는 것은 좋은데, 예시와 같이 Table이라는 컴포넌트 자체를 폴더로 묶어버리기 보단 다음과 같이 폴더로 3가지 컴포넌트를 담고 있는 식으로 하는 게 추후 이동이나 공통화시킬 때도 좋을 것 같아요.

components/
┣ Table/
┃ ┣ TableHeader.tsx
┃ ┣ TableRow.tsx
┃ ┣ Table.tsx
┃ ┗ index.tsx

• 위에 예시로 든 폴더 구조에서 스타일 파일이 ts 확장자로 되어있는 걸로 보아 styled Component를 사용하는 것 같아서 스타일은 컴포넌트와 같은 파일에 있는 것이 좋을 것 같아 삭제해보았습니다.

[LeeMir]

@bucketressi

아침부터 정신없으실텐데 답변 달아주셔서 감사합니다 😄

---

일단 아직 지식이 부족해서 그런지, Organism Molecule Atom 으로 설명한 용어가 무엇을 의미하는지 알기 힘들어 설명을 덧붙여줬으면 합니다.

저도 그렇게 자세히 알고 있는 것은 아닌데 쉽게 말씀드리자면 아토믹 디자인에서는 컴포넌트가 Atom < Molecule < Organism < Template < Page 총 다섯 개의 종류로 등장합니다.

여기서 가장 작은 컴포넌트 단위가 Atom이고, Molecule은 Atom의 조합으로, Organism은 Molecule + Molecule 또는 Molecule + Atom의 조합으로 만들어 최종적으로 Template에서는 Atom + Molecule + Organism으로 레이아웃(뷰)을 결정하고 Page에서는 로직을 정의해 Template으로 내려주는 역할을 하는 것으로 알고 있습니다!

그래서 아토믹 디자인을 따른다고 하면 당시 제가 공부하려고 찾아본 외국 레포들은 디렉토리 구조를 아예 atoms/ molecules/ organisms/로 나누고, 컴포넌트 이름들도 ~~~~Atom 이런식이더라구요! 프로젝트의 규모가 그렇게 크지 않으면 이렇게 크기에 따라 계층을 나누는 것도 불편하고, 맥락은 관련이 없고 오로지 크기에 따라서만 폴더에 나눠서 보관하는 것이 불편한 것 같다고 생각하던 찰나에, 조금 옛날 영상이긴 한데 라인에서 [ 아토믹 디자인을 본인들 입맛에 맞게 바꿔서 적용했다는 이야기 ]를 유튜브에서 봐서 그걸 보고 저도 제가 편한대로 바꿔봤던 거였습니다!

---

context 관련 컴포넌트는 어떤 폴더에 추가되나요? 따로 두는 것이 관리하기 쉬울 것 같아서요.

context api를 말씀하시는 거라면 저는 context api를 사용하는 것을 선호하지 않는 편입니다. 전역 상태 관리 방법에서 recoil과 context api의 차이는 context api는 실제로 최상단의 context 컴포넌트로부터 props drilling이 일어나고 있지만 그것을 겉으로는 숨겨주는 역할일 뿐이고, recoil은 전역 상태와 컴포넌트 사이에 직접적인 관계를 유지하는 것으로 알고 있는데요, props drilling과 recoil 설치의 pay off를 따졌을 때, recoil 쪽을 조금 더 선호하고 있습니다! 그래서 context 관련 컴포넌트는 아예 존재하지 않을 것으로 예상됩니다!

recoil은 store/에 atom()이나 selector()를 정의하고, 상태에 직접 접근하거나 접근하는 로직을 훅으로 따로 빼내서 쓸 수 있도록 하는 방향으로 사용하고 있습니다.

---

hook이 따로 빠져있는데 컴포넌트 하나와만 밀접하게 연계된 훅의 경우에도 저 공통 폴더에 포함시켜야 할까요?

지금까지 생각했던 커스텀 훅의 정의는 유틸 함수의 컴포넌트 버전이라고 생각했습니다. 그래서 여러 컴포넌트에서 사용할만한 로직을 분리한다고 생각했는데, 컴포넌트 하나와만 밀접하게 연계된 훅이라면 그 로직을 해당 컴포넌트 안에서 쓰면 안되나요? 뷰와 로직을 분리하기 위해선지 다른 이유인지 궁금합니다!

---

폴더 내부에 관계된 컴포넌트를 묶어서 저장하는 것은 좋은데, 예시와 같이 Table이라는 컴포넌트 자체를 폴더로 묶어버리기 보단 다음과 같이 폴더로 3가지 컴포넌트를 담고 있는 식으로 하는 게 추후 이동이나 공통화시킬 때도 좋을 것 같아요.

좋은 방법인 것 같습니다! 여기서 index.tsx는 export 모음 역할인가요? 그러면 그와 관련해서 궁금한 점이 있는데, export 모음 역할을 하는 index.tsx를 매 폴더마다 정의를 해주는 것이 좋은가요? 예전 프로젝트할 때 그렇게 쓰시던 것을 봤던 것 같아서요!
저는 같은 위치에 있는 여러 파일을 한번에 import하는 상황이 있을 때에만 그 부분에만 export 모음을 정의했었어요..! (예를 들면 라우터에서 pages/에 있는 페이지들 import하는 상황)

---

위에 예시로 든 폴더 구조에서 스타일 파일이 ts 확장자로 되어있는 걸로 보아 styled Component를 사용하는 것 같아서 스타일은 컴포넌트와 같은 파일에 있는 것이 좋을 것 같아 삭제해보았습니다.

사실 이 부분도 고민이 있는 부분입니다. 간단한 컴포넌트면 스타일을 .tsx 내에서 같이 정의해서 쓰면 좋을 것 같은데, 코드 길이가 길어지면 스타일이 오히려 독이 되는 느낌이라 그 때 style.ts를 분리하자니 어떤 컴포넌트는 style.ts가 있고, 어떤 컴포넌트는 없는 것은 통일성을 해칠수도 있다고 생각이 되더라구요!

그래서 style을 분리했는데, 그러고나니까 무조건 styled component를 export - import해서 써야 하니 <Container /> 같이 흔한 이름으로 지어버리면 나중에 import할 때 수십개의 <Container /> 위치가 뜨는 참사가 벌어져서 이름을 고유하게 짓도록 <~~~~Container />로 타협을 봤었습니다.

혹시 그러면 하위 컴포넌트들끼리 공유할 수 있는 스타일의 경우에는 상위에 정의해서 import 해오나요? 아니면 공유할 수 있더라도 중복해서 따로 만드나요? style.ts를 분리하면 그들끼리만 export - import 하면서 쓰면 되는데, 스타일이 컴포넌트에 있으면 스타일 때문에 컴포넌트끼리 export - import 하는 게 어색해보이기도 합니다!

어렴풋이 어디선가 Table.styled.ts 이렇게도 만드는 걸 본 것 같은데 이 방법은 어떻게 생각하시나요!

[bucketressi]

아토믹 디자인에 관하여...

아토민 디자인을 적용하는 것은 좋아보이는데, 저도 현재처럼 폴더명은 누구나 알기 쉽게 짓는 게 더 좋은 것 같아요 b

Recoil 좋으네요

살짝 비교해둔 글을 찾아봤는데, Recoil도 결국 context를 사용은 하지만 구독기능을 별도 로직으로 관리해서 context보다 렌더링 측면에서 이점이 있을 것이라고 이해했습니다 b "실제로 최상단의 context 컴포넌트로부터 props drilling이 일어나고 있지만 그것을 겉으로는 숨겨주는 역할일 뿐이고" 이 부분은 Context api의 목적이 props drilling을 없애고자 하는거라 "Context의 상태가 변경되면 Context Provider 하위의 컴포넌트가 모두 재렌더링"되는 상황을 말한거라고 해석하면 될까요?
더해서 아직 안정화 단계라 웹 소켓 관련 이슈가 많은 듯하여 웹 소켓 사용할 생각이 있으면 Recoil 사용을 좀 고민해보는 게 좋을 것 같습니다!

Hook에 관하여..

제가 질문 했던 의도는 Scrap.tsx 라는 컴포넌트 파일 안에서 사용할 useScrap이라는 훅이 있다면, 이 훅의 위치는 아래와 같아야 하지 않나 하는 것이었습니다. 컴포넌트 파일 내부에 작성하면 파일도 비대해지고 필요시에 훅을 찾기가 어려울 것 같아서요!

components/
┣ Scrap/
┃ ┣ Scrap.tsx
┃ ┣ useScrap.ts
hooks/
┣ useSomething.ts (공통 훅)

index.tsx의 역할

네! 제가 생각한 index.tsx의 역할은 그저 컴포넌트, 훅 들을 모아서 export 해주는 것입니다. 별도로 index.tsx가 없고 내보내고자 하는 컴포넌트를 components/index.tsx 에서 모두 export 하는 것으로 관리하는 방식도 좋을 것 같아요. 이 서비스는 해당사항이 없지만 라이브러리를 만들 때는 어떤 컴포넌트들이 export 되고 있는 지 한 눈에 보기 쉬워야 유지보수하기 쉬워서요!

스타일에 관하여...

보통 컴포넌트 끼리 공유할 수 있는 스타일은 common이나 style이라는 폴더에 따로 정의해서 import 해와서 사용하는 것 같아요. 아니면, 공통 폴더에 common이라는 폴더를 정의하여 공통으로 쓸 것들을 한꺼번에 다루는 방법도 있겠네요.

components/
┣ Something/
┃ ┣ A.tsx
┃ ┣ B.tsx
┃ ┣ common.ts

파일명 확장자 앞에 명확히 구분해주는 네이밍을 붙이는 것은 완전 찬성입니다 :)

[LeeMir]

@bucketressi

감사합니다! 어느 정도 갈피가 잡혀가는 것 같아요 🙌

---

Context api의 목적이 props drilling을 없애고자 하는거라 "Context의 상태가 변경되면 Context Provider 하위의 컴포넌트가 모두 재렌더링"되는 상황을 말한거라고 해석하면 될까요?

제가 이해하고 있는 바로는 그렇습니다! recoil도 사실 상위 컴포넌트가 recoil을 구독하고 있으면 하위 컴포넌트가 같이 재렌더링되는 것은 결국 마찬가지입니다. 그러나 context는 컴포넌트 규모가 어쩔 수 없이 커졌을 때 context와 직접적인 관련이 없는데 맥락상 하위에 있다는 이유만으로 재렌더링되는 컴포넌트가 생기는 상황이 있을 수 있고, 이는 그 규모가 커질수록 개발자 입장에서는 예측하거나 제어하기 힘들어 부담이 된다고 생각합니다. recoil은 그 depth를 최소한으로 줄여서 예방할 수 있다는 것이 장점인 것 같아요!

원래는 recoil에서 제공하는 selector라는 함수가 기가 막힌 친군데 (api 캐시 기능 제공 + react suspense와 자동으로 연동됨), react-query 쓰는 바람에 그 장점은 흐릿해졌어요,, 😭

---

사실 context를 잘 안썼던 터라 한 컴포넌트에서만 쓰는 훅이 어떤 의미가 있는지, 어떤 상황에서 쓰는지 이해가 안됐었는데, 이번에 좀 찾아보면서 알게됐습니다. 아토믹 디자인에 대해서도 다시 한 번 찾아보게 됐는데, 그러다가 Compound Component라는 개념을 처음 접했습니다! [ 요기서 봤어요 ]
지금 패턴에 Compound Component가 좀 잘 맞을 것 같기도 해서 이번에 공부해보려고 합니다! 근데 context 써야하더ㄹ..

지금까지 이야기를 종합해보면 구조가 대략 이런 것 같습니다.
(일단 단위 테스트만 한다는 가정 하에)

components/
┣ A/
┃ ┣ AA/
┃ ┃ ┣ AA.tsx
┃ ┃ ┣ AA.styled.ts
┃ ┃ ┗ AA.test.ts       # @testing-library
┃ ┣ BB/
┃ ┃ ┣ BB.tsx
┃ ┃ ┣ BB.styled.ts
┃ ┃ ┗ BB.test.ts
┃ ┣ A.tsx              # A는 <AA />와 <BB />로 이루어진 컴포넌트
┃ ┣ A.common.styled.ts # A, AA, BB의 common style..?
┃ ┣ A.styled.ts        # common 아니고 A에서만 쓸 styled
┃ ┣ A.test.ts
┃ ┗ useA.ts
┗ index.tsx

제가 이걸 적으면서도 이게 맞나 싶긴 한데 Compound Component를 적용한다고 했을 때 한 .tsx 파일에서 부속 컴포넌트를 정의하는 것이 아니라 <A.AA /> <A.BB />로 위와 같이 파일을 분리한 구조를 갖는다고 가정했을 때 AA 대신 Title Wrapper Container와 같은 흔한 이름일 경우를 생각해보았는데요, 이건 styled 또한 흔한 이름으로 지은 후 export 했을 때와도 같은 것 같아 급하게 예시를 찍어봤습니다.

<Wrapper />를 쓰고 싶은데, 여기저기서 다 export 하다보니 이게 B.styled.ts라고 명시가 되어있더라도 헷갈릴 수 있겠다 싶은 상황입니다.

style을 .tsx 안에 함께 정의하면 되겠지만 그 방법은 제외한다치고
이런 상황을 겪으신 적이 있는지, 어떻게 해결하셨는지 궁금합니다!