search

prefragrance / prefragrance-client

향으로 취향을 공유하고 나의 취향을 찾는 소셜미디어, 취향의 프론트엔드 저장소
0 stars 0 forks source link

pages / components 폴더 구조 개편 #10

Closed HiimKwak closed 2 years ago

HiimKwak commented 2 years ago

안녕하세요 횐님들. 이번엔 pages - components 폴더 두 개에 대한 단상입니다

현재 저희 prefragrance-client 프로젝트의 src 파일 아래 pages와 components 폴더의 구조를 살펴보면 아래와 같습니다

KakaoTalk_Photo_2022-08-28-14-32-06

저희가 상호 합의한 것과 같이 pages 폴더에는 정말 각 페이지를 구성하는 컴포넌트 단위로 잘라놓은 '스켈레톤' 형태의 프레임 파일만 존재하고

그 각각의 구성품들은 pages 관련 내용이지만 pages 폴더 바깥 components 폴더에 따로 위치하여 세포분열(?)하는 모습을 띄고 있습니다.


그런데 여기서 한 가지 다시 생각해볼 점은,

pages 폴더 아래에 각 페이지의 프레임 파일만 존재할거면 굳이 pages 폴더가 따로 구분되어야 할 필요가 있을까? 란 점입니다.

각 페이지 스켈레톤(프레임 or 템플릿) 파일과 각각의 컴포넌트 코드들이 같은 줄기에 연속적으로 놓여있지 않고 서로 완전히 구분된 위치에 놓여있어

특히나 컴포넌트 코드를 고치려 할 때 내가 보려는 페이지가 아닌 다른 페이지 폴더들과 같은 선상에 존재하고 있어 작업할 때 불편한 경험을 줍니다.

아래와 같이 바꿔보는건 어떨까요?

KakaoTalk_Photo_2022-08-28-14-32-12

이렇게 하면 저희가 지금 페이지 단위로 테스크를 분할해 작업하고 있는데 굳이 components 폴더를 펼쳐서 잘 구분도 안되는 shared 폴더와 home/search/detail 폴더를 펼쳤다 닫았다 들락날락 하지 않아도 되고

깔끔하게 pages - 각자 작업하는 페이지 폴더만 딱 열어놓고 작업할 수 있게 됩니다. 굉장히 편하지 않을까요?

횐님들은 어떻게 생각하시는지 알려주십쇼. 감사합니다.

HiimKwak commented 2 years ago

아, 추가로 다같이 읽어보면 좋을 양질의 글을 발견하여 공유해봅니다.

Atomic Design Pattern의 Best Practice 여정기

제가 위 글에서 '스켈레톤'과 '컴포넌트'라는 단어를 사용했는데, 이런 페이지 구분 단위에 대해서도 확실한 기준을 가지고 정해놔야 혼란이 없을 것 같습니다.

image

위 이미지는 제가 공유드린 글에서 사용한 이미지 중 하나인데요, Atomic Design Pattern의 핵심을 압축한 그림입니다.

저희도 얼추 위와 비슷하게 구분을 지어 작업하고 있긴 했습니다. 사진을 보시면 원래 이렇게 작업하고 있는거 아니였나? 싶을 정도로 특별한 내용은 아닙니다. 글을 더 읽어보시면 중간에 아래와 같은 구조를 언급하고 있습니다.

/components ㄴ /atoms ㄴ /molecules ㄴ /organisms ㄴ /templates /pages

구조를 보시면 여기도 components와 pages를 구분짓고 있네? 헛수고한거 아니야? 할 수 있지만

image

2안처럼 가져간다면 말이 달라지겠죠? 각 개인의 능률도 올라갈테고 추후 merge와 같이 합병 혹은 새로운 팀원(머나먼 미래의 일이지만..)이 만약 저희의 레거시 코드들을 관리하기 위해 들여다볼 때 훨씬 설득력있는 생명력이 긴 코드가 될 것입니다(위 사진 2안에서 제일 상위 Components 폴더명은 저희 프로젝트에서는 Pages가 될테고, 그 한 단계 아래 A와 B가 Home/Search/Detail이 될 것입니다).

오 글 써놓고 보니 댓글에 써놓은 구조가 더 좋아보이네요... 그럼 결론은 바로 위에 적어놓은 2안 구조로 하겠습니다 ㅋㅋㅋ

천천히 읽어보시고 답변 달아주시면 감사하겠습니다.

