[6팀 김소리] Chapter 3-3 기능 중심 아키텍처와 프로젝트 폴더 구조

.env.development

@@ -0,0 +1 @@
+VITE_API_BASE_URL=/api

.env.production

@@ -0,0 +1 @@
+VITE_API_BASE_URL=https://dummyjson.com

.github/workflows/deploy.yml

@@ -0,0 +1,59 @@
+name: Deploy to GitHub Pages
+
+on:
+  push:
+    branches:
+      - main
+  workflow_dispatch:
+
+permissions:
+  contents: read
+  pages: write
+  id-token: write
+
+concurrency:
+  group: 'pages'
+  cancel-in-progress: true
+
+jobs:
+  build:
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout source
+        uses: actions/checkout@v4
+
+      - name: Setup pnpm
+        uses: pnpm/action-setup@v4
+        with:
+          version: latest
+
+      - name: Setup Node.js
+        uses: actions/setup-node@v4
+        with:
+          node-version: 22
+          cache: 'pnpm'
+
+      - name: Install dependencies
+        run: pnpm install --frozen-lockfile
+
+      - name: Build
+        run: pnpm run build
+
+      - name: Copy 404.html
+        run: cp dist/index.html dist/404.html
+
+      - name: Upload artifact
+        uses: actions/upload-pages-artifact@v3
+        with:
+          path: dist
+
+  deploy:
+    needs: build
+    runs-on: ubuntu-latest
+    environment:
+      name: github-pages
+      url: ${{ steps.deployment.outputs.page_url }}
+    steps:
+      - name: Deploy to GitHub Pages
+        id: deployment
+        uses: actions/deploy-pages@v4

README.md

@@ -1,106 +1,14 @@
 # Chapter3-3. 기능 중심 아키텍처와 프로젝트 폴더구조
+https://milmilkim.github.io/front_7th_chapter3-3/
 
-## [3주차] 기본과제
+## 과제 셀프회고
+FSD를 '그런 게 있다더라'하는 정도로만 알고 있었기 때문에 개념자체가 새로웠다. 이전 과제들은 그래도 어느 정도 아는 것들이었는데 FSD가 과제 중에서 제일 알기 어려운 부분이었다. 
 
-여러분은 게시판을 관리할 수 있는 Admin 코드를 인수인계 받았습니다. 다행히 못 알아볼 정도의 더티코드는 아니고 적당히 잘 만든 것 같지만 정리가 된 것 같지 않은 아주 현실감 있는 익숙한 느낌의 코드였습니다.
+디렉토리 구조를 어떻게 꾸려갈지는 개발을 할 떄 항상 어려웠던 부분이다. 일을 할 떄 초도개발을 할 일이 많았는데 그떄마다 구조를 조금씩 바꿔 보았고, 항상 단점이 있었다. 발제나 Q&A에도 나온 얘기지만 2depth는 정해진 게 없어서 어딘가 불편한 느낌이 드는 것이었다. 나의 경우에는 프로젝트 규모가 FSD의 도입을 고민할 정도로 커졌던 일이 없었기에 그냥 구조를 최대한 펼쳐놓고 폴더 구조 고민을 안 하게 하는 것을 선택했다. (컨벤션을 정하기 쉽지 않고 작업자가 자주 바뀌는 환경이었다.)
 
-우리는 지금까지 배웠던 내용을 토대로 해당 코드들을 클린하게 정돈하고 FSD 아키텍쳐를 활용해서 정리해보려고 합니다.
+처음엔 '그래서 이 방식을 왜 써야 하는 거지'하는 생각을 계속 했었는데, 지금은 FSD의 장점을 알 것 같다. 도입하기는 힘든데 그 방법을 정하고 나면 앞으로는 정해진 규칙대로 만들어나가면 되는 것이다.
 
-**여러분들은 해당 코드를 분석해보니 다음과 같은 문제점들을 발견할 수 있었습니다.**
+하나의 프로젝트를 길게 가져간다면 이 방식의 장점이 클 것 같다. 나는 아직 그런 경험이 없어서 잘 와닿지 않았다.
 
