[1팀 이은지] Chapter 2-3. 관심사 분리와 폴더구조 by angielxx · Pull Request #48 · hanghae-plus/front_6th_chapter2-3

angielxx · 2025-08-14T19:25:10Z

배포 링크

https://angielxx.github.io/front_6th_chapter2-3

과제 체크포인트

기본과제

목표 : 전역상태관리를 이용한 적절한 분리와 계층에 대한 이해를 통한 FSD 폴더 구조 적용하기

전역상태관리를 사용해서 상태를 분리하고 관리하는 방법에 대한 이해
Context API, Jotai, Zustand 등 상태관리 라이브러리 사용하기
FSD(Feature-Sliced Design)에 대한 이해
FSD를 통한 관심사의 분리에 대한 이해
단일책임과 역할이란 무엇인가?
관심사를 하나만 가지고 있는가?
어디에 무엇을 넣어야 하는가?

체크포인트

심화과제

목표: 서버상태관리 도구인 TanStack Query를 이용하여 비동기코드를 선언적인 함수형 프로그래밍으로 작성하기

TanStack Query의 사용법에 대한 이해
TanStack Query를 이용한 비동기 코드 작성에 대한 이해
비동기 코드를 선언적인 함수형 프로그래밍으로 작성하는 방법에 대한 이해

체크포인트

모든 API 호출이 TanStack Query의 useQuery와 useMutation으로 대체되었는가?
쿼리 키가 적절히 설정되었는가?
fetch와 useState가 아닌 선언적인 함수형 프로그래밍이 적절히 적용되었는가?
캐싱과 리프레시 전략이 올바르게 구현되었는가?
낙관적인 업데이트가 적용되었는가?
에러 핸들링이 적절히 구현되었는가?
서버 상태와 클라이언트 상태가 명확히 분리되었는가?
코드가 간결하고 유지보수가 용이한 구조로 작성되었는가?
TanStack Query의 Devtools가 정상적으로 작동하는가?

최종과제

폴더구조와 나의 멘탈모델이 일치하나요?
다른 사람이 봐도 이해하기 쉬운 구조인가요?

과제 셀프회고

최종 과제는 final_src 폴더에 있습니다.

이번 과제를 통해 이전에 비해 새롭게 알게 된 점이 있다면 적어주세요.

FSD 아키텍처의 진짜 가치 체감해보기

레이어별 책임 분리의 강력함

FSD를 처음 적용할 때 가장 인상적이었던 건 "어디에 무엇을 넣어야 할지"가 명확해진다는 점이었습니다. 이전에는 새로운 기능을 추가할 때마다 "이 코드는 어느 폴더에 넣지?"라고 고민했는데, FSD를 적용하고 나니 자연스럽게 적절한 위치가 보이더라구요.

이렇게 각 레이어가 명확한 역할을 가지니까 코드를 찾기도 쉽고, 새로운 팀원이 와도 구조를 이해하기 쉬울 것 같았습니다.

하지만! 이런 장점을 체감하려면 FSD에 대해 정확히 이해하고 있고, 어느 정도 FSD에 익숙한 상태여야 가능합니다.

FSD 구조하에 모듈을 어디에 위치시킬지에 대한 zep 토론 흔적..

공통 UI 컴포넌트는 어떤식으로 분류할 것인가?

primitive 컴포넌트를 기능별로 분류하여 더 쉽게 찾아서 쓸 수 있도록 했습니다.

헤더를 어느 레이어에 넣을 것인가?

헤더,푸터의 경우 shared에 포함되는 primitive 컴포넌트보다 더 넓은 범위의 컴포넌트라고 생각해서 widget에 두었습니다. shared 내의 코드들은 어느 상황의 프로젝트에서도 사용할 수 있으만한 공통 모듈을 넣으려고 했습니다. 또한 의존성 부분에서도 pages에서만 사용되기 때문에 widget에 두는 것이 더 적절하다고 생각했습니다!

