2021-04
04월 05일 : 렌더러프로세스의 내부동작
렌더러프로세스: 주로 메인스레드의 역할이 크다. 최근미션이었던 jsonParser가 떠올랐다. 메인스레드는 문자열 html을 파싱하여 문서구조를 파악하고, css도 파싱하여 각 노드의 스타일을 파악하여 레이아웃 트리를 만든다. 이것만으로 렌더링을 할 수 없다. 레이아웃 트리를 만들면서 레이어 트리도 만들고 페인트 단계에서 요소를 그리는 순서를 정리하게된다.(마치 canvas로 그림을 그렸던 것과 같이 순서가 중요하다.) 이를 바탕으로 draw 그리기가 이뤄지고 래스터화시킨다고 표현됐다.(rasterlize) 기본적으로는 뷰포트 내부에 래스터시키고 스크롤에 따라 빈 공간을 다시 재 래스터화 시키는 방식인데, 최근엔 '합성'이 사용된다. 페이지의 각 부분을 별도로 래스터하고 컴포지터 스레드가 이들을 합성한다. 레이어가 너무 큰 경우 래스터스레드가 레이어를 타일형태로 나눠 GPU메모리에 저장시킨다. 이것의 이점은 메인스레드와 별도로 작동하므로 JS실행이나 페인트계산이 필요없어 애니메이션을 가장 부드럽게 구현할 수 있다는 점이다.
드로 쿼드 메모리에서 타일의 위치와 웹 페이지 합성을 고려해 타일을 웹 페이지의 어디에 그려야 하는지에 관한 정보를 가지고 있다. 컴포지터 스레드가 렌더링하기 위해 드로쿼드를 모으기 시작한다.
이 아티클은 시리즈로 작성되서 앞뒤내용이 너무 궁금해진다. 하지만 여기까지만 읽겠다. 여기서 가장 관심이 갔던 부분은 JS script를 만나면 js코드를 로딩,파싱해야하면서 html파싱이 멈춰버려 렌더링 jank가 생겨버리는 점이었다. 이를 피하기 위해 js script를 비동기적으로 실행해야 하는 것이 좋다는 점, reqestAnimationFrame은 렌더링과 js로딩을 잘게잘게 쪼개 실행하는 듯하다. (setTimeout으로 실행하라는 글을 본적은 있었는데 이것이 그리 정확한 타임라인을 지켜준다는 확신이 없다고 한다.)그리고 웹워커가 js를 도와준다 .
아티클에 나와있는 그림들이 너무 귀엽다. 특히 마지막 이 프레임을 렌더링해 줘!"(Render this frame please!).🥰 ㅎㅎ
간단하게 소감을 적으려고했는데 읽다보니 재밌어서 자세하게 보고 적게 되었다. 어차피 내일부턴 다시 시간이없을테니 이렇게 적지도 못하겟지 i _ iㅎㅎㅎㅎ
04월 10일 : 프론트엔드와 백엔드가 소통하는 엔드포인트, RESTful API
REST는 REpresentational State Transfer의 약자, 서버에 get요청을 보내 받은 json데이터는 단지 데이터베이스에 저장되어있는 원본 데이터 리소스의 현재 상태를 표현한 것, REST는 클라이언트와 서버가 리소스의 타입이나 원하는 언어 등을 사용하여 자원을 자유롭고 명확하게 표현할 수 있는 것에 집중한다. put(리소스 대체)/patch(리소스 수정)의 차이를 알게 되었다. 다음주 미션에 명확하게 api설계해봐야지.
04월 11일 : 10 JavaScript Quiz Questions and Answers to Sharpen Your Skills
질문3번ㅎㅎObject.freeze()가 신기했다. 객체를 변경시키지 못하게 동결시켜버린다니. 얼음땡이넹. 그치만 얕은 복사라서 객체 내 객체는 동결시키지 못한다.얕은복사 관련된 8번 내용도..! 얕은 복사는 모양은 복사했지만 참조하는 대상을 바꾸지는 못한다. 따라서 객체를 수정하려하면 원본데이터까지 변경되어 버린다.
질문9번은 잊어가고있던 bind의 개념을 상기시켜주었다. this를 묶어서 새로운~~ 함수로 만들어 주기! 이번 아티클은 오랜만에 js의 기본 개념들을 다시 한번 검색해보고 상기시키는 기회가 되어 좋았다.
04월 12일 : 어서 와, SSR은 처음이지?
SSR과 CSR에 대해 대략적으로 알게된 글이었다. 오랫동안 사용해왔던 네이버 블로그를 떠올리며 글을 읽다보니, 이걸 만들기 위해 이런 고민과 결정을 해왔구나를 생각하며 읽어 재미있었다. SSR은 사용자응답면에서 신속하다는 기술적 장점을 취하면서도(초기로딩은 CSR보다 늦음) Node.js를 기반으로하여 백엔드의 비중보다 프론트엔드의 비중을 높였고 프론트엔드입장에서 풀스택에 대한 고민을 해결한 방법이기도 하다. SSR과 프론트엔드의 현 시점을 파악할 수 있어 공감하며 읽은 글이다.
04월 13일 : The one thing that no one properly explains about React — Why Virtual DOM
[번역] 리액트에 대해서 그 누구도 제대로 설명하기 어려운 것 – 왜 Virtual DOM 인가?
Virtual DOM 단어는 리액트를 접하게 되면서 많이 들어봤지만 정확히 개념을 알고있지 않아 개념공부부터 시도했다. 첫날읽었던 아티클(04/05 렌더러프로세스의 내부동작)이 DOM이 생성되는 과정을 이해하는데 큰 도움이 됐었다. Virtual Dom은 말 그대로 '가상 돔'으로 데이터가 업데이트되면 전체 UI를 자바스크립트 객체형태의 Virtual DOM에 리렌더링하고 이전 버젼의 Virtual DOM과 차이나는 부분만 실제 DOM에 적용시킨다. 기존의 전부를 리렌더링하면 DOM자체가 느린 것보다는 DOM을 그려주기까지의 연산과 실행과정이 렌더링갯수만큼 소요되니 늦어지게 된다. 이를 피하기 위해 정말 수정해야할 부분만 도와주는 것이 Virtual DOM이다. 개념을 확인하고 가게된 아티클이었다.
04월 15일 : 주니어-개발자가-포트폴리오를-준비할-때-알아두면-좋은-것들
읽고 읽고 또 읽자. 고민의 흔적을 남기자.
04월 19일 : 깊은 복사와 얕은 복사에 대한 심도있는 이야기
자바스크립트에서 “복사” 라고 알려져있는 거의 모든 기능은 이터러블 순회를 수행하도록 설계되어 있어 기본형데이터는 복사가 되지만 중첩된 객체(참조형 데이터)를 복사할 땐 값이 아닌 주솟값만 복사하게 된다. 주솟값이 동일하기 때문에 중첩객체값을 수정할 때 원본과 복사본은 똑같은 변경이 일어나게 된다. 내부 프로퍼티에 대한 재복사가 필요하다. 깊은 복사를 할 수 있는 방법으로 JSON.parse(JSON.stringfy(obj))가 있는데 데이터를 주고받을 때만 쓴다고 생각했지 복사의 방법이 될 수있다는게 신기했다. 그러나 함수나 JSON으로 변경할 수 없는 프로퍼티는 무시되기 때문에 정말 전송받은 데이터를 복사할때 활용하는 것이 좋을 것이다.
04월 21일 : 잘가, 클린 코드
능력자의 실수(?)회고를 읽으니 너무 재미있었다. 내용도 내용인데 역시 누구나 실수를 할 수있다는 그 상황자체가 재밌었다고 해야할까. 인상깊었던 부분은 댄의 실수 첫번째로 코드를 작성한 사람과 변경에 대해 논의하지 않았던 것
(페어프로그래밍을 하면서 주의하자고 생각한다. 상대방이 나에게 논의와 양해를 구할때 -뭐 이런거까지 얘기한데?- 이렇게 생각 하지말고 , 나 또한 사소한 것이라도 하고나서 통보하지말고 미리 상대방에게 얘기를 하고 진행하도록 하자!)
두번째는 클린코드란 코드를 읽기 좋게 하기위한 수단인데 그것이 목표가 되어 버렸다는 점이다. 클린코드보다도 추후 다양한 사람들로부터 어떻게 발전될 것인지에 대해 고려가 필요하다. 꼭 프로그래밍에서만 해당되는 내용은 아닌 것 같다. 각자가 중요하게 보는 관점이 있겠지만 거기에만 갇혀 다른 시각에 차단되지 않도록 주의하자.
04월 25일 : How to fetch data in React
데이터 요청에 관한 시점과 방법, fetch - axios 사용차이를 확인할 수 있었다. 현재 미션을 fetch로 하고있는데 axios로도 구현해봐야겠다.
04월 26일 : Fix Like No One’s Watching
리팩토링을 부지런히 해야하는 이유! your project’s fate depends on it.
