처음 프로젝트를 시작했을 때, 디자인 패턴, 파일구조와 같은 추상적인 개념과 d이것들에 대한 중요성을 전혀 몰랐다. 프로젝트에 몇 가지 새로운 기능 구현을 요청될때마다 디자인 패턴, 파일구조 등을 전혀 고려하지 않은 구조때문에, 작은 기능 하나가 어플리케이션 전체에 큰 이슈를 불러 일으켰다. 더 많은 기능 구현을 하며 코드를 재작성하는 일이 두 번 더 반복되었고, 요구될때 마다 변경하는 것이 두려워지기 시작했다. 코드리팩토링이 필요하다!

왜 디자인 패턴을 사용할까

• 앱의 규모가 커지면서, 코드를 관리하고 유지보수 하기 힘들다.
• 설계된 컴포넌트들이 변화하는 일(망가지는)이 많다.

주의사항

여러가지 패턴들이 있지만, 무작정 적용하기보다 풀고자 하는 문제와 맞는 경우에만 사용하는 것이 좋다. 대신 아래와 같은 규칙은 적용하는 것이 좋다.
1. DRY (Don’t Repeat Yourself)를 유지한다.
2. 컴포넌트를 작게 쪼개고, 재사용 가능한 컴포넌트를 만들어라.
3. '단일책임'원칙에 초점을 맞춰라. 컴포넌트가 무엇을 하는지 명확하게 이해할 수 있다.

그래서, 생각해본 개선할 점

• 설계우선접근법을 따르자.
• 컴포넌트 구성에 대한 예제
• ES6로 명확하게 표현하기
  - 언제 사용하면 좋을까
  • 재사용성이 굉장히 높은 컴포넌트
  • state가 없을 경우
• 컴포넌트의 역할을 특수화 해서 보다 명확한 컴포넌트로 만든다.

  {this.props.theme === RED ? <RedButton> : <BlueButton>}

• Presentational & Container 컴포넌트
  - 🙄Presentational 컴포넌트
  + JSX를 이용한 마크업이 존재합니다.
  + render에 필요한 데이터는 이미 존재한다고 가정합니다.
  + UI를 위한 state가 존재할 수 있습니다.
  - 🙄Container 컴포넌트
  + JSX를 이용한 마크업이 거의 없습니다.
  + Ajax 요청, HOC 등을 이용해 render에 필요한 데이터를 Fetching 합니다.
  + 데이터 Fetching 등을 위한 state가 존재할 수 있습니다.
• 대중화된 고차 컴포넌트 (Higher Order Component)