FSD 구조를 기반으로 모듈을 분리하고 위치시키면서 각 모듈에 대한 기능, 역할에 대해 더 얇은 레이어로(?) 디테일하게 생각해볼 수 있었던 것 같습니다. 기존 모듈 역할 단위로만 나누던 폴더 구조에서는 모듈의 분류에 대해 깊이 생각하지 않기 때문에 프로젝트가 커질 경우 모듈이 서로 뒤섞이게 되는 것 같습니다.

낙관적 업데이트를 제대로 구현하고 사용자 경험 개선 효과 직접 느껴보기

즉시 반응하는 UI의 쾌감

낙관적 업데이트를 적용하기 전에는 댓글을 추가하거나 좋아요를 누를 때마다 서버 응답을 기다려야 했습니다. 사용자 입장에서는 "내가 뭔가 했는데 반응이 없네?"라는 답답함이 있었어요.

하지만 낙관적 업데이트를 적용하고 나니 버튼을 누르는 순간 즉시 UI가 업데이트되면서 훨씬 반응성 있는 앱이 되었습니다. "아, 이래서 요즘 앱들이 이렇게 빠르게 느껴지는구나"라고 깨달았어요.

하지만 낙관적 업데이트를 구현하면서 예상보다 복잡한 부분이 많았습니다. 성공했을 때는 문제없지만, 실패했을 때 이전 상태로 롤백하는 로직이 생각보다 까다로웠어요.

본인이 과제를 하면서 가장 애쓰려고 노력했던 부분은 무엇인가요?

FSD 아키텍처의 완벽한 이해와 적용

타입 안전성을 보장하는 낙관적 업데이트 시스템

개발자 경험을 향상시키는 도구와 설정

1. FSD 아키텍처의 완벽한 이해와 적용

각 레이어의 역할 명확히 정의하기
FSD를 단순히 폴더 구조로만 이해하지 않고, 각 레이어가 왜 존재하는지, 어떤 책임을 가져야 하는지 깊이 고민했습니다.

엔티티에 서버 관련 코드 모아놓기

post
- index.ts
- post.api.ts
- post.constant.ts
- post.model.ts
- post.queries.ts
- post-type.ts

이런 식으로 같은 엔티티 기반으로 파일명을 가독성이 높게 파일명을 작성하려고 했습니다. 가독성 뿐만 아니라 엔티티 하위에 다중 폴더 구조가 되지 않게 관련 코드끼리 모아뒀습니다.

index.ts로 공개 API를 슬라이스 단위에서만 명시적으로 사용

import 할 때 어느 슬라이스에 포함되는 모듈인지 명시적으로 확인할 수 있도록 layer 최상단에서는 index.ts로 노출시키지 않고 각 slice에서만 index.ts로 export 했습니다.

// 지양
from '@/shared'

// 지향
from '@/shared/ui'

2. 제네릭을 활용한 타입 안전성

타입 정의 시 타입을 통해 데이터의 구조나 기능이 상상이 가능할 수 있도록 실제 기능과 구조를 잘 표현하기 위해 노력했습니다.

예를들어, 사용자 목록 조회 시 'select' 파라미터를 통해 사용자 모델의 속성을 선택할 수 있게 되어있습니다. 이 기능을 온전히 타입에 표현되도록 제네릭 타입을 사용하여 표현했습니다.

// 동적으로 User 속성을 선택할 수 있는 제네릭 타입
export interface GetUsersParams<K extends keyof User> {
  limit: number;
  select: K[];
}

// 제네릭 함수로 타입 안전성 확보
export const getUsers = async <K extends keyof User>({
  limit,
  select,
}: GetUsersParams<K>): Promise<GetUsersResponse<UserPick<K>>> => {
  // ...
};

// UserPick 타입으로 선택된 속성만 포함하는 타입
export type UserPick<T extends keyof User> = Pick<User, T>;

API 응답에서 필요한 속성만 선택적으로 가져올 수 있도록 제네릭을 활용하고 타입 안정성을 보장하여 런타임 에러를 방지할 수 있었습니다.