jellysoo97 commented 2 years ago

  1. 일단 pages랑 components를 구분한 이유는 container-presenter 구조를 생각했기 때문입니다.

    • container(우리 프로젝트는 pages) : 비즈니스 로직 관장 -> api 통신 등등
    • presenter(우리 프로젝트는 components) : 데이터 뿌리기 + 간단한 사용자 이벤트 처리(onChange 등등)

    이 구조는 필연적으로 props drilling 문제를 발생시키는데 이를 해결하기 위해 Recoil을 통한 전역적인 상태관리를 생각했습니다. 아무튼 컴포넌트 렌더링을 넘어서 페이지 자체의 에러 핸들링 (예를 들면, 로그인 실패나 과도한 로딩 등등) 더 나아가 배포 전 test를 위해서라도 pages-components 구분은 필요하다고 생각합니다.

  2. atomic design은 좋은 생각인 것 같습니다만 저희 현재 프로젝트 디렉 구조와 똑같이 무한 폴더 리스트의 굴레 빠지는 건 아닌가 하는 생각이 들었습니다. 재사용할 컴포넌트가 그렇게 많은가? 우리 프로젝트가 5단계로 계층을 분리할 정도인가? 오히려 컨벤션에 집착하다가 진행이 느려지는건 아닌가?하는 문제들이 생각났습니다.

    • 재사용할 컴포넌트가 많은가? : 이 문제의 경우 당장은 많지 않더라도 추후의 확장성을 생각하면 재사용가능한 컴포넌트로 쪼개는 것이 맞긴 합니다.
    • 5단계로 분리할 정도인가? : 물론 단계를 줄일 수도 있지만 atomic design 개발 후기에서 공통적으로 발견할 수 있었던 molecules와 organisms 구분 기준에 정답이 없는게 걸리는 점입니다.
    스크린샷 2022-08-31 오전 12 01 28

당장 위 컴포넌트만 보더라도 이렇게 나눌 수도 있고 다른 방안이 있을 수도 있습니다. molecules와 organisms을 나눌 명확한 기준을 정하지 않는 한 세세하게 나누기보다는 좀 더 큰 단위로 진행하는게 나을 것 같기도 합니다.

+atomic design pattern으로 간다면 1안이 더 많이 사용되는 것 같습니다. boostcamp github < 이 레포와 같은 구조가 많더라구요 참고하면 좋을 것 같습니다!

jellysoo97 commented 2 years ago

제가 생각한 폴더 구조 안은 기존 방식을 유지하되 정리를 하자입니다~

대략 이 정도인데 글보다는 직접 보는게 좋으니 제가 참고한 레포 보시면 좋을 것 같습니다👍 [유사한 기술 스택의 repo] < 이 레포의 폴더구조대로 가면 어떨까요?

두가지 방안이 나왔으니 둘 중 하나 고르면 될 것 같습니당

HiimKwak commented 2 years ago

팀장님 의견 읽어보니 폴더 구조를 개편하기보다는 기존 방식을 유지하고 정리하는게 더 낫겠다는 생각이 듭니다. 제가 atomic design pattern 글을 공유한 이유도 이 방식을 도입하고 싶어서라기 보단 우리가 작업하는 방식을 선택하는 폭을 넓히고 선택할 때 왜 그 방안을 선택했는지에 대한 이유를 보완하려는 목적이었습니다.

다만 몇 가지 질문이 있는데요,

  1. 전에는 pages를 container로 생각해서 pages 레벨에서 api 통신하려고 했는데 각각의 컴포넌트에서 다 처리하자는 말씀은 저희 기존 방식인 container - presenter에서 presenter 단에서 api 통신을 하자는 말씀으로 이해하면 되나요? container - presenter 구조에 대해서는 말씀해주신 것 덕분에 그 필요성을 납득할 수 있었는데, api 통신 문제를 Presenter단으로 내리자는 말씀은 잘 이해가 안되어 여쭤봅니다. (혹시 props drilling 문제때문에 그런건가요?)

  2. 스타일과 jsx를 합치는 건 불필요한 하위 폴더들이 생성되는 문제때문에 고안하신건가요? 스타일과 jsx를 한 파일에 합치는 건 못할 것은 아닙니다만 저도 개인적으로 선호하는 방식이 아니라.. 선뜻 합치기가 꺼려지네요 ㅜ

jellysoo97 commented 2 years ago

0831 회의)

해야할 것)

jellysoo97 commented 2 years ago

11 [Refactor] 완료