⚙ Setting(#16): 폴더구조_생성

rhehfl commented 4 days ago

🔗 관련 이슈

⚙ Setting(#16)

📝작업 내용

기존에는 컴포넌트 안에 각 페이지별로 들어가야 할 컴포넌트를 만들었음 ⇒ 페이지별 퍼블리싱, 기능구현

⇒ 확장성 없는 컴포넌트와 스타일이 단점

기본적으로 모든 컴포넌트들을 재사용된다는 가능성을 두고 구조를 짜고싶다 라는 생각이 들어서 폴더구조를 잡게 되었습니다

apis : Axios의 기본 인스턴스 세팅이 들어가는 폴더입니다 api request, response 요청에 대한 추가 작업이나 각 상태코드별 예외처리가 이루어지는 단계입니다
components: 재사용 가능한 컴포넌트들이 모이는 공간 각 컴포넌트는 고유한 스타일과 기능을 가질 수 있지만 기본적인 레이아웃(틀) 은 재사용된다는 가정하에 비즈니스 로직을 분리해야 함
따라서 이런 분리된 비즈니스 로직들은 services에 들어감
1. 비즈니스 로직에서 사용되는 훅, 유틸함수들은 각각 hooks 와 utils에 분리되어 들어감 이유는 다른 비즈니스 로직이여도 같은 기능이 있을 수 있기 때문 ex) 회원가입, 로그인에 유효성 검사 등등이 겹칠 수 있음
zustand를 사용한 전역 상태 관리 저장소로 store 폴더를 이용
전역 스타일을 style에 지정 각 컴포넌트에서 이를 상속받거나 새로 만들어서 스타일을 생성한다
공용 타입들을 types에 모아놓음

🔍 변경 사항

[ ] 변경 사항 1
[ ] 변경 사항 2
[ ] 변경 사항 3

💬리뷰 요구사항 (선택사항)

각 폴더구조를 봤을때 합리적인지 아니라면 어떤식으로 프로젝트를 진행했으면 좋겠는지 적어주셨으면 좋겠습니다

bluetree7878 commented 3 days ago

아 그럼 components 폴더 안에 들어가는 것들은 대부분 UI 부분의 컴포넌트들이고 실질적으로 그걸 작동시키게 하는 비즈니스 로직이 services 안에서 처리해준다는 거군요. 그럼 components 폴더 안에 파일이 많이 들어갈 텐데 혹시 그 안에서도 폴더를 여러 개로 나뉘어 정리할 생각이신가요?

rhehfl commented 3 days ago

네 일단은 매 스프린트마다 새로운 기능이 도입된다는 가정하에 생각을 했기때문에 컴포넌트 안에서 도메인별로 나눌 생각입니다 서비스쪽 코드가 많아지면 마찬가지로 도메인별로 나눈다면 1:1로 매칭되어서 수정하거나 할때 찾기도 쉬울 것 같고 확장성도 좋을 것 같아서용 현성님 생각은 어떤가요

bluetree7878 commented 3 days ago

오... 괜찮다고 느끼는 게 이렇게 나눠도 도윤님 말씀대로라면 도메인별로 나누니까 찾기 쉬울 것 같아요 전 좋습니다👍👍

zzzRYT commented 3 days ago

오랫동안 고민하시고 선택하신게 느껴집니다. 이미 알고 계신 내용일 수 있지만, 제 경험을 살려서 이야기 해 드리겠습니다. 저는 딱히 디자이너와 고민하지 않고, 재사용이 되는 component를 생길 때 마다, 따로 compoent로 분리해서 작업을 진행했습니다. 근데 이런식으로 작업을하면 문제점이, 컨벤션입니다

분명, 나는 게시판 페이지에 대한 퍼블리싱을 진행하고 있는데, 재활용 되는 컴포넌트가 많아서, 컴포넌트 분리를 위한 작업이 많아지는 경우가 있었습니다. 그럼, 해당 작업에서 이 사람이, 컴포넌트를 분리하고 싶은건지, 퍼블리싱을 하고 싶은건지 볼 때 애매할 때가 있었던 것 같습니다.(저의 경우엔 그랬습니다😅),

그래서 따로 UI를 위한 작업을 할 때, issue를 새로 파서 작업을 했습니다.🥲 작업을 두 번 한 셈인거죠,

제가 생각할때는 이런 상황을 극복할 수 있는게, 디자인 시스템 이라고 생각합니다. 디자인 시스템은 디자이너와, 개발자 (원래는 기획자도 포함)이 상의 하에, 만들어지는 일종의 컨벤션이라고 생각하시면 될 것 같습니다. 참고 블로그

이미지 출처 이런식으로 디자이너와 미리, UI에 대한 정보를 공유하고, 그 값을 미리 정의해 둔다면, 어떤 페이지에 어떤 부분에서 해당 디자인을 사용할 수 있도록 디자이너와 이야기를 해 둔다면,

디자이너는 물론, 개발자 입장에서도 빠르게 UI생성이 가능하기 때문에, 좋은 효율로 이어진다고 생각합니다.

이 때, 디자이너와 개발자가 소통하기 위해 사용하기 좋은 라이브러리가 스토리북공식사이트 입니다.

위에서 언급했듯이, 미리 정의해 둔 UI를 스토리북(일종의 디자인 테스팅 도구)을 활용해서 소통하면, 디자이너도 실제로 사이트 내에서 사용하는 UI를 확인이 가능하고, 빠르게 수정도 가능합니다. 패션24에서 사용하는 storybook

사실 패션 24는 따로 디자인 시스템을 정의하지는 않아서 저 혼자 만들었습니다...좀 힘드네요...

워낙 유명한 라이브러리이기도 하고, 배포도 쉬워서 많이들 사용하는 것 같습니다. 좋은 디자이너가 있다면, 한 번 쯤 상의 후 사용해보시면 좋을 것 같습니다.

rhehfl commented 3 days ago

확실히 맞는 말이네요 나중에 웹 규모가 커지면 커질수록 컴포넌트에서 재사용 가능한 컴포넌트를 분리하는 작업을 하는 시간이 많아질 것 같다는 생각이 듭니다. 하나 궁금한점이 사전에 디자이너와 충분한 소통을 거쳐서 완전히 재사용 가능한 단위로만 분리했다고 가정하면 이러한 컴포넌튼느 도메인 단위로 분리할 수 없고 components폴더에 한번에 넣어야 할까요?

modern-agile-team / 8term-coko-Front