유틸리티 타입을 사용하여 단순 타입(?) 형태로 표현하지 못하는 경우들을 표현할 수 있도록 했습니다.

// src/6_shared/types/utility.type.ts

export type Nullable<T> = T | null;
export type EmptyStringable<T> = T | '';

// 사용
export interface BaseFilterParams {
  limit: number;
  skip: number;
  sortBy?: EmptyStringable<SORT_BY>;
  sortOrder?: SortOrder;
}

export interface UIState {
  showAddDialog: boolean;
  showEditDialog: boolean;
  showAddCommentDialog: boolean;
  showEditCommentDialog: boolean;
  showPostDetailDialog: boolean;
  showUserModifyDialog: boolean;
  selectedPost: Nullable<Post>;
  selectedComment: Nullable<Comment>;
  selectedUser: Nullable<Partial<User>>;
}

명시적이고 의도가 명확하게 타입을 정의하려고 했고, 재사용 가능한 유틸리티 타입으로 일관성 있는 타입 시스템 구축하고자 했습니다.

3. 쿼리키 관리

export const QUERY_DOMAINS = {
  POSTS: 'posts',
  USERS: 'users',
  COMMENTS: 'comments',
  TAGS: 'tags',
} as const;

export const QUERY_OPERATIONS = {
  LIST: 'list',
  DETAIL: 'detail',
  INFINITE: 'infinite',
  SEARCH: 'search',
  COUNT: 'count',
} as const;

const postQueryKeys = {
  all: [QUERY_DOMAINS.POSTS] as const,

  lists: () => [QUERY_DOMAINS.POSTS, QUERY_OPERATIONS.LIST] as const,
  list: (params: Partial<AllFilterParams>) =>
    [...postQueryKeys.lists(), params] as const,
} as const;

Work in progress... 더 작성하겠습니다. 죄송합니다..

4. FSD 폴더 구조 사용을 위한 개발자 경험을 향상시키는 도구와 설정

FSD 폴더 구조에서는 Layer 계층이 분명하고 단방향 의존성을 지켜야하기 때문에 그 계층이 시각적으로 눈에 보여서 어느 폴더가 상위이고 하위인지 생각하는 시간을 줄이고자 했습니다.

FSD의 최상위 폴더, 즉 Layer의 상위 ~ 하위 계층은

app
pages
widgets
features
entities
shared

이런 순서로 구성이 되는데 만약 이 폴더를 그대로 만들게 되면 알파벳 순서로 정렬되기 때문에

app
entities  
features
pages
shared
widgets

이렇게 뒤섞여보이기 때문에 의존성 방향을 시각적으로 바로 확인하기가 어려웠습니다.

그래서 폴더 순서가 의존성 계층 순서와 일치하여 폴더 위치만 봐도 의존성 관게를 파악할 수 있도록 폴더명 앞에 순서를 붙였습니다.

1_app/
2_pages/
3_widgets/
4_features/
5_entities/
6_shared/

하지만 이 폴더명 그대로 import문에 지저분하게 노출하여 사용하고 싶진 않았습니다. 그래서 절대 경로 설정을 통해 import 문에서 숫자없이 Layer 명만 깔끔하게 노출하여 사용할 수 있게 했습니다. 그리고 절대 경로 입력시 각 레이어가 몇번 폴더인지 생각할 필요없이 바로 Layer명으로 자동 완성할 수 있기 때문에 개발 생산성을 높일 수 있었습니다

from '@/features/add-to-cart'
from '@/entities/post'
from '@/shared/ui'

이렇게 절대경로를 실제 숫자가 붙은 폴더명을 Layer명으로 alias하고 싶었습니다

그래서 절대 경로 설정은 아래와 같이 설정했습니다.

// vite.config.js

