나는 그동안 재사용 가능한 공용 컴포넌트를 만들었나? 코드스쿼드에서 했던 프로젝트를 곰곰히 생각해보면 내가 어떤 컴포넌트를 과연 재사용했는가?에 대한 대답은 NO 였다. 물론 내 기준에 적절한 크기로 컴포넌트를 분리는 했지만 과연 공용 컴포넌트 폴더에 넣어둔 공용 컴포넌트가 정말 공용이었을까? 어떻게 하면 컴포넌트를 재사용 가능하게 사용할 수 있을까? 이 글이 정말 큰 도움을 줬다. 코드스쿼드를 다닐 때도 읽었던 글인데, 그 당시엔 전혀 공감되지 않았다. 코드스쿼드 수료 후에 리액트를 다시 공부하고 읽어보니 이제는 조금 이해했다. 아직 그 행간을 모두 이해하지는 못했지만 컴포넌트를 나누는 나만의 기준을 세우는데 가장 큰 도움을 준 글이다. 도메인과 분리된 공용 컴포넌트 1) 이슈 목록을 표시하기 위한 테..

dev mode 에선 어떤 것이 중요할까? 웹팩의 dev mode에 대해 먼저 말해보고자 한다. 어떤 점을 가장 중요시 해야할까? 바로 빌드 시간일것이다. production mode는 번들 사이즈의 최소화가 가장 중요한 점이지만, dev mode에선 번들 사이즈를 최소화하기 위해 여러 로더를 넣어 빌드 시간을 증가시키는 일을 줄여야 한다. 다음과 같이 dev mode를 설정했다. const path = require('path'); const HtmlWebpackPlugin = require('html-webpack-plugin'); const Dotenv = require('dotenv-webpack'); const ReactRefreshWebpackPlugin = require('@pmmmwh/re..

실제 코드를 예제로 사용하려다, 정리하고자 했던 개념들에 오히려 혼돈만 주는 것 같아 예제를 각색했습니다. Type vs Interface Typescript 문서나 Type과 Interface를 비교한 글을 봐도 개인 기호나 팀 컨벤션을 따를 뿐 명확한 기준점은 찾지 못했다. 하지만 Effective Typescript에서 내 기준으론 가장 정답에 가까운 기준을 보게 됐는데, 바로 declaration merging 이다. interface IState { name: string; capital: string; } interface IState { population: number; } const wyoming: IState = { name: 'Wyoming', capital: 'Cheyenne', p..

어떤 관심사들이 있을까? 프로그램에는 다음과 같은 관심사들이 보통 존재한다. 1. 뷰를 그리기 위한 렌더링 로직 2. 비즈니스 로직 3. 네트워크 요청 이런 관심사에 따라 크게 세가지 레이어로 나누었다. 1. Domain layer: Entity, Repository Interface, Use Case 2. Data layer: Repository Impl, Data Source 3. Presentation layer: 리액트 코드 Domain layer 도메인 레이어에는 엔티티가 존재했다. 추구했던 방향은 Class로 entity를 나타내고 해당 entity에서 수행해야 하는 비즈니스 로직을 메서드로 표현하고 싶었다. 하지만 2가지 문제점이 있었다. 1. 앱 자체가 어찌보면 단순한 CRUD 앱이었기 때..

아키텍쳐 코드스쿼드에서 팀 프로젝트를 진행하면서 처음 사용했던 리액트. 팀 프로젝트 당시엔 데모도 해야하고 백엔드가 제공해준 API를 화면에 그리지 못하면 민폐라 생각해 마구잡이로 컴포넌트를 짜고 어떻게든 화면만 그렸었다. 하지만 항상 마음 속에 무언가 찜찜함이 있었다. 이렇게 지저분한 코드로 어떻게든 화면만 그려내는건 내가 원했던 개발자로서의 모습이 아니었다. 리액트를 처음 배운다는, 팀원들에게 화면을 보여줘야 한다는 핑계 뒤에 숨어 마구잡이로 컴포넌트를 짜고 있다가 문득 이런 생각이 들었다. 지금 내가 하는 프로젝트가 그렇게 큰 프로젝트도 아닌 것 같은데, 만약 회사에서 더 큰 프로젝트를 만들 때 내가 수많은 수정사항들을 다 처리할 수 있을까? 주어진 피그마대로 화면을 그리는건 쉽다. 하지만 내가 걱..

useQuery의 반환값들 크게 두 범주로 생각할 수 있는데, 캐쉬된 데이터의 상태와 데이터 페칭에 대한 상태로 생각하면 쉽다. 데이터에 대한 상태값 - status === ‘pending’ 쿼리에 데이터가 없을 경우 isPending - status === 'error' 쿼리에 오류가 생긴 경우 isError - status === 'success' 쿼리가 성공적이었고 데이터가 사용 가능한 경우 isSuccess 페칭 상태에 대한 값 - fetchStatus === 'fetching' - 쿼리가 페칭 중일때 - fetchStatus === 'paused' - 쿼리는 페치를 하고 싶지만, 일시중지 됐을때. - fetchStatus === '..