webpack의 버전이 나날이 높아질수록, webpack 자체 라이브러리가 기본적으로 제공하는 기능이 추가되고 있다. minimize등이 대표적이다. 나는 번들할때마다 번들폴더를 비워주는 CleanWebpackPlugin을 사용하고 있었는데, 다른 크루가 output의 clean: true로 기본 제공을 해주고 있었다고 한다. 그래서 깔끔하게 제거했다! 해당커밋: chore: CleanWebpackPlugin 제거 (webpack5 내장)

javascript에는 이미 구현된 API 객체가 많다. 쿼리 스트링을 담당하는 URLSearchParams가 있을 것이고, 주소를 다루는 URL이 있을 것이고, 데이터를 다루는 Date도 있을 것이다. 또한, iframe간의 통신을 다루는 MessageChannelAPI도 있을것이다. 이미 존재하는 API객체를 사용하면 장점이 있다. 1. 해당 역할을 온전히 API객체에 위임하여 제한할 수 있다. 예를들어서, 쿼리스트링은 다음과 같은 하드코딩으로 직접 구현할 수 있다. `/index.html?$projectKey={projectKey}` 하지만, 이러한 하드코딩 방식은 복잡해질수록 휴먼에러를 발생시킬 확률이 높다. 이미존재하는 URLSearchParamsAPI를 사용하면 다음과 같은 구조가 된다. co..

조건문이 많아지면, 코드의 가독성이 나빠지는 것은 많이 느껴보았을 것이다. switch같은 구문도 있지만, if문과 큰 차이가 없다고 생각한다. 나는 모든 if문을 Object Literal로 바꿀 수 있다고 생각한다. Object Literal로 바꾸게되면 장점이 있다. 1. 바로 조건검사 로직을 특정 객체에 위임할 수 있는 것이다. 결이 같은 로직을 특정 객체가 담당하므로써, 유지보수와 디버깅 시에 원인을 빠르게 특정하고 개선할 수 있다. 더불어 가독성도 개선된다. 2. 코드의 길이가 줄어든다. 지금까지는 새로운 조건이 추가될때마다 if문과 === 또는 !== 로직을 반복해서 써주어야했다면, 이제는 객체의 Property만 1개더 추가해주면 된다. 즉, 변경엔 닫혀있고 확장엔 열리는 OCP원칙을 만족..

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..

테스트 코드를 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