'@/app': path.resolve(__dirname, './src/1_app'),
'@/app/*': path.resolve(__dirname, './src/1_app/*'),
'@/pages': path.resolve(__dirname, './src/2_pages'),
'@/pages/*': path.resolve(__dirname, './src/2_pages/*'),
'@/widgets': path.resolve(__dirname, './src/3_widgets'),
'@/widgets/*': path.resolve(__dirname, './src/3_widgets/*'),
'@/features': path.resolve(__dirname, './src/4_features'),
'@/features/*': path.resolve(__dirname, './src/4_features/*'),
'@/entities': path.resolve(__dirname, './src/5_entities'),
'@/entities/*': path.resolve(__dirname, './src/5_entities/*'),
'@/shared': path.resolve(__dirname, './src/6_shared'),
'@/shared/*': path.resolve(__dirname, './src/6_shared/*'),
'@final_src': path.resolve(__dirname, './src/final_src'),
'@': path.resolve(__dirname, './src'),

처음에 가장 최상단 폴더에 대한 절대 경로 설정을 맨 위에 두었더니, 다른 모든 절대경로를 인식하지 못하는 문제가 있었습니다

문제가 발생한 설정

'@': path.resolve(__dirname, './src'),
'@/app': path.resolve(__dirname, './src/1_app'),
'@/app/*': path.resolve(__dirname, './src/1_app/*'),
'@/pages': path.resolve(__dirname, './src/2_pages'),
'@/pages/*': path.resolve(__dirname, './src/2_pages/*'),
'@/widgets': path.resolve(__dirname, './src/3_widgets'),
'@/widgets/*': path.resolve(__dirname, './src/3_widgets/*'),
// ...생략

이렇게 설정했을 때는

from '@/shared/ui'

이런 경로가 에러가 발생하게 됩니다!

'@': path.resolve(__dirname, './src'), 여기에서 먼저 걸러지기 때문에


from '@/6_shared/ui'

‘@’ 하위의 정확한 폴더명을 적어줘야 정상적으로 작동하게 됩니다.

그래서 alias되는 절대 경로를 우선 처리하고 나머지 절대 경로를 인식할 수 있도록 ‘@’를 최하단에 두었더니 모든 절대 경로가 정상적으로 동작했습니다!!

아직은 막연하다거나 더 고민이 필요한 부분을 적어주세요.

FSD 레이어 간 경계가 모호한 경우의 판단 기준
대규모 프로젝트에서의 FSD 확장성
복잡한 비즈니스 로직에서의 낙관적 업데이트 전략

이번에 배운 내용을 통해 앞으로 개발에 어떻게 적용해보고 싶은지 적어주세요.

실무 프로젝트에 FSD 아키텍처 도입 검토
TanStack Query를 활용한 서버 상태 관리 개선
타입 안전성을 고려한 API 설계 및 구현

챕터 셀프회고

클린코드와 아키텍처 챕터 함께 하느라 고생 많으셨습니다!
지난 3주간의 여정을 돌이켜 볼 수 있도록 준비해보았습니다.
아래에 적힌 질문들은 추억(?)을 회상할 수 있도록 도와주려고 만든 질문이며, 꼭 질문에 대한 대답이 아니어도 좋으니 내가 느꼈던 인사이트들을 자유롭게 적어주세요.

클린코드: 읽기 좋고 유지보수하기 좋은 코드 만들기

더티코드를 접했을 때 어떤 기분이었나요? ^^; 클린코드의 중요성, 읽기 좋은 코드란 무엇인지, 유지보수하기 쉬운 코드란 무엇인지에 대한 생각을 공유해주세요

결합도 낮추기: 디자인 패턴, 순수함수, 컴포넌트 분리, 전역상태 관리

거대한 단일 컴포넌트를 봤을 때의 느낌! 처음엔 막막했던 상태관리, 디자인 패턴이라는 말이 어렵게만 느껴졌던 시절, 순수함수로 분리하면서 "아하!"했던 순간, 컴포넌트가 독립적이 되어가는 과정에서의 깨달음을 들려주세요

