- 조건문들을 전략패턴으로 변경 - 조건 추가될 때마다 === 등 구현부를 수정하게되어 변경이 어렵거나 사이드이펙트 발생 가능성 있음. (물론 간단한 코드는 상관없음) - 코드 가독성이 높지 않다고 생각이 듬 - 전략 패턴을 사용하면 구현부 수정없이 전략만 추가하면 되니 코드가 변경에 용이 - 여기 코드는 캡슐화 되어있어서 크게 상관없지만 외부에서 호출되는 케이스일 경우 전략패턴 장점이 극대화됨. 호출부에서 전략을 호출하기 때문에 구현부를 보지 않더라도 전략 네이밍만 보고 동작 유추가능. - Location: 스트링 리터럴 타입 or enum 적극 사용. TS 이점을 누리자. - UI와 데이터가 강하게 연결되어있음 - 데이터를 DB처럼 활용하자
context API
- 데이터와 UI가 잘 분리된 것 같다.
- 굳이 아쉬운 점은 ViewNavigationContext에 페이지 세팅과 UI 상태인 transition이 강하게 결합되어 있는 것
- 사이즈가 크지 않거나 가볍게 구현할 때는 이 방향도 맞다. 하지만 저라면 SRP에 따라 transition과 데이터를 분리했을 것.
- 컨텍스트가 2개 있던가 혹은 transition은 사용하는 곳에서 useState 혹은 hook으로 다뤘을 듯
- 컴포넌트가 재사용성이 고려되었나 잘 분리되었나 이런 공통 질문들
- 이걸 판단하려면 명확한 도메인과 서비스가 있어야 판단 가능.
- 지금은 그냥 서비스 목적 없이 과제용으로 페이지 네비게이션 기능을 만드는 페이지임
- 그래서 컴포넌트는 가장 낮은 책임을 가진 Button, Link, header, Menu, Icon 혹은 List 정도 였을 것 같다.
컴포넌트
- 재사용성과 변경에 유연한 코드
- 데이터와 UI의 분리
- Ex
- Input은 키보드를 통한 텍스트 입출력을 선언적으로 추상화한 모습
- 이 작은 컴포넌트부터 다양한 요소들을 적절한 단위로 나누고 추상화 해야함.