-1. 컴포넌트가 너무 크고 복잡하다.
-2. Typescript를 사용하고 있지만 Type처리가 부실하다.
-3. 상태관리의 개념없이 너무 많은 상태를 가지고 있다.
-4. useEffect 관리가 안되고 있다.
-5. 비동기 처리 로직이 복잡하게 구성되어 있다.
-
-**여러분들은 해당 코드를 개선하기 위해서 다음과 같은 목표를 세웠습니다.**
-
-1. Typescript를 확실히 사용해서 코드의 이해와 리팩토링에 대한 안정성을 확보합니다.
-2. 컴포넌트에 단일 책임 원칙을 부여하여 작게 만들고자 합니다.
-3. 적절한 관심사의 분리를 통해서 폴더구조를 만드려고 합니다.
-4. 이때 배웠던 FSD를 한번 적용해보려고 합니다.
-
-**Basic 과제**
-
-상태관리를 사용하여 관심리를 분리하고 FSD 폴더 구조를 적용하기
-
-```markdown
-목표:
-전역상태관리를 이용한 적절한 분리와 계층에 대한 이해를 통한 FSD 폴더 구조 적용하기
-
-- 전역상태관리를 사용해서 상태를 분리하고 관리하는 방법에 대한 이해
-- Context API, Jotai, Zustand 등 상태관리 라이브러리 사용하기
-
-- FSD(Feature-Sliced Design)에 대한 이해
-
-- FSD를 통한 관심사의 분리에 대한 이해
- - 단일책임과 역할이란 무엇인가?
- - 관심사를 하나만 가지고 있는가?
- - 어디에 무엇을 넣어야 하는가?
-
-
-체크포인트
-- [ ] 전역상태관리를 사용해서 상태를 분리하고 관리했나요?
-- [ ] Props Drilling을 최소화했나요?
-- [ ] shared 공통 컴포넌트를 분리했나요?
-- [ ] shared 공통 로직을 분리했나요?
-- [ ] entities를 중심으로 type을 정의하고 model을 분리했나요?
-- [ ] entities를 중심으로 ui를 분리했나요?
-- [ ] entities를 중심으로 api를 분리했나요?
-- [ ] feature를 중심으로 사용자행동(이벤트 처리)를 분리했나요?
-- [ ] feature를 중심으로 ui를 분리했나요?
-- [ ] feature를 중심으로 api를 분리했나요?
-- [ ] widget을 중심으로 데이터를 재사용가능한 형태로 분리했나요?
-```
-
-
-
-## [3주차] 심화과제
-
-여러분들은 비동기 코드가 들어가고 서버와 통신을 하기 시작하니 상태관리가 엄청나게 복잡해진다는 것을 알았습니다. 그래서 서버상태관리를 도입을 하면 보다 함수형 패러다임으로 선언적으로 비동기를 관리할 수 있다는 사실을 알게 되었습니다.
-
-**여러분들은 해당 코드를 개선하기 위해서 다음과 같은 목표를 세웠습니다.**
-
-1. TanstackQuery를 이해하고 적용해보자.
-2. api의 관리를 잘 할 수 있는 표준을 만들자.
-3. 기존에 만들어진 코드를 통해 낙관적인 업데이트를 적용해보자.
-
-**Advanced 과제**
-
-TanstackQuery를 이용하여 코드를 개선하기
-
-```markdown
-목표:
-서버상태관리 도구인 TanstackQuery를 이용하여 비동기코드를 선언적인 함수형 프로그래밍으로 작성하기 
-
-- TanstackQuery의 사용법에 대한 이해
-- TanstackQuery를 이용한 비동기 코드 작성에 대한 이해
-- 비동기 코드를 선언적인 함수형 프로그래밍으로 작성하는 방법에 대한 이해
-
-체크포인트
-- [ ] 모든 API 호출이 TanStack Query의 useQuery와 useMutation으로 대체되었는가?
-- [ ] 쿼리 키가 적절히 설정되었는가?
-- [ ] fetch와 useState가 아닌 선언적인 함수형 프로그래밍이 적절히 적용되었는가?
-- [ ] 캐싱과 리프레시 전략이 올바르게 구현되었는가?
-- [ ] 낙관적인 업데이트가 적용되었는가?
-- [ ] 에러 핸들링이 적절히 구현되었는가?
-- [ ] 서버 상태와 클라이언트 상태가 명확히 분리되었는가?
-- [ ] 코드가 간결하고 유지보수가 용이한 구조로 작성되었는가?
-- [ ] TanStack Query의 Devtools가 정상적으로 작동하는가?
-```
-
-
-## [3주차] 최종 과제
-
-FSD는 하나의 제안이지만, 여러분들은 FSD를 적용해보고 나면 조금 더 나은 구조를 만들 수 있다는 것을 알게 되었습니다. 
-그래서 여러분들은 FSD를 적용해보고 나서 다음과 같은 추가적인 목표를 세웠습니다.
-
-**조금 더 현대적이면서도 기능 중심의 폴더 구조를 만들 수 있지 않을까?**
-
-최종 목표는 다음과 같습니다.
-FSD가 아닌 자신만의 기능 중심의 폴더 구조를 만들어보세요.
-
-꼭 기억할 점
-1. 자신만의 기능 중심의 폴더라고 했지만, 그 모습이 상당히 유니크하고 독창적이지는 않을 거에요. 아마 적절한 모법사례의 조합으로 수렴될 거에요. 
-2. 그리고 그게 잘하는 거에요. 좋은 코드는? 자신보돠 남들에게 모두에게 이해하기 쉬운 코드니까요.
+아직은 막연한 부분은 Entity와 Feature 레이어의 구분이다. 다른 레이어들은 좀 헷갈려도 비교적 직관적인데 이 두 가지 레이어는 헷갈린다. Entity는 명사고 Feature는 동사라는 AI의 비유가 그래도 좀 와닿는 거 같다.
+나는 나름대로 FSD대로 했다고 생각하였지만 잘 맞지 않는 부분도 있는 듯 하다.

package.json

@@ -12,13 +12,16 @@
     "coverage": "vitest run --coverage"
   },
   "dependencies": {
+    "@tanstack/react-query": "^5.90.12",
     "react": "^19.2.1",
-    "react-dom": "^19.2.1"
+    "react-dom": "^19.2.1",
+    "zustand": "^5.0.9"
   },
   "devDependencies": {
     "@eslint/js": "^9.39.1",
     "@radix-ui/react-dialog": "^1.1.15",
     "@radix-ui/react-select": "^2.2.6",
+    "@tanstack/react-query-devtools": "^5.91.1",
     "@testing-library/jest-dom": "^6.9.1",
     "@testing-library/react": "^16.3.0",
     "@testing-library/user-event": "^14.6.1",