응집도 높이기: 서버상태관리, 폴더 구조

"이 코드는 대체 어디에 둬야 하지?"라고 고민했던 시간, FSD를 적용해보면서의 느낌, 나만의 구조를 만들어가는 과정, TanStack Query로 서버 상태를 분리하면서 느낀 해방감(?)등을 공유해주세요

리뷰 받고 싶은 내용이나 궁금한 것에 대한 질문

질문 1: FSD 아키텍처에서 도메인 중심 슬라이스 설계의 적절성

FSD 아키텍처에서 도메인 중심의 슬라이스 사용이 적절한지, 그리고 현재 구조를 개선할 수 있는 더 나은 방법이 있는지 궁금합니다.

현재 src/final_src/4_features/post-management 경로에서 게시물 관련 기능들을 하나의 도메인 중심 슬라이스로 구성하고 있습니다.

현재 접근 방식의 배경:

게시물 기능을 CRUD 단위로 세분화하면 post-create, post-read, post-update, post-delete와 같은 개별 슬라이스들이 생성되는데, 각각이 너무 작은 단위가 되어 오히려 관리 복잡도가 증가할 수 있다고 판단했습니다. 그래서 현재는 post-management라는 도메인 중심의 상위 개념으로 묶어서 관리하고 있습니다.

검토하고 싶은 부분:

도메인 중심의 슬라이스 설계가 FSD 철학에 적합한지
기능별 세분화 vs 도메인별 통합 중 어떤 접근이 더 적절한지
현재 구조에서 발생할 수 있는 잠재적 문제점과 개선 방안

코드위치:
src/final_src/4_features/post-management

질문 2: 낙관적 업데이트의 선언적 모듈화 방안

낙관적 업데이트 로직을 선언적이고 재사용 가능한 형태로 추상화하여 코드 중복을 줄이고 유지보수성을 향상시키고 싶습니다.

문제 상황:
현재 React Query의 useMutation에서 낙관적 업데이트를 onMutate, onError, onSuccess 콜백들을 통해 명령형으로 구현하고 있습니다. 이로 인해 다음과 같은 문제들이 발생하고 있습니다:

구체적인 문제점:

각 뮤테이션(생성, 수정, 삭제)마다 유사한 낙관적 업데이트 패턴이 반복되고 있습니다.
queryClient.setQueryData 호출이 여러 파일에 분산되어 있어 일관성 있는 관리가 어렵습니다.
각 뮤테이션에서 에러 발생 시 롤백 로직을 독립적으로 구현하고 있어 에러 처리 전략이 파편화되어 있습니다.

코드위치:
src/final_src/5_entities/post/post.queries.ts 의 useCreatePostMutation (46번째 줄)

질문 3: 다중 쿼리 타입 환경에서의 캐시 동기화 전략

게시물에 변경사항(생성, 수정, 삭제)이 발생할 때, 현재 활성화된 쿼리 타입을 감지하여 해당하는 쿼리키로 캐시된 데이터에만 낙관적 업데이트를 수행하도록 구현했습니다. 이러한 방식이 적절한지, 더 나은 방법은 없는지 궁금합니다.

실무에서 이러한 상황이 발생했을 때 확장성, 유지보수성을 고려하여 세련되게 처리할 수 있는 방법이 없을까요?

현재 상황:
게시물 목록을 조회하는 방식이 세 가지 타입(기본 목록, 태그별 필터링, 검색어 기반)으로 나뉘어 있으며, 각각 다른 API 엔드포인트에서 데이터를 가져옵니다.

코드위치:

쿼리키 선택 : src/final_src/6_shared/lib/hooks/useCachedPostsQueryKey.ts
해당 훅을 사용하여 캐시 데이터 선택 : src/final_src/5_entities/post/post.queries.ts 의 useCreatePostMutation (51번째 줄에서 useCachedPostsQueryKey사용)

