일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | ||||
4 | 5 | 6 | 7 | 8 | 9 | 10 |
11 | 12 | 13 | 14 | 15 | 16 | 17 |
18 | 19 | 20 | 21 | 22 | 23 | 24 |
25 | 26 | 27 | 28 | 29 | 30 | 31 |
- poiemaweb
- 자바
- 자바스크립트
- 오블완
- 수학
- 자료 구조
- 브루트포스
- 모던 자바스크립트 튜토리얼
- styled-components
- HTML5
- 토이 프로젝트
- 구현
- 티스토리챌린지
- js
- 프론트엔드
- JavaScript
- State
- 개발 회고
- 시뮬레이션
- 회고
- 코딩일기
- 기본 문법
- Next.js
- 백준
- 해시를 사용한 집합과 맵
- 엔트리포인트
- three.js
- REACT
- 세그먼트 트리
- react-three/fiber
- Today
- Total
코딩하는 고릴라
[FE/Refactor] if-else 문 lookup table 패턴으로 리팩토링 본문
⏰ WHY
로그인 여부에 따라 페이지 접근 시 라우팅 할 LoginGuard 컴포넌트 내에서 if - else 문을 활용해 코드를 작성했었습니다.
이는 가독성 측면에서 좋아보이지 않아 최근에 학습한 lookup table 패턴으로 보다 유지보수가 용이한 코드로의 리팩토링을 시도해보았습니다.
🦍 WHAT
Lookup table?
- 객체 내에 조건을 key로, 실행시켜야 할 함수를 value로 하여 if문 순회 없이 조건에 부합했을 때의 함수를 O(1)에 실행시킬 수 있도록 하는 디자인 패턴
초기 코드
먼저 lookup table 패턴과는 무관하지만 배열 형태로 되어 있는 loginLimitPath 를 set 형태로 변환해 경로를 체크하는 로직의 시간 복잡도를 O(n) 에서 O(1)로 줄였습니다.
다음으로는 useEffect 내에서 사용한 if문의 실행문을 각각 truthyAction과 falsyAction 함수로 분리하였습니다.
마지막으로, useEffect 내에 있는 if문을 대체하기 위해 checkLoginMap이라는 객체를 생성하여 조건에 따라 부합하는 함수를 실행할 수 있도록 수정했습니다. 결과적으로 if문을 순차적으로 검사하지 않고, 객체에서 즉각적으로 조건에 부합하는 함수를 찾아 실행함으로써 시간 복잡도를 O(n)에서 O(1)로 개선했습니다.
최종 코드
if문으로 관리하던 작업을 함수로 분리하여 가독성과 유지보수 측면에서 더 나은 코드가 된 것 같습니다. 또한, 위에서부터 순차적으로 조건을 검사하는 if문과 달리, 객체의 key 값을 찾아 즉각적으로 함수를 실행할 수 있어 속도 면에서도 개선이 가능했습니다.
물론, 현재 조건 분기가 2개밖에 없어서 실제 성능 차이는 거의 없겠지만, 조건 분기가 많은 작업이나 코드의 양이 많아졌을 때는 더 큰 이점을 가질 수 있는 패턴인 것 같습니다.
'Project > Bridgetalk' 카테고리의 다른 글
[FE] 렉시컬 환경, 클로저를 활용한 기능 구현 (0) | 2024.05.05 |
---|---|
[FE] Props를 활용한 Styled-components 트러블 슈팅 (0) | 2024.05.05 |