React의 역사

업데이트때문에 리액트는 등장한다. 즉각적으로 웹페이지가 사용자와 상호작용해야 했는데, 이를 대규모로 수행하기는 어려웠던 초창기 애플리케이션

1. 성능
   • 하나를 업데이트하면 Reflow가 전체가 다시 다 됨. 이를 반복적으로 수행하게 되면 브라우저에 대한 오버헤드와 성능 병목 발생
2. 신뢰성
   • 상태 추적 및 일관성 관리가 어려웠음
   • 특히 협업할 때는 더욱 어려웠음
3. 보안
   • XSS 및 CSRF와 같은 악용 방지를 위해 Sanitize할 필요가 있었음

가장 초창기의 웹 애플리케이션

사용자가 버튼을 클릭했을 떄 고려할 사용자 인터페이스 상태

• 클릭 전
• 클릭했지만 대기 중
• 클릭 후 성공
• 클릭 후 실패 이러한 상태를 관리하기 위해서는 data- prefix가 붙은 HTML 요소에 대해서 매번 해당 DOM Element를 가져오고 이를 업데이트 하는 로직이 필요했음.

서버 데이터에 의존하는 요소의 경우에는 특히 이런걸 관리하는 로직이 힘들었음. 위처럼 고려할 사용자 인터페이스 상태가 최소 4개는 되었기 때문에 복잡성이 높아지고, 상태를 추적하고 이를 업데이트 하는 시점을 예측하기 어려워지게 되는 문제 발생

• 오류가 쉽게 생김
  • Form의 onsubmit 액션과 같은 로직에 대해서 변형이 쉬움.
• 예측이 불가해짐
  • 동일한 id를 가진 element가 많아질 때
  • element가 존재하지 않을 떄
  • 다른 element를 선택했을 때 등..
• 비효율적임
  • 목록 항목을 순차적으로 하면에 → Jqeury가 나오게 되는 계기가 됨.

Jquery

MVC의 문제 → 양방향 바인딩이 안됨

이를 해결하고자 MVVM 패턴 등장. MVVM 패턴 모델

• 애플리케이션의 데이터 및 비즈니스 로직
• 데이터 검색, 저장, 처리
• 데이터베이스, 서비스, 다른 데이터 출처와 통신하고 작업
• 뷰 및 뷰 모델을 인식하지 못함 뷰
• 애플리케이션의 UI
• 사용자 정보 표시, 입력 받기
• 수동적임. 애플리케이션 로직을 포함하지 않지만 데이터 바인딩 메커니즘을 통해 자동으로 변경 사항 반영하여 선언적으로 뷰 모델에 바인딩

뷰 모델

• 모델과 뷰 사이의 다리 역할

• 바인딩할 데이터와 명령 제공.

• 명령 패턴을 통해 사용자 입려개 처리

• 프레젠테이션 로직 포함. 모델의 데이터를 뷰에서 쉽게 표시할 수 있는 형식으로 변환

• 분리된 아키텍처를 위해 뷰 모델은 어떤 뷰가 자신을 사용하는지 인식 X

• 테스트 가능성

• 재사용성

• 유지 보수성

• 데이터 바인딩