✨ 주요 변경사항: - FSD 아키텍처 원칙에 따른 레이어 구조 정리 - Features 레이어에 posts-list 분리 및 엔티티 간 의존성 제거 - PostWithAuthor 조합 타입을 Features 레이어로 이동 - Tag 엔티티 추가 및 관련 API/쿼리 구현 🔧 기술적 개선: - ESLint 설정을 Airbnb 스타일로 업그레이드 - Import 경로를 절대 경로로 정리 및 Public API 활용 - 타입 시스템 개선 및 중복 export 제거 - 빈 폴더 제거 및 파일 구조 정리

Hwirin-Kim · 2025-08-16T05:12:51Z

src/4_features/comment-management/hooks/useAddCommentForm.ts

+import { useState } from 'react';
+
+import { useCreateCommentMutation } from '@/entities/comment';
+import { useUIStore } from '@/shared/lib';


UI스토어를 보니 모달과 선택된 포스트 그리고 코멘트 등이 같이 존재하는데 이 부분은 각각의 스토어로 분리하면 더 깔끔했을것같아요..!
그렇게 분리하고 모달을 여는 기능훅을 만들고 주입해서 사용하는것도 좋은 방법같더라구요..! (물론 저도 그렇게 안함..)

Hwirin-Kim · 2025-08-16T05:15:36Z

src/4_features/comment-management/hooks/useEditCommentForm.ts

