min

오늘은 Todo-List를 만들면서 겪었던 트러블 슈팅에 대해서 정리하려고 한다. 트러블 슈팅은 신입 개발자로써 성장할 수 있는 아주 좋은 양분이다. 즉 신입 개발자에게 트러블 슈팅이란 우리가 일상적으로 먹는 밥 같은 존재다. 맨날 마주치면서 우리를 성장시켜주는 촉진재인 셈이다. 그래서 오늘은 겪어던 트러블 슈팅들에 대해서 적어볼려고 한다. 1. 문제상황 헤더 영역는 크게 2가지로 나뉜다. 제목 영역 , 설명 영역 이렇게 2가지로 나뉜다. 여기서 문제는 설명영역에서 에니매이션 처리를 했는데 이 에니매이션 처리가 제목 영역까지 영향을 미친다는 것이다. 원인을 분석해보니 헤더의 제목 , 설명 영역을 감싸는 부모 영역이 있다면 이 부모영역에서 상태를 관리하고 있었고 이로 인해서 제목 , 설명 영역 모두가 영향..

오늘은 Todo-List를 만들면서 겪었던 트러블 슈팅에 대해서 정리하려고 한다. 트러블 슈팅은 신입 개발자로써 성장할 수 있는 아주 좋은 양분이다. 즉 신입 개발자에게 트러블 슈팅이란 우리가 일상적으로 먹는 밥 같은 존재다. 맨날 마주치면서 우리를 성장시켜주는 촉진재인 셈이다. 그래서 오늘은 겪어던 트러블 슈팅들에 대해서 적어볼려고 한다. 1. 문제상황 헤더 영역에서 캘린더가 있고 이 캘린더를 눌렀을 때 에니매이션 처리와 함께 그 캘린더에서의 To-Do가 보이는 로직을 구현해야 함 헤더 영역과 TodoList 영역은 별개의 영역으로 따지자면 형재 관계의 컴포넌트이다. 2. 해결방법 헤더 영역에 상태를 종속시키는 순간 나는 TodoList와 해당 상태를 공유할 수 없게 된다. 즉 전역적으로 상태를 관리해..

오늘은 Todo-List를 만들면서 겪었던 트러블 슈팅에 대해서 정리하려고 한다. 트러블 슈팅은 신입 개발자로써 성장할 수 있는 아주 좋은 양분이다. 즉 신입 개발자에게 트러블 슈팅이란 우리가 일상적으로 먹는 밥 같은 존재다. 맨날 마주치면서 우리를 성장시켜주는 촉진재인 셈이다. 그래서 오늘은 겪어던 트러블 슈팅들에 대해서 적어볼려고 한다. 1. 문제 상황 내가 만들려고 하는 드롭박스의 컴포넌트 분리를 어떻게 해야지 나중에 확장을 고려했을 때 확장성을 맞출 수 있는 구조로 설계할 지에 대한 고민이 있었음 2. 해결방법 토스에서 컴포넌트 분리와 관련된 영상이 있어서 그 영상을 참고함. 대체적으로 컴포넌트를 분리할 때는 그 컴포넌트가 하나의 역할을 담당할 수 있도록 만듦. 즉 단일 책임의 원칙에 따라서 하나..

오늘은 Todo-List를 만들면서 겪었던 트러블 슈팅에 대해서 정리하려고 한다. 트러블 슈팅은 신입 개발자로써 성장할 수 있는 아주 좋은 양분이다. 즉 신입 개발자에게 트러블 슈팅이란 우리가 일상적으로 먹는 밥 같은 존재다. 맨날 마주치면서 우리를 성장시켜주는 촉진재인 셈이다. 그래서 오늘은 겪어던 트러블 슈팅들에 대해서 적어볼려고 한다. 1. 문제상황 컴포넌트 분리는 사실 정답이라고 하는 것은 없다. 하지만 나중에 프로젝트가 커졌을 때 확장성에 유연한 프로젝트가 되는 지, 확장성에 유연하지 못한 프로젝트가 되는 지는 컴포넌트 분리가 결정한다. 내가 만들려고 하는 헤더의 영역을 캘린더 까지를 헤더로 볼 것인지 , 아님 제목 영역 까지로 봐야할 것인지에 대한 설계에서의 문제가 발생함 2. 해결 방법 문제..

1. To-Do-List를 기획한 이유 제작 이유 : 현재 취업 시장에서 가장 많이 하는 오해가 새로운 기술을 많이 접해보는 것임. 나는 이점을 역을 공략해 기본적인 기술들을 쓰면서 기술적 의사결정과 최적화에 포커스를 맞출려고 함 기술적 의사 결정의 필요성 : 기술적 의사 결정은 면접에서 필수 질문임 내가 쓴 기술에 이유를 모른다는 것은 결국 그 기술의 장단점을 모르는 것과 같음 최적화의 필요성 : 최적화는 유저의 만족도를 위해서 꼭 필요한 부분임 아무리 UI가 예쁘고 들어가는 기술이 많다고 해도 정작 성능이 안 좋으면 사용하는 유저는 없을 수 밖에 없음 2. 기술적 의사결정 React-Query 서버 사이드 데이터만 다루기에 규격화 문제를 해결함 데이터를 cache , prefetch , stale등 ..