이번에 새로 사이드프로젝트 돌릴려고 이것저것 새로운걸 참고하고있는데, 정말정말 유요한 프론트엔드 지식을 얻어가는거 같아서 재미있게 시청했습니다! 마치 자바의 스프링 프레임워크와 유사하게 계층구조를 정하고 OOP를 따르는게 사실 새로운게 아님에도 불구하고 굉장히 센세이션하게 와닿네요..! 잘 공부해서 유용하게 사용해봐야겠습니다! 감사합니다~
좋은 자료 감사합니다. 저도 좀 몇자 남겨봅니다... - 좋은 폴더구조는, 어떤 하나의 구조라고 딱 짚어서 말 할 수 없고, 그 App 의 기능과 목적에 따라서 개발자가 직관적으로 이해할 수 있도록 구조화 되어 있는 것이 좋은 폴더구조라고 생각합니다. - 그래서 먼저 App의 유형을 분류하는 것이 더 우선이라고 생각하는데, 제 경험상 Frontend application 은 크게, model centric / page centric 이 두가지 분류로 나뉘게 됩니다. - 둘다 global level 에서 공유되어야 하는 구조 (types, util, api 등등)을 가져가야 하는 것은 당연합니다 - 다만 차이가 발생하는 부분은, 다음과 같습니다 - model centric 한 application 은, model 혹은 entity가 중심이 되어서 app lifecycle 이 흘러가는 경우가 많습니다. 여러 페이지에서도 동일한 model 을 바라봐야 하는 경우가 많고, 심지어는 초기에 만든 model instance 를 전역에 담아두고 계속 끌고 가야 하는 경우도 있습니다. - page centric 한 application은, page 별로 독립된 context 를 가지는 경우가 많아서, page 내에서 서로 참조하기 쉽도록 공유 로직을 가져가야 하는 경우가 많습니다. 단 예외로 다중 page 에서 공유해야 하는 것들도 생기기 때문에, 이때는 shared page 를 만들어서 이를 바라보도록 하는 것이 좋습니다 - 따라서 제 결론은 본인이 만드는 app이 어떤 유형에 해당하는지 먼저 파악한 다음에, 재사용성과 계층화를 염두에 두셔서 폴더구조를 생각하면 어느정도 정답이 나오지 않을까 싶습니다. 물론 제가 생각한 각각 유형에 따른 정답도 있긴 있으나 설명하면 너무 길어져서 패스... - 언급하신 fsd 구조에서는...작성하신 분께서도 process 라는 걸 넣었다가 deprecate 라고 딱지를 달아놓으셨고... features 라는건 설명이 좀 애매하네요. 저는 솔직히 별로 와닿지가 않습니다 ㅎㅎ;
건의사항이 있는데요, 프론트진영에서 패키지명을 복수명으로 쓰는것에 약간의 거부감이 있는데, 프론트 영역의 오래된 네이밍 컨밴션이라 사용은 하고 있습니다만, 단수명 대신 북수명으로 사용할 경우에 얻는 이점을 다루어 주실수 있으신가요? 백엔드 구성에 매몰되어 단수명 패키징이 옳다라고 느끼는 쪽입니다😅
@@ZeroChoTV 예 맞습니다.( src 하위 소스코드 디렉토리) 영상에서도 LV2 (entities 하위) 폴더이름이 단수형 이름으로 되어있기도 하고, 왠지 단수형태 이름이 타입을 나타내기도 하기 때문이라 생각이 드네요. 그래서 LV1 단의 폴더명이 단수형태로 가는건 어떻게 생각하실지 궁금합니다.
@@ZeroChoTV 그.. 단순히 복수가 여러개다 라는 것은 알고있으나 저의 궁금증은, 폴더를 구분짓는 이유가 "카테고리를 나눈다" 라는 의미에서 복수형태 이름을 두는 이유가 궁금했습니다. 예를들어 entities 대신 entity 라고 해도 그룹화 하는데 문제가 없는데, 궂이 복수형태로 이름을 짓는 이유는, 타 언어와 구분짓기 위함인지 다른이유가 있는지 말이지요, 역사와 관련된 질문인것 같습니다. 이 부분에 대해 다루어주실 수 있는지 질문하게 되었습니다.
관점이 좀 다른것 같은데요. 폴더 이름을 지을 때 카테고리를 나눈다라고 생각하기보다는 폴더가 무엇을 포함하고있냐로 보는 것 같습니다. 폴더 안에 엔티티 여러개를 포함하고 있으니 entities인 것이고, 폴더가 model/ui/lib을 합쳐서 post 엔티티 하나를 구성하니 post가 되는 것이죠.
@@iwilldowhatiwannado843왜 반말을...? 꼭 라우팅을 위해서만 폴더 구조가 있는게 아니라 도메인 로직을 관심사에 맞게 분리할 목적으로 적용할 수도 있습니다 예를 들어 어떤 서비스의 핵심적인 개념이 ‘검색’과 ‘회원’이라고 가정했을 때 이 개념들은 여러 페이지에 걸쳐 등장할 가능성이 높기 때문에 단순히 components / utils / types / ... 이런 식의 분류보다는 search / users 같은 방식으로 나누고 코로케이션 하는 게 유리한 점이 있다는 겁니다 서비스가 엔터프라이즈 레벨에 가까워질 수록 효과는 커지겠죠 클린 아키텍처에서 소리치는 아키텍처 같은 개념도 넓게 보면 fsd와 같은 발상에서 시작했다고 볼 수 있는 등 난데 없이 나온 개념도 아니고요
꼭 라우팅을 위해서만 폴더 구조를 만드는게 아니라 도메인 로직을 관심사에 맞게 분리할 목적으로 적용할 수도 있습니다 예를 들어 어떤 서비스의 핵심적인 개념이 ‘검색’과 ‘회원’이라고 가정했을 때 이 개념들은 여러 페이지에 걸쳐 등장할 가능성이 높기 때문에 단순히 components / utils / types / ... 이런 식의 분류보다는 search / users 같은 방식으로 나누고 코로케이션 하는 게 유리한 점이 있다는 겁니다 서비스가 엔터프라이즈 레벨에 가까워질 수록 효과는 커지겠죠 클린 아키텍처에서 소리치는 아키텍처 같은 개념도 넓게 보면 fsd와 같은 발상에서 시작했다고 볼 수 있는 등 여러모로 괜찮은 방법이라고 생각합니다 참고로 fsd를 사용할 때 린트 룰도 함께 사용할 수 있어서 허용되지 않은 방향으로의 모듈 참조를 막을 수도 있습니다. 이렇게 하면 로직의 의존성을 순수하게 만들 수도 있는 등 코드 유지보수 특히 협업 측면에서 장점이 많다고 생각합니다
![[제로초뉴스]2024년 리액트 개발자라면 이 영상만 보시면 됩니다(트렌드 라이브러리 정리)](http://i.ytimg.com/vi/k0oqyokMm5Y/mqdefault.jpg)
![[제로초뉴스]2024년 리액트 개발자라면 이 영상만 보시면 됩니다(트렌드 라이브러리 정리)](/img/tr.png)
![[제로초뉴스]연말에 React 19가 나온다고 하네요! 예상 업뎃사항 간단하게 살펴보기](/img/n.gif)
emewjin.github.io/feature-sliced-design/?
결국에 프로젝트 구조에 답은 없다를 완전히 이해하고 받아드리는 것이 중요한 것 같아요.
저는 이것 때문에 답이 있을 거라는 생각으로 고민한 시간이 얼마인지 모르겠습니다.
좋은 팁 공유해 주셔서 감사합니다!
기존 components 역할이 features, entities, shared로 나눠지는게 핵심이네요
fsd 깃허브 가보시면 관련 eslint 규칙이 있더라구요. 규칙이 헷갈리거나 팀원들에게 강제할 때 쓰면 유용할 것 같습니다.
좋은 정보 감사합니다
감사합니다
좋은 영상 감사합니다!
이번에 새로 사이드프로젝트 돌릴려고 이것저것 새로운걸 참고하고있는데, 정말정말 유요한 프론트엔드 지식을 얻어가는거 같아서 재미있게 시청했습니다! 마치 자바의 스프링 프레임워크와 유사하게 계층구조를 정하고 OOP를 따르는게 사실 새로운게 아님에도 불구하고 굉장히 센세이션하게 와닿네요..! 잘 공부해서 유용하게 사용해봐야겠습니다! 감사합니다~
폴더구조 매번 고민 많았는데 감사합니다!
좋은 강의 정말 감사합니다
동작과 UI의 완전한 분리가 신선하네..
신선하니 도입해본다.
폴더구조 고민 많았는데 좋은 정보 감사합니다!!
저도 아티클 읽고나서 다음 프로젝트에 도입해보고 싶어서 공식문서 보면서 공부중인데 제로초님의 분석을 다시 보니 도움이 많이 됩니다!!
굳굳입니다잉~
좋은 자료 감사합니다. 저도 좀 몇자 남겨봅니다...
- 좋은 폴더구조는, 어떤 하나의 구조라고 딱 짚어서 말 할 수 없고, 그 App 의 기능과 목적에 따라서 개발자가 직관적으로 이해할 수 있도록 구조화 되어 있는 것이 좋은 폴더구조라고 생각합니다.
- 그래서 먼저 App의 유형을 분류하는 것이 더 우선이라고 생각하는데, 제 경험상 Frontend application 은 크게, model centric / page centric 이 두가지 분류로 나뉘게 됩니다.
- 둘다 global level 에서 공유되어야 하는 구조 (types, util, api 등등)을 가져가야 하는 것은 당연합니다
- 다만 차이가 발생하는 부분은, 다음과 같습니다
- model centric 한 application 은, model 혹은 entity가 중심이 되어서 app lifecycle 이 흘러가는 경우가 많습니다. 여러 페이지에서도 동일한 model 을 바라봐야 하는 경우가 많고, 심지어는 초기에 만든 model instance 를 전역에 담아두고 계속 끌고 가야 하는 경우도 있습니다.
- page centric 한 application은, page 별로 독립된 context 를 가지는 경우가 많아서, page 내에서 서로 참조하기 쉽도록 공유 로직을 가져가야 하는 경우가 많습니다. 단 예외로 다중 page 에서 공유해야 하는 것들도 생기기 때문에, 이때는 shared page 를 만들어서 이를 바라보도록 하는 것이 좋습니다
- 따라서 제 결론은 본인이 만드는 app이 어떤 유형에 해당하는지 먼저 파악한 다음에, 재사용성과 계층화를 염두에 두셔서 폴더구조를 생각하면 어느정도 정답이 나오지 않을까 싶습니다. 물론 제가 생각한 각각 유형에 따른 정답도 있긴 있으나 설명하면 너무 길어져서 패스...
- 언급하신 fsd 구조에서는...작성하신 분께서도 process 라는 걸 넣었다가 deprecate 라고 딱지를 달아놓으셨고... features 라는건 설명이 좀 애매하네요. 저는 솔직히 별로 와닿지가 않습니다 ㅎㅎ;
오 저도 각 페이지별로 서비스가 독립적이고 다루는 데이터도 분리된 성격의 서비스를 만들고 있는데 보면서 공감이 안됐던 부분이 비슷했어요
말씀하신 page centric 성격의 서비스에선 fsd 구조를 생각했을때 상상이 잘 안가네요
시간되시면 각각 유형에 따른 정답도 말씀해주세요 ㅎㅎ
새책 프사 긔여움 😊
저는 컴포넌트 재사용 유무, 컴포넌트내에서 데이터패치/스토어 호출 유무에 따라 나누는데 정신 똑바로 안차리면 중구난방 되더라고요 ㅠ
네 맞습니다. 팀 내에 명확한 기준이 필요합니다
건의사항이 있는데요, 프론트진영에서 패키지명을 복수명으로 쓰는것에 약간의 거부감이 있는데, 프론트 영역의 오래된 네이밍 컨밴션이라 사용은 하고 있습니다만, 단수명 대신 북수명으로 사용할 경우에 얻는 이점을 다루어 주실수 있으신가요? 백엔드 구성에 매몰되어 단수명 패키징이 옳다라고 느끼는 쪽입니다😅
디렉토리 이름 말씀하시는 건가요??
@@ZeroChoTV 예 맞습니다.( src 하위 소스코드 디렉토리) 영상에서도 LV2 (entities 하위) 폴더이름이 단수형 이름으로 되어있기도 하고, 왠지 단수형태 이름이 타입을 나타내기도 하기 때문이라 생각이 드네요. 그래서 LV1 단의 폴더명이 단수형태로 가는건 어떻게 생각하실지 궁금합니다.
entities 폴더 안에는 post, comment, slice같은 엔티티들이 여러 개 들어있어서 복수형이고, post 안에는 model, ui, lib같은 post의 구성요소들이 들어있어서 post는 단수인 것입니다.
@@ZeroChoTV 그.. 단순히 복수가 여러개다 라는 것은 알고있으나 저의 궁금증은, 폴더를 구분짓는 이유가 "카테고리를 나눈다" 라는 의미에서 복수형태 이름을 두는 이유가 궁금했습니다. 예를들어 entities 대신 entity 라고 해도 그룹화 하는데 문제가 없는데, 궂이 복수형태로 이름을 짓는 이유는, 타 언어와 구분짓기 위함인지 다른이유가 있는지 말이지요, 역사와 관련된 질문인것 같습니다. 이 부분에 대해 다루어주실 수 있는지 질문하게 되었습니다.
관점이 좀 다른것 같은데요. 폴더 이름을 지을 때 카테고리를 나눈다라고 생각하기보다는 폴더가 무엇을 포함하고있냐로 보는 것 같습니다. 폴더 안에 엔티티 여러개를 포함하고 있으니 entities인 것이고, 폴더가 model/ui/lib을 합쳐서 post 엔티티 하나를 구성하니 post가 되는 것이죠.
들어도 어렵네요 ㅜㅜ 한번 직접 만들어봐야 될거같아요
레이아웃이 위젯이 되는걸 보고 플러터 구조가 떠오르네요ㅋㅋ
폴더구조 고민중이라 호다닥 달려왔는데 영상만 봐서는 코드 파편화가 엄청 심해질거같네요.. 제 개인적인 취향은 colocation을 챙기는 걸 선호해서 저는 도입을 보류해야겠습니다 ㅠㅠ
감사합니다
영상을 보고 느낀점이 FSD 또한 하나의 방법론이고 정답은 없다라는 결론이 나오네요
맞습니다!
폴더 구조가 네트워크 OSI 7계층이 생각나네요 ㅋㅋㅋ
icon 써주면 안될까요?
구조를 보여주는데 icon없어서 잘 안보이네요
좀 부담되는데 얼굴 크기를 줄여주실 수 있나요;
아니 이게 적고 보니 오해의 소지가 좀 있네요;;
화면 내 강의자분의 얼굴이 차지하는 영역을 좀 줄여주실 수 있을지입니다;;
외모비하의도 절대 없습니다.
더 강의에 집중이 잘 될 것 같아서요.
좋은 영상 감사합니다.
ㅋㅋㅋㅋㅋㅋ 이런답글은 처음보네요
전 딱좋은데 ㅎㅎㅎㅎ
@@swh9362 강의영상은 얼굴 작은게 좋죠
강의영상은 얼굴 작게 넣긴 한데, 이건 강의는 아니고 유튜브 컨텐츠라서 키웠습니다 ㅎㅎ
전 남자고, 보통 다른 남자분이면 부담될 법한데 제로쵸님 인물이 훤칠하셔서 딱히 부담되진 않네요 ㅎㅎ
👍👍
슬랙 링크가 활성이 안 되어서 참여할 수가 없습니다 ㅜㅜ 어떻게 하면 될까요?
바로 수정해두겠습니다
@@ZeroChoTV 감사합니다!
오 직접해바야겟어요❤ FSD를 이용한 넥스트 앱라우터 환경에서도 될까요?
넥스트용 앱라우터 폴더만 예외로 삼으면 됩니다. (fsd의 pages 폴더 대체)
Provider, Router가 HOC 인가요?
넵
@@ZeroChoTV HOC가 component를 인자로 받고 component를 반환하는 함수로 알고있는데,
Provider 나 Router는 조금 다르지 않나해서요!
아 순간 children을 받는 것과 헷갈렸네요. 말씀하신게 맞습니다. 주로 withOOO(컴포넌트) 이런 식으로 사용되는 함수들이었는데 리액트 훅 나오면서 사실상 레거시 취급이긴 합니다.
질문있습니다. FSD 샘플들 보면 공개api index.ts를 zeroCho님이 설명하신것처럼 별도로 import 해서 사용하는 코드는 안보이는데 그냥 index.ts에서 export 제약만 걸어두는건가요?
네네 외부에서 import할 것들만 export 하는 것입니다.
무슨말인지 하나도 모르겠습니다 하하
걍 nextjs 쓰면 대지 먼 아직도 바닐라 리액트로 폴더구조를 짜고있노
nextjs에도 fsd 적용 가능해요
@@oj8mmnextjs가 이미 자동 폴더 라우팅 방식인데 fsd를 왜하냐;;;
fsd랑 nextjs 폴더 라우팅이랑은 아무 관련이 없는데...
@@iwilldowhatiwannado843왜 반말을...? 꼭 라우팅을 위해서만 폴더 구조가 있는게 아니라 도메인 로직을 관심사에 맞게 분리할 목적으로 적용할 수도 있습니다
예를 들어 어떤 서비스의 핵심적인 개념이 ‘검색’과 ‘회원’이라고 가정했을 때 이 개념들은 여러 페이지에 걸쳐 등장할 가능성이 높기 때문에
단순히 components / utils / types / ... 이런 식의 분류보다는 search / users 같은 방식으로 나누고 코로케이션 하는 게 유리한 점이 있다는 겁니다 서비스가 엔터프라이즈 레벨에 가까워질 수록 효과는 커지겠죠
클린 아키텍처에서 소리치는 아키텍처 같은 개념도 넓게 보면 fsd와 같은 발상에서 시작했다고 볼 수 있는 등 난데 없이 나온 개념도 아니고요
꼭 라우팅을 위해서만 폴더 구조를 만드는게 아니라 도메인 로직을 관심사에 맞게 분리할 목적으로 적용할 수도 있습니다
예를 들어 어떤 서비스의 핵심적인 개념이 ‘검색’과 ‘회원’이라고 가정했을 때 이 개념들은 여러 페이지에 걸쳐 등장할 가능성이 높기 때문에 단순히 components / utils / types / ... 이런 식의 분류보다는 search / users 같은 방식으로 나누고 코로케이션 하는 게 유리한 점이 있다는 겁니다 서비스가 엔터프라이즈 레벨에 가까워질 수록 효과는 커지겠죠
클린 아키텍처에서 소리치는 아키텍처 같은 개념도 넓게 보면 fsd와 같은 발상에서 시작했다고 볼 수 있는 등 여러모로 괜찮은 방법이라고 생각합니다
참고로 fsd를 사용할 때 린트 룰도 함께 사용할 수 있어서 허용되지 않은 방향으로의 모듈 참조를 막을 수도 있습니다. 이렇게 하면 로직의 의존성을 순수하게 만들 수도 있는 등 코드 유지보수 특히 협업 측면에서 장점이 많다고 생각합니다
감사합니다