기술 아티클 읽고 메모📚_7월

7월

 

6일

토스의 비동기 영상을 보았다. 최근에 useRecoilValueLoadable 코드를 블로그에도 작성(링크)했었는데, 가독성이 좋지 않은 코드였다! 깔끔하다고 생각했어서 충격이기도 했고, 잘못된 점을 알게돼서 기쁘기도 했다.

 

async 함수의 장점을 다음과 같이 설명했다.

'성공하는 경우'만 다루고, '실패하는 경우'는 catch절에서 분리해 처리한다. '실패하는 경우'에 대한 처리를 외부에 위임할 수 있다.

 비동기가 성공적으로 응답을 받았을 때의 코드만 작성해서 동기적으로 보일 수 있게끔 하고, 로딩과 에러는 외부에 위임하는 것. 그래서 내가 작성했었던 useRecoilValueLoadable의 코드는 좋은 코드라고 하기 어려웠던 것이다. 리액트 컴포넌트 내에서 조건문으로 성공, 로딩, 에러의 경우를 모두 다루고 있기 때문에. 비동기 리소스가 늘어날 경우 조건문은 더더 복잡해짐..

 

 이것을 해결해주는 것이 React(React Suspense for Data Fetching)의 ErrorBoundary와 Suspense이다. Recoil에서는 async selector과 Suspense를 사용할 수 있다. 코드의 가독성도 좋아지지만 데이터가 준비되는 대로 하나씩 자연스럽게 보여주기 때문에 UIUX면에서도 좋다.

토스 | SLASH21 - 프론트엔드 웹 서비스에서 우아하게 비동기 처리하기

 

 

16일

긴 휴식기를 가졌다. 정말 오랜만에 본가도 다녀왔다. 너무 휴식이 길었어서 탈..

 네이버 블로그 모바일 서비스가 angular.js의 풀스택 방식에서 Node.js 기반의 SSR로 전환이 됐다고 한다.

 

1. CSR의 기술적 한계 : CSR만을 지원하는 angular.js 내에서 페이지 로드 후 동적으로 콘텐츠를 생성하기 때문에 콘텐츠를 빠르게 소비하는 사용자의 요구 사항 충족하기 어려움. 모두 로드될 때까지 빈 화면..

2. universal language인 JavaScript 최대한 활용 : 개발의 난이도는 있지만 생산성 측면에서 SSR 구축하는 것이 장기적 관점에서 생산적, React 기반의 SSR을 선택!

    → universal language의 장점 + 성장한 React 생태계 이용 가능

3. 프론트엔드, 백엔드 영역 완전 분리 : FE와 BE를 REST API를 통해 느슨하게 연결.

기존에 CSR 페이지는 프론트엔드에서 개발하고 SSR 페이지는 백엔드에서 개발했다면, SSR 환경을 구축하면 페이지의 소유권이 온전히 프론트엔드에 존재. 페이지 변경 시마다 불필요한 커뮤니케이션할 필요X

    → 프론트엔드와 백엔드 사이의 소통은 API 명세에 대한 것으로 국한되어 커뮤니케이션 비용 감소!

    → 작업 완성도 및 이슈 대응 생산성이 상대적으로 높아짐

4. SSR 아키텍처 구성 → 여러 대안 활용의 토대 : 필요에 따라 CSR로만도, CSR with prerendering 개발도 가능.

 

새로 알게된 개념: BTS(bug tracking system, 링크), QA(quality assurance, 품질 개선)

NAVER D2 - 어서 와, SSR은 처음이지? - 도입 편

 

17일

 예전에 옵저버 패턴으로 벤딩머신 코딩을 한 적이 있는데 그 때도 완전 이해하지 못해서 매우 찝찝했다. 이해하고 싶어서 구글링하면서 학습했다. 블로그마다 사용하는 개념 용어가 다르기도 하고, 하나의 글만으로 바로 이해하기 어려워서 여러 글을 읽었다. 음 아직도 완전히 이해하진 못 했다^^ View끼리 이벤트를 주고 받게되면 클래스 간 결합도가 높아지고 복잡해지니 중간관리자가 View들의 변화를 감지해 대신 통보하는 것. 결과적으로 복잡도와 객체 간 결합도는 낮아진다는 것! 설명할 수 있을만큼 잘 이해하기 위해 더 찾아보고 코드도 이해해보고 직접 짜보고 해야겠다..!!

바닐라 자바스크립트로 옵저버 패턴 흉내내보기
옵저버 패턴 with JavaScript
상태관리와 옵저버패턴
TypeScript 디자인 패턴 - 옵저버 패턴

 

