z-index를 사용하면 요소들의 쌓임처리를 하는것이 유용하다. 마치 치트키처럼 느껴질 때가 있다. 다른 사람들이 z-index를 지양하는게 좋다고 했어도, 애니매이션을 주려고 혹은 직관적으로 쌓임맥락을 확인할 수 있어서 사용했다. 그러나, z-index의 예상치 못한 동작은 나에게 유지보수의 어려움을 한층 더해주었다. 일단 z-index가 아무리 낮아도 position: relative를 가진 엘리먼트는, z-index: 100이고 position: relative속성이 없는 요소보다 상위에 노출된다. 나는 position: fixed인 엘리먼트 뒤로 위치하게 의도했는데, 전혀 다른 동작이 나타난것이다. 처음에는 봐줄만했으나, 이러한 요소가 많아질수록 z-index를 상수로 관리하여도 코드가 더러워지는..

페이지가 많아질수록, App.tsx에서 Routing을 하고 있는 숫자로 많아진다. 결과적으로 아래와 같은 아주 긴, 컴포넌트가 만들어지게 된다. } /> 지금까지 간과하고 있었는데, 같은 로직이 중복되는 코드가 너무 많음을 알 수 있다. 유지보수가 쉬운 코드를 위하여 공통된 로직을 추상화했다. , , } /> {nonAuthorizedRoute.map(({ path, component, redirectPath }) => { return ; })} {authorizedRoute.map(({ path, component }) => { return ; })} 권한이 필요한 Path와 권한이 필요없는 Path를 상수화하여, render로직에서는 map으로 순회만하는 코드로 바꾸었다. 이렇게 하니, 훨씬 가독성..

다라쓰는 총 2개의 프로젝트로 이루어져있다. 그렇다고 각 2개의 프로젝트 규모가 작은것도 아니다. 이제 프론트엔드의 많은 부분을 혼자서 작업하게 되었는데, 막막하기 보단 더욱 열심히 해야겠다는 느낌이 들었다. 그 느낌중 하나는, 테스트 코드를 한번 완벽하게 짜보자는 것이었고, 그에 따른 나의 목표는 다음 데모데이인 10/27까지 내가 무조건 가져가고자 하는 바는, 2개의 프로젝트 모두의 test coverage를 70%이상으로 만들어놓는것이다. 오늘은 2개의 컴포넌트에 대해 test code를 작성했다. https://github.com/woowacourse-teams/2021-darass/commit/148712acb98dfdbb3930a97996acfeac34342906 https://github.c..

- jest를 선택한 이유 통합테스트는 단위테스트와 e2e테스트의 중간의 테스트 기법임. 그렇기에 통합테스트를 한다는 것은, 단위테스트와 e2e테스트의 장점을 동시에 가져갈 수 있으므로 가성비가 좋은 테스트라고 할 수 있기에 jest를 이용해서 사용. - jest에서 cypress로 바꿔보려고 결심한 이유 페이지 단위로 나누어 핵심 기능들을 테스트했고, 해당 테스트를 위해서는 매번 use~~로 시작하는 api를 비동기 요청하고 있는 커스텀훅들을 모킹해주어야 했고, 로직이 크게 변경되면 테스트 코드를 여러군데 많이 손보아야 했음. 이렇다보니 테스트코드가 정말 버그를 잡는 용도로서의 기능보다, 테스트 코드가 작성되있는 프로젝트야~ 라는 느낌의 테스트코드만 작성하게됨. 테스트가 유의미하다고 느껴지지 않을 정도..

테스트 코드를 cypress 로 작성하기로 결심 https://github.com/woowacourse-teams/2021-darass/issues/588

1. 훅 디렉토리 구조변경 https://github.com/woowacourse-teams/2021-darass/pull/579 2. path aliasing 적용 https://github.com/woowacourse-teams/2021-darass/pull/581

밤새서 미션을 하고 씻는 도중 현재 채택하고 있는 git flow전략에서 머지 방법을 바꿔보자는 의견이 있었다. "feature -> dev는 sqush and merge, dev -> main은 rebase and merge로" 원래는 둘다 스쿼시 머지를 하고 있었는데, 현재 전략을 수정함으로써 얻을 수 있는 이점을 샤워끝나자마자 정리한다. 역시 우테코는 학습하기에 정말 좋은 환경이다 👍 아무튼 내가 전략 수정에 찬성하게된 이유는 다음과 같다. 첫번째 이유로는 git flow 전략은 짧은 배포 주기가 특징인데, dev -> main에서 굳이 커밋을 한번더 생성할 이유가 없다는 것이었고, 두번째 이유로는 짧은 배포 주기때문에 hoxfix나 롤백에 굉장히 유연해야 하는데, dev, main 브랜치의 커밋내..

프로젝트가 복잡해질수록, import 경로가 복잡해지는 경우가 있다. import "../../../../../../component/App"; 이렇게 되면, 제 3자가 봤을때 폴더의 구조를 파악하기도 힘들 뿐더러, ../ 문에 오타가 있을시에 수동으로 찾아나가는 수 밖에 없다. 그래서 필요한 것이 path aliasing이다. path aliasing은 특정 경로에 이름을 부여하여 그것을 path로 사용할 수 있다. 예를들어서, "@"를 "/src" 으로 지정해줄 수 있고, 갯수나 유형은 마음대로 가능하다. 그럼 이렇게 만들 수 있을 것이다. import "@/component/App"; 이제한번 "@"를 "/src"로 path alias 해보는 실습을 해보자. 1. webpack 설정 webpack...