+  };
+
+  useEffect(() => {
+    setCommentBody(selectedComment?.body || '');


selectComment 함수를 이 훅에서 정의하고, 그 함수 내부에서 setCommentBody를 하게 하는건 혹시 어떻게 생각하시나요..? 저는 사이드는 최소화 해야한다는 생각에 그렇게 하긴했는데 은지님 의견이 궁금합니다..!

Hwirin-Kim · 2025-08-16T05:16:43Z

src/4_features/comment-management/ui/AddCommentFormDialog.tsx

+
+import { useAddCommentForm } from '../hooks/useAddCommentForm';
+
+export const AddCommentDialog = () => {


UI 컴포넌트를 어떻게 분리해야할지 막막했는데 이렇게 보니 뭔가 좀 느낌이 옵니다!!

Hwirin-Kim · 2025-08-16T05:22:08Z

src/4_features/filter-posts/hooks/useFilteredPosts.ts

+    ...[Object.values(filters)],
+  ]);
+
+  const postsWithAuthorBySearch = useMemo(() => {


재 계산 안되도록 메모 한거 너무좋아요.... 백엔드는 왜 조인 안해서 주냐고...

Hwirin-Kim · 2025-08-16T05:26:00Z

src/4_features/filter-posts/hooks/useFilteredPosts.ts

+    if (searchQuery && searchQuery.trim()) {
+      setPagination({
+        ...pagination,
+        total: postsBySearchData?.total ?? 0,


토탈은 페이지네이션 상태로 두지 않고, 파생값으로 둬도 될것같아요! 이 자체가 하나의 상태인데 다른 상태에 옮겨간 형태같습니다..!

Hwirin-Kim · 2025-08-16T05:28:22Z

src/4_features/filter-posts/hooks/useFilteredPosts.ts

+      ...pagination,
+      total: postsData?.total ?? 0,
+    });
+  }, [postsBySearchData, postsByTagData, postsData]);


이건 궁금증인데, searchQuery값이 의존성배열에 없으면 첫 번째 if문은 실행이 어떻게 되는거에요..?

이거슨 실수입니닷..

Hwirin-Kim · 2025-08-16T05:31:50Z

src/5_entities/post/post.queries.ts

+    },
+    onSuccess: (data, _, { previousPosts }) => {
+      // ! 성공 시 이전 데이터에 성공 데이터 추가
+      queryClient.setQueryData(cachedPostsQueryKey, (old: any) => {


이미 onMutate 에서 진행했던 사항을 똑같이 진행하는것 같아서 불필요해 보입니다!

CreatiCoding · 2025-08-16T06:21:16Z

final_src/6_shared/lib/store/UIStore.ts

+  return {
+    showAddDialog,
+    setShowAddDialog,
+    showEditDialog,
+    setShowEditDialog,
+    showAddCommentDialog,
+    setShowAddCommentDialog,
+    showEditCommentDialog,
+    setShowEditCommentDialog,
+    showPostDetailDialog,
+    setShowPostDetailDialog,
+    showUserModal,
+    setShowUserModal,
+    selectedPost,
+    setSelectedPost,
+    selectedComment,
+    setSelectedComment,
+    selectedUser,
+    setSelectedUser,
+  };


소소한 제안입니다, 인터페이스를 이렇게 제공하면 어떨까요?

const { addDialog } = useUIStore();
addDialog.isOpen;
addDialog.open();
addDialog.clpse();

CreatiCoding · 2025-08-16T06:22:26Z

final_src/6_shared/lib/utils/ui.util.tsx

@@ -0,0 +1,21 @@
+export const highlightText = (text: string, highlight: string) => {


이거 리액트 엘리먼트를 반환하는 함수인데 그냥 컴포넌트로 바꿔보는 건 어떨까요?

export const HighlightText = ({ text, highlight }: { text: string; highlight: string; }) => {

CreatiCoding · 2025-08-16T06:26:21Z

final_src/final_src/5_entities/post/post.api.ts

+export const createPost = async (newPost: Omit<Post, 'id'>): Promise<Post> => {
+  return ApiService.post<Post>('/posts/add', newPost);
+};


공통된 내용인데, ApiService.post 에 이미 제네릭으로 Post 가 반환 타입임을 적용했으므로 래핑한 함수에서는 굳이 명시하지 않아도 알 수 있을 것 같아서 간단하게 이렇게만 적어도 괜찮을 것 같아요!

Suggested change

export const createPost = async (newPost: Omit<Post, 'id'>): Promise<Post> => {

return ApiService.post<Post>('/posts/add', newPost);

};

export const createPost = async (newPost: Omit<Post, 'id'>) => {

return ApiService.post<Post>('/posts/add', newPost);

};

CreatiCoding

6주차 고생하셨습니다~! 🎉

angielxx added 30 commits August 12, 2025 02:47

docs: 과제 목표 설정

28c1e3f

chore: eslint, prettier 설정

76491a9

feat: 프로젝트 요구사항 분석 및 코드 분석

3c684b3

docs: 기존 코드 주석 설명 추가

86291d6

chore: 기본 최상위 폴더 생성

6200844

docs: FSD rules 작성

4127232

chore: FSD 아키텍처 적용, FSD 구조에 맞는 import문 정렬 설정

3b98b41

refactor: 일단 공통 UI 컴포넌트 분리만

e5ab3cc

chore: 절대 경로 설정 수정

c56a1cb

refactor: 매직 넘버 상수화

2553f4a

feat: tanstack query 설정

944778b

refactor: FSD 엔티티 폴더 구조 구성 및 게시물 조회, 사용자조회 API 작성

895e518

feat: useGetPostsWithAuthor 구현 및 queryKeys 구조 설계

ff5f870

docs: 서버상태관리 작업 문서 작성

41cc10f

chore: tanstack devtools 설정

bdbaaad

feat: 게시물 엔티티 관련 api, query 구현

67efd81

feat: 태그 관련 api, query 구현 및 태그 선택 UI 분리

a0f4cf4

feat: 게시물 삭제 mutation 적용

85a75a0

feat: 다이얼로그 공통화, 전역 상태 관리

09e1995

feat: 게시물 상세 보기 모달 구현

5fda36a

feat: 게시물 상세, 게시물 수정, 게시물 목록 분리

451a83b

feat: 댓글 추가 분리

7c05d76

feat: 댓글 수정 분리 및 낙관 업데이트 로직 수정

61637ce

feat: 사용자 모달 분리 및 select 필드에 맞게 사용자 타입 제네릭으로 정의

83d71c5

feat: 댓글 낙관적 업데이트 동작 수정

24cff50

refactor: shared는 slice에서 꺼내쓰도록, 게시물 목록 로딩 높이 limit에 따라 설정

4def1d1

feat: 필터 컴포넌트 그룹화 및 URL 파라미터 새로고침 시 유지

aa67aab

feat: 태그, 검색어 필터시 표시 갯수 및 페이지 파라미터 추가

2f7054a

feat: limit, skip에 따른 요청 및 페이지네이션 분리

d66facb

angielxx added 6 commits August 15, 2025 04:03

feat: 게시물 낙관 업데이트 쿼리키 저장하여 선별적 수행

85cd683

feat: fetch 함수를 모두 axios로 교체

59d8149

chore: gh-pages 설정

26f9c23

chore: 무한루프 에러 수정 및 배포 설정

94b4d95

feat: 최종 과제 final_src 생성 및 폴더 구조 수정

e0269e8

feat: 최종 폴더 구조

cb4e0c5

Hwirin-Kim reviewed Aug 16, 2025

View reviewed changes

CreatiCoding reviewed Aug 16, 2025

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[1팀 이은지] Chapter 2-3. 관심사 분리와 폴더구조#48

[1팀 이은지] Chapter 2-3. 관심사 분리와 폴더구조#48
angielxx wants to merge 36 commits intohanghae-plus:mainfrom
angielxx:main

angielxx commented Aug 14, 2025 •

edited

Loading

Uh oh!

Hwirin-Kim Aug 16, 2025

Uh oh!

Hwirin-Kim Aug 16, 2025

Uh oh!

Hwirin-Kim Aug 16, 2025

Uh oh!

Hwirin-Kim Aug 16, 2025

Uh oh!

Hwirin-Kim Aug 16, 2025

Uh oh!

Hwirin-Kim Aug 16, 2025

Uh oh!

angielxx Aug 16, 2025

Uh oh!

Hwirin-Kim Aug 16, 2025

Uh oh!

CreatiCoding Aug 16, 2025

Uh oh!

CreatiCoding Aug 16, 2025

Uh oh!

CreatiCoding Aug 16, 2025

Uh oh!

CreatiCoding left a comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants


		import { useAddCommentForm } from '../hooks/useAddCommentForm';

		export const AddCommentDialog = () => {

		@@ -0,0 +1,21 @@
		export const highlightText = (text: string, highlight: string) => {

Conversation

angielxx commented Aug 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

배포 링크

과제 체크포인트

기본과제

목표 : 전역상태관리를 이용한 적절한 분리와 계층에 대한 이해를 통한 FSD 폴더 구조 적용하기

체크포인트

심화과제

목표: 서버상태관리 도구인 TanStack Query를 이용하여 비동기코드를 선언적인 함수형 프로그래밍으로 작성하기

체크포인트

최종과제

과제 셀프회고

이번 과제를 통해 이전에 비해 새롭게 알게 된 점이 있다면 적어주세요.

본인이 과제를 하면서 가장 애쓰려고 노력했던 부분은 무엇인가요?

아직은 막연하다거나 더 고민이 필요한 부분을 적어주세요.

이번에 배운 내용을 통해 앞으로 개발에 어떻게 적용해보고 싶은지 적어주세요.

챕터 셀프회고

클린코드: 읽기 좋고 유지보수하기 좋은 코드 만들기

결합도 낮추기: 디자인 패턴, 순수함수, 컴포넌트 분리, 전역상태 관리

응집도 높이기: 서버상태관리, 폴더 구조

리뷰 받고 싶은 내용이나 궁금한 것에 대한 질문

질문 1: FSD 아키텍처에서 도메인 중심 슬라이스 설계의 적절성

질문 2: 낙관적 업데이트의 선언적 모듈화 방안

질문 3: 다중 쿼리 타입 환경에서의 캐시 동기화 전략

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

CreatiCoding left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

angielxx commented Aug 14, 2025 •

edited

Loading