min

Todo List를 context api를 통해서 만들어 보자는 생각이 들었다. 그럼 여기서 이런 의문이 들 수 있다. 왜 컨텍스트 api를 이용해서 만들었는가? redux라는 라이브러리도 많은데 context api를 고른 이유는 무엇인가? 이유는 다음과 같다. redux의 경우 생각보다 굉장히 무거운 라이브러리 이다. redux의 장점은 버그나 로그 관리등 부가적으로 할 수 있는 것들이 많다는 점이다. 하지만 그만큼 무겁고 redux를 사용하기에는 환경 세팅이 정말 어렵다는 점이다. 근데 이번에 내가 만든 todo list는 사실 그렇게 무거운 프로그램이 아니다. 따라서 redux를 사용하기에는 적합하지 않는 환경이라고 생각했다. 그래서 나는 redux보다 상태관리를 하는데 좀더 가벼운 context..

오늘은 Todo-List를 만들면서 겪었던 트러블 슈팅에 대해서 정리하려고 한다. 트러블 슈팅은 신입 개발자로써 성장할 수 있는 아주 좋은 양분이다. 즉 신입 개발자에게 트러블 슈팅이란 우리가 일상적으로 먹는 밥 같은 존재다. 맨날 마주치면서 우리를 성장시켜주는 촉진재인 셈이다. 그래서 오늘은 겪어던 트러블 슈팅들에 대해서 적어볼려고 한다. 1. 문제 상황 작성 페이지에서 제목과 관련된 인풋 박스를 수정했는데 결과적으로는 모든 InputBox와 Select박스들이 바뀌는 현상을 목격할 수 있었음 원인을 분석해보니 props로 넘기는 함수에서 문제가 발생함 함수의 경우 참조 타입으로 안에 내용이 갔다고 해도 메모리에 똑같은 함수가 올라갔을 경우, 이는 shallow equerl 테스트에서 다른 부분으로 판..

오늘은 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등 ..

오늘은 프로젝트를 시작하는 주만큼 내가 처음에 준비해야 할 것들이 많았다. 그래서 나는 오늘 내가 협업을 하면서 주관적으로 내가 필요했다고 느껴졌던 부분들에 대해서 설명을 하려고 한다. 1. 코드 컨밴션 코드 컨밴션은 협업을 하는 데 있어서 내가 가장 중요하다고 생각했다. 우리는 프로그래머다. 프로그래머는 코드를 읽고 , 코드를 작성하기 위해서 생각하는 사람이다. 즉 코드와 아주 밀접한 관계가 있는 사람이다. 근데 만약에 다른 사람과 협업을 할 때 서로의 변수명이 다 다르다면 어떨 것인가? 만약 개발자가 코드를 읽기 어렵다면 어떨 것인가? 이는 엄청난 비용과 유지보수의 힘든 점들을 가져올 것이다. 즉 변수명 하나로 인해서 이렇게 까지 큰 스노우 볼이 굴러올 수 있다. 그래서 우리는 사전에 변수명 , 파일..