화면을 업데이트 해야 합니다. 변경사항에 따라 문서 트리 전체를 다시 그리는 것은 비용이 많이 들기에 변경 부분만 반영할 필요가 있습니다. ݽ؛ .PEFM ޙࢲёݽ؛ %0. Actual DOM 실제 — 문서객체모델 모델(데이터 구조) 변경 — 렌더링 프로세스 → 문서객체모델 ࢚క߸҃ ࠭সؘ
ޙࢲёݽ؛ %0. ޙࢲёݽ؛ %0. 과거 웹 애플리케이션은 클라이언트에서 데이터 변경을 요청하면 서버에서 이를 처리하여 새로운 DOM을 생성한 후, 응답해주는 프로세스가 사용 되었습니다. 하지만 이 방법은 매우 느렸고, 오늘 날 이 부분을 프론트엔드에서 관리/처리 해야 할 필요가 생겼습니다. ࢚క߸҃ ࠭সؘ
이러한 프레임 워크는 모델에서 UI 코드를 분리하기위한 아키텍처를 제공 했지만, 두 모델 간의 동기화는 여전히 남아있었습니다. 변경이 발생할 때 어떤 종류의 이벤트를 얻을 수 있지만 다시 렌더링 할 대상과 이동 방법을 파악하는 것은 개발자의 몫이었습니다. 모델(데이터 구조) 변경 — 렌더링 프로세스 → 문서객체모델 ߮ FWFOU زӝച 4ZOD Backbone, Ext JS, Dojo 와 같은 초창기 프레임워크는 모델 데이터 상태 관리를 웹 브라우저에서 하는 방법을 도입했습니다 상태 변경이 발생하면 이를 바로 UI에 반영하여 업데이트 합니다 ࢚క߸҃
Backbone과 마찬가지로 Ember는 변경이 발생할 때 데이터 모델에서 이벤트를 보냅니다. 차이점은 Ember 프레임워크가 이벤트 수신을 위한 기능을 제공하는 것입니다. 즉, UI에 첨부 된 업데이트 이벤트에 대한 리스너가 있음을 의미합니다. 모델(데이터 구조) 변경 — 렌더링 프로세스 → 문서객체모델 সؘ߄ੋ٬ #JOEJOH6QEBUF ࢚క߸҃
데이터를 참조 할 때, 예를 들어 {{foo.x}} 와 같은 표현식에서 데이터를 렌더링 할뿐만 아니라 특정 값에 대한 관찰자도 만듭니다. 그 후 앱에서 어떤 일이 발생하면 Angular는 해당 감시자의 값이 마지막으로 변경 되었는지 여부를 확인합니다. 있는 경우 UI의 값을 다시 렌 더링합니다. 이러한 감시자를 실행하는 프로세스가 더티 체크입니다. 모델(데이터 구조) 변경 — 렌더링 프로세스 → 문서객체모델 ҙ 8BUDIFST 1 ݽ؛ .PEFM
상태 변화에 신경 쓰지 않았던 좋은 오래된 서버 측 렌더링 일로 되돌아갑니다. 변경 사항이있을 때마다 전체 UI를 처음부터 렌더링 합니다. 이렇게하면 UI 코드가 크게 단순해질 수 있습니다. React 구성 요소의 상태를 유지하는 것에 신경 쓰지 않습니다. 서버 측 렌더링과 마찬가지로 한 번 렌더링 하면 완료됩니다. 변경된 구성 요소가 필요할 때 다시 렌더링 됩니다. 구성 요소의 초기 렌더링과 변경된 데이터에 대한 업데이트는 차이가 없습니다. 모델(데이터 구조) 변경 — 가상 DOM — 렌더링 프로세스 → 문서객체모델