19일

 브라우저가 어떻게 동작하는지가 중요하다는 것도 알았고, 해야지해야지 했지만 자꾸 다른 것들에 밀렸었는데 오늘 아티클을 읽었다. 'What happens when type www.google.com'이라고 구글링하면 자료들이 꽤 나온다. 이 아티클을 읽고 블로그에 정리했다. 글을 읽고 정리하는 데에 꽤 걸렸는데 실제로는 몇 ms안에 끝나는 과정이라는 게 신기했다. 어떻게 이렇게 복잡한 과정이 순식간에 지나고 사이트가 로드되는 건지.. 컴퓨터나 인터넷이 빠르다는 거야 알고있지만 이렇게 한 번씩 새삼스럽게 신기할 때가 많다. 만 번 이상의 반복문이 후딱 끝날 때라던지ㅋㅋㅋㅋ

What happens when you type a URL in the browser and press enter?

 

20일

 브라우저의 렌더링 과정에 대해 간단히 알게 되었다. 렌더링 최적화를 위해서는 렌더트리 생성 > layout > paint 과정을 최대한 줄여야하는데 이 부분에 대해서도 다음에 찾아봐야겠다. DOM에 대해서는 워낙 많이 들어봤지만 전체적인 렌더링 과정을 통해 DOM 생성과정도 알게돼서 좋았다. 그리고 display: none, visibility: hidden이 렌더 트리 생성 과정에서의 차이가 있다는 것도 알게 돼서 마음이 시원하다! 아래 아티클들을 읽고 DOM, CSSOM, Render Tree에 대해 블로그에 간단하게 정리했다.

Critical Rendering Path | Constructing the Object Model
Critical Rendering Path | Render-Tree Construction, Layout, and Paint

 

21일

디바운스와 스로틀링에 대해 찾아보았다. 이것도 구현해보고 공부해봐야지 하고 계속 미뤄놨던.. 코드스쿼드 과정이 끝나니 이런 것들을 차차 공부하고 정리할 수 있어 좋다. 코딩을 많이 못 하고 있지만ㅎㅎ 디바운스와 스로틀링의 차이에 알게됐다. 그리고 클로저를 사용한 바닐라 자바스크립트 코드도 공부했다. 공부한 내용에 대해 다음에 블로그에 정리해야겠다. 오늘은 시간이 너무 늦어 자야겠다..

디바운스와 스로틀 그리고 차이점

 

22일

let, const 변수 선언 이전에 사용할 수 없다는 걸 알고는 있었지만 TDZ(Temporal Dead Zone)이라는 개념을 오늘 처음 알았다. TDZ를 모른 채 자바스크립트 변수를 사용하지 말라는데 그렇게 해왔었다ㅎㅎ 하지만 엄청 새로운 개념은 아니고 변수 선언 이전에 변수를 사용하는 것을 허용하지 않는다는 것이다. 새로 알게 된 것은

- class구문도 이전에 사용 안 된다는 것. 그렇게 많이 사용했는데 몰랐었다.🙄 

- 반대로 import 구문은 또 호이스팅이 되고 선언 전에 호출해도 된다는 것.

- constructor() 내부의 super()를 호출하기 전에 this 사용이 안 돼서 super()를 먼저 호출해줘야 한다는 것.

- typeof 연산자로 변수가 현재 스코프 안에 선언되었는지 확인할 때 유용하다는 것도 신기했다.

TDZ를 모른 채 자바스크립트 변수를 사용하지 말라

 

23일

 상태 관리를 위해 useState, useReducer, contextAPI, 라이브러리 Recoil을 써봤지만 상태관리가 무엇인가?에 대해 말이 안 나왔다. 그래서 찾아보다 보니 네이버 테크 콘서트 영상을 보게 되었다.

 앱 사용이 보편화되면서 사용자들은 페이지 전환이 많은 것을 원하지 않는다. 앱처럼 한 페이지에서 데이터를 주고 받아 화면을 실시간으로 보여주는 SPA를 원한다. 그러다보니 페이지 내의 상태들을 잘 관리해줘야 하는 필요성이 생겼다.

 이 영상에서 jQuery → AngularJS → Redux로 상태관리의 발전 과정을 설명해주시는데 React로 상태관리를 배운 게 행복한 것이란 생각이 들었다. jQuery는 상태를 따로 저장하는 게 아니라 HTMLElement 각각에 상태를 저장해 DOM을 조작했다고 하는데 끔찍하다😵 jQuery로 해보진 않았지만 자판기를 바닐라 자바스크립트 클래스로 만든 적이 있는데 데이터 관리가 굉장히 까다로웠었다. View 간에 데이터 조작이 서로 막 하다보니..(그 당시의 나는 복잡하지 않게 하려고 노력했으나ㅜㅜ) 그리고 AngularJS가 굉장히 대단한 것임을 알 수 있었다. 상태 관리 패러다임을 바꾼!! 신기했다. 계속 발전해왔지만, 이렇게 불편한 점들이 있음으로 계속 개선이 되고 빠르게 발전되고 있다는 게 정말 신기하다. 세상의 개발자들엔 똑똑한 사람도 많고 열정적인 사람도 많은 것 같다. 개발자들 멋져

NAVER TECH CONCERT: FRONT END 2019 - 데이터 상태 관리. 그것을 알려주마