# 2021.01

# 1/1

# 모노레포

https://kdydesign.github.io/2020/08/25/mono-repo-lerna/ https://kdydesign.github.io/2020/08/27/mono-repo-lerna-example/

멀티레포 vs 모노레포
1. 멀: 여러repo에 각각 패키지 관리. A를 만드는데 B, C 레포로 나눠짐. CI가 하나에 집중하기 때문에 빠름. 컨플릭 피하기. But 공통된 설정 매번 다 세팅및 설치해야함. 공통코드도 중복됨. 그리구 이슈트래킹이나 로그가 분산되어 관리(결국 하나의 서비스 목푠데도). 의존성 버전관리 hell.
2. 모: 여러패키지 한 repo에 관리. 공통코드나 설정 한벌만(각 의존성 업데이트도 관리 편함). 이슈 트래킹 통일. But repo가 넘 커지고 CI느림. 패키지별 과한 의존 관계.
구글, 페북, 트위터가 모노레포 방식 선택
Lerna: 모노레포 관리와 workflow 최적화 도구
1. 모듈 설치할때 중복을 통합해줌 / 독립적인 버전 정책 / 패키지 일괄 push및 npm publish
2. Babel, vue-cli, jest, nuxt, cra, webpack-cli 등이 사용
3. https://openbase.io/js/lerna <- 오홍 오픈소스 현황 대시보드구나

# 1/2

https://speakerdeck.com/raon0211/toseuyi-maikeuropeuronteuendeu-akitegceo-geurigo-jadonghwa https://aws.amazon.com/ko/microservices/ https://medium.com/@yesesyo/%EA%B0%80%EB%B3%8D%EA%B2%8C-%EB%A7%88%EC%9D%B4%ED%81%AC%EB%A1%9C%EC%84%9C%EB%B9%84%EC%8A%A4-%EA%B5%AC%EC%B6%95%ED%95%B4%EB%B3%B4%EA%B8%B0-1-fb4d7741b316

# 마이크로서비스

여러 서비스를 관리하기 위해...
- v1 모놀리식: 한패키지에 여러서비스 (빌드느림, 서비스별 캐싱 등 정책분리 어려움). 뚱뚱해지면 새로운 아이디어 구현 어려워짐.
- v2 마이크로서비스: 한패키지에 하나서비스, 자유로운 의존성 선택
- v3 모노레포: 한repo에 여러패키지
장점
- 설정공유 간편하다 (eslint 세팅을 상대경로로 상위에서 받아오기(extends: [../../.eslintrc.service.js))
- 소규모 컨텍스트의 작은 팀:민첩하다. 서비스별로 독립적인 확장. 기술적 자유, 배포쉬움.

# 1/3

# Observable

https://slides.com/seokjume/observable#/1-title (옵저버블을 읽기 좋은 도해로 표현한 좋은 자료다. debounce 타임 안에서 이벤트 구독해제가 어떻게 일어나는지 그림에서 감탄)

Promise의 한계: 취소불가(e.g. 검색 자동완성때 텍스트를 바꿀때마다 이전 텍스트 자동완성콜 취소해야한다), 단일값
Observable
- 비동기로 발생하는 '여러'데이터를 다루는 인터페이스 / 이벤트 스트림 / 취소 가능 / 흐름을 쉽게 읽을 수 있음
- cleanup 함수 제공: 이벤트리스터 해지 or ajax abort
- composition 가능
- 아하 이벤트 스트림을 함수형으로 다룰 수 있구나. 성능차이는 어떻게 되나?
js에선 아직 proposal(stage1)상태. RxJs등이 옵저버블 구현체 제공해서 사용가능.

# 1/4

# ECMAScript와 TC39

https://ahnheejong.name/articles/ecmascript-tc39/ https://ko.wikipedia.org/wiki/Ecma_%EC%9D%B8%ED%84%B0%EB%82%B4%EC%85%94%EB%84%90

Netscape와 MS등 이해당사자들끼리 합의해서 ECMAScript 언어 표준 만듦.
1. (Ecma인터네셔널: 정보통신 국제적 표준화기구. European Computer Manufactures Association이었다가 국제적 확장위해 이름 바꿈)
2. (Ecma인터네셔널의 여러 기술위원회(TC - Technial Committee)중 TC39란 위원회(모질라, 구글, 애플 등 브라우저 벤더, 페북, 트위터 등 다양한 단체 피플)가 이 명세 관리)
3. TC39위원회 회의록 (opens new window) 흥미롭다. 2020년 11월 19일 회의 보면 :: 문법 프로포절 (opens new window) 이랑 이에 대한 프레젠테이션 (opens new window), 그리고 이에 대한 구루들의 열띤 토론 (opens new window)이 모두 적혀있군.
  1. 회의에서 발제자의 발표가 끝나고 제일 처음에 말을 꺼낸 MM이란 사람 말 전개 구조가 인상깊다. 디테일하게 칭찬하고 감사를 표하고, 스무스하게 질문으로 들어간다.
    1. 프로포절 감사하다 / 이게 stage one 가길 완전 협조하겠다 / 훌륭한 발견이다 / very simple core가 있는 발표다. 적절한 starting point를 잡았어 / bind오퍼레이터에 대한 virtual한 관점. / 글고 니가 simple코어로 좁히기 전에 broader exploration을 얘기해서 우리가 대안도 상상할수있게 해서 좋다. 전체적으로 맘에 든다. / 이제 3항폼에 대해 질문 있다 ,~~
  2. 영어로 회의 진행할 때 참고할 수 있는 표현과 전개방식이 많다. 전 회사에서 알았다면 유용했겠네.
TC39 프로세스
1. 프로포절 저장소: https://github.com/tc39/proposals
  1. 문법을 제안한다는게 재밌다. 라이브러리 만드는 그 이상이다. https://github.com/tc39/proposal-top-level-await
2. 0단계: 누구든 프로포절을 낼 수 있음. 라이센스 동의 + TC39컨트리뷰터로 등록. 모두가 Tc39 회의 안건으로 상정됨.
3. 1단계: TC39구성원 중 1인이 총대매줘야함(챔피언). 구현상 폴리필, 데모 등 필요.
4. 2단계: ECMAScript표준으로 작성된 초안 필요. 실제 표준 편입될 때 사용할 명세의 초기버전.
5. 3단계: 마무리된 명세 필요. 이제부턴 변경 불가
6. 4단계: 제안 수락됨! 다음 표준 발표를 기다리는 중.

# 1/5

# 명령형(imperative)과 선언형(declarative) 프로그래밍

https://so-tired.tistory.com/75 https://boxfoxs.tistory.com/430 <- 앗 ㅅㄹ님 https://dev.to/khophi/explain-declarative-vs-imperative-programming-like-i-m-5-2a1l

// option 1
<button onClick={() => logToServer(data)} />

// option 2
<LoggingClick data={data}>
  <button />
</LoggingClick>

option 1보다는 option2가 더 코드가 깔끔하다. 선언적이니까~ 라고 말하려다가 내가 명령형과 선언형의 차이를 모호하게만 인지하고 있다는걸 깨닫고 좀 찾아봤다.

리액트 컨셉 자체가 선언형
- jQuery등: 상태에 따라 DOM을 어떻게 업데이트 해야하는지 규칙을 적기
- 리액트: 상태에 따라 보여져야하는 DOM을 미리 정의 (매번 새로그리기 - Virtual DOM 으로 빠른계산해서 가능한 일)
명령형 vs 선언형
- 명령형: '어떻게' 할것인가 (e.g. 12번 테이블이 4인자리가 비어있네요 저기로 걸어가 앉겠습니다)
- 선언형: '무엇을' 할것인가 (e.g. 4인 앉을자리를 주세요)
  - 다만 종업원이 가는길 알고있어야함('어떻게'에 대한 추상화): 선언형 프로그래밍의 중요한 솔루션! 명령형으로 작성된 구현에 대한 추상화

# 언제 useCallback 을 쓰고, 쓰지 말아야 할까?

https://dmitripavlutin.com/dont-overuse-react-usecallback/ https://aheadcreative.co.uk/articles/when-to-use-react-usecallback/ https://kentcdodds.com/blog/usememo-and-usecallback

'이 함수 useCallback으로 감싸주세요~'란 코드리뷰 많이들 받아봤을거임. 과연 효과적인 useCallback의 유즈케이스는?

써야 할 때: React.memo로 만든 컴포넌트에 함수 넘길 때 / 다른 훅에 dependency로 있을때 / 너무 긴 함수(웬만하면 안 만드는게 좋겠지만)
안써도 될 때: 위 케이스가 아닐 때.(useCallback을 부르는 코스트와 함수를 memo해서 얻는 성능향상이 비슷. useCallback dependencies 관리포인트만 늘어날수도)
1. 아래와 같은 케이스는 useCallback 없는게 성능 더 빠름 (useCallback도 불러야하고 빈 array도 만들어야하고.)
```
const dispense = React.useCallback((candy) => {
  setCandies((allCandies) => allCandies.filter((c) => c !== candy));
}, []);
```
- 미미한 성능최적화보다 코드를 복잡하게 만든다는 단점이 더 커짐.
- 유지보수 하다 dependencies array 에 실수할수도 있음
useCallback은 계산된 값을 메모이즈하는게 아니다. 함수 자체를 메모이즈하는것임. 값 메모가 필요하면 useMemo쓰삼.
결론: 성능최적화는 꽁짜가 아니다. 최적화를 하고 싶다면 실제로 최적화가 된지 측정해보라.

# 독서 습관을 만드는 구체적인 방법

https://blog.shiren.dev/2020-10-05/

책읽는 속도파악: 100페이지에 몇분 걸리는지 측정. 후에는 책 집었을 때 '흠 대략 n시간 걸리겠군' 파악가능 (shiren님은 약 1시간)
마킹하며 읽기 - 종이책이라면 손가락으로 가리켜서 사진찍고 구글포토에 그룹으로 만들어두기(OCR로 검색도 됨!)
마킹한 부분 따로 정리

# 1/6

# React clean code

https://dev.to/jithinks97/writing-clean-react-code-2mcm

컴포넌트는 짧짧익선
컴포넌트에서는 같은 레벨의 추상화를 모아둬라
props갯수 줄이기. 많이 보내야한다면 비슷한 인자를 object로 묶어서.

# 1/7

# 웹소켓이 등장하기까지 - 폴링, 스트리밍, 웹소켓

https://lkhlkh23.tistory.com/121 https://ko.javascript.info/websocket https://medium.com/@chullino/http%EC%97%90%EC%84%9C%EB%B6%80%ED%84%B0-websocket%EA%B9%8C%EC%A7%80-94df91988788

Polling: 클라에서 api 주기적 요청. 요청수가 많아 서버부담 큼.
Long Polling: 클라에서 api 요청하면 서버에선 대기타다가 필요한 시점에 응답값 줌. 서버 요청이 몰려서 순간 부담 커질수 있다.
Streaming: 연결 안 끊고 계속 전달.

WebSocket: 새로운 통신 프로토콜.첨에 HTTP로 연결했다가 서로 쿵짝이 맞으면 그 때 부터 HTTP프로토콜이 아닌 양방향 통신 가능.

let socket = new WebSocket("wss://javascript.info"); // ws보다 wss가 안전. https처럼.
socket.onopen = function (e) {
  alert("커넥션 만들어짐");
  socket.send("데이터 가랏");
};

socket.onmessage = function (e) {
  alert("서버가 준 데이터:", e.data);
};

socket.onclose = function (e) {
  if (e.wasClean) {
    alert("정상종료");
  } else {
    alert("커넥션 이상하게 쥬금");
  }
};

socket.onerror = function (e) {
  alert("에러", e);
};

HTTP 프로토콜: url 주면 서버에서 문서 줄수이음
AJAX: HTTP프로토콜을 잘 활용. XMLHttpRequest 객체로 데이터 주고받음.
WebSocket 프로토콜: 양방향 프로토콜

# 1/8

# HTML5, 웹소켓

https://www.slideshare.net/hiscale/111015-html5-1 2011년 자료.

HTTP: Hyper Text Transfer Protocol. 서버가 HTML로 디자인된 문서를 유저에게 잘 보내주는게 핵심. 이전까진 걍 터미널에서 txt만 주고받음.
1. 그래서 새페이지에서 새데이터 보여주거나, 팝업 / iframe으로 보여줌. 플래시나 액티브엑스도 사용.
Ajax: Asyncronous JavaScript And XML. 옛날부터 존재하던 기법이지만 구글이 쓰며 대중화됨. js의 XMLHttpRequest란 api로 url이동이 아닌 임의 요청을 주고받음.
1. XMLHttpRequest의 한계. 브라우저가 서버로 요청 보내면 서버가 응답 주는것만 가능. 서버가 필요할 때 먼저 데이터를 주는게 불가능.
웹소켓: HTML5 표준에 추가된 규약. 어제 적은 설명과 동일.

# 1/9

# isLoading props 그만써라

https://kentcdodds.com/blog/stop-using-isloading-booleans?ck_subscriber_id=448616155

기본상태, isLoading, isError 만 관리해선 api결과가 변동될 때 원하는 상태를 정확히 캐치하지 못할 수 있다
명확하게 key 하나로 관리하자: status = 'idle' / 'pending' / 'resolved' / 'rejected'
내생각: 위처럼 관리하면 render코드가 모두 같은뎁스로 resolved나 rejected 등 ui 코드가 보여짐. 코드를 빠르게 파악하려면 가장 메인 동작(resolved상태의 UI)을 한눈에 볼 수 있어야하는데 중요도 없이 섞여버림. try catch문도 성공하는 케이스를 try문에 집중해서 넣고 엣지 케이스들을 catch에 넣어서 중요한 코드만 빠르게 파악할 수 있잖아. 차라리 <Suspense fallback={}>으로 감싸는게 더 try/catch처럼 성공케이스에 집중해서 좋을거같음.

# 1/10

# Ellx

https://ellx.io/

Exploratory programming의 컨셉을 차용. 코드 씀과 동시에 바로 결과 볼 수 있다.
브라우저에서 100% 로컬하게 돌아감! 새로운 라이브러리나 api테스트하고, 앱 부트스트래핑하거나 아예 프로덕션에 내놓는것, 서버리스 마이크로서비스까지(이건 곧) 지원.
특이하네... 노트북처럼 생겼는데 웹코드도 다 돌릴 수 있고 웹으로 말아낼 수 있는 가능성도 높다.

# Skypack

https://www.skypack.dev/

설치나 빌드 툴 없이 npm 패키지 이용가능 (!). 그리고 최적화까지 되어있음. 무료임.

import confetti from "https://cdn.skypack.dev/canvas-confetti";
confetti();

# Exploratory programming

https://en.wikipedia.org/wiki/Exploratory_programming https://www.facebook.com/groups/TensorFlowKR/permalink/1055753581432366/

탐구적 프로그래밍. 도메인이 잘 알려지지 않았거나 아직 결론이 안 났을 때, 인터랙티브하게 개발하고 디버깅하는게 필요할 때가 있다.
edit - compile - run - debug 사이클.
e.g. 노트북, 스프레드시

# 1/11

# 리액트 17의 새로운 JSX 변환

https://reactjs.org/blog/2020/09/22/introducing-the-new-jsx-transform.html

바벨이랑 협업해서 새로운 JSX transform 만듦(기존껀 유지)
React 의존성 없이 JSX transform을 쓸 수 있다. 번들 사이즈가 줄었다. 리액트 첨배울때 이해해야 하는 개념들 줄여준다.

예시

// As-is
import React from "react";
React.createElement("h1", null, "Hello world");

// To-be
import { jsx as _jsx } from "react/jsx-runtime";
_jsx("h1", { children: "Hello world" });

React 임포트 안함. api설계가 바뀜 (children: "" 넘기는 식)

# 1/12-13

# 2020년과 이후 JavaScript의 동향 - 라이브러리와 프레임워크

https://d2.naver.com/helloworld/7226235 https://d2.naver.com/helloworld/6951656

오호 앵귤러는 Virtual DOM방식이 아닌 Incremental DOM이란 방식을 쓰구나.
1. VDOM은 렌더링 요인이 발생할 때마다 전체 트리를 다시 그리는데 Incremental DOM은 재렌더링이 발생하지 않는 영역은 메모리 사용x하고 DOM 추가하고 삭제할때만 씀.

오호 Vue3 Composition api쓰면 로우레벨 Reactivity API랑 Lifecycle hooks 사용할 수 있구나

import { onMounted, onUpdated } from "vue";

const MyComponent = {
  setUp() {
    onMounted(() => {
      console.log("mounted");
    });
  },
};

Svelte: ts지원을 귀엽게 하네. <script lang="ts">로 사용할 수 있도록. 기존의 번들러 슬슬 떠나고 있음(개발시에는 온디맨드로 모듈 제공). 일단 Snowpack을 써서 HTR, SSR등 사용하고 최적화된 앱 배포하려면 Rollup 쓰긴 함.
Stimulus: 2017년 만들어짐. 전체 프런트엔드 스택 커버하기보단 HTML에 data-*속성으로 컨트롤러/타겟/액션 기술.

# 1/13

# Hey 이메일 클라이언트

https://app.hey.com/

UX적으로 이메일이라는 서비스를 새로 썼다.
앞으로 계속 보려는 메일을 turn on하고, 뉴스레터들은 모아서 timeline으로 보고 등등.
앗 근데 1년에 99달러네 일단 머릿속에만 킵

# 1/15

# 휴리스틱

https://m.blog.naver.com/businessinsight/221053956083 https://medium.com/lucky-sonnie/%ED%81%B4%EB%A6%B0%EC%BD%94%EB%93%9C-17%EC%9E%A5-%EB%83%84%EC%83%88%EC%99%80-%ED%9C%B4%EB%A6%AC%EC%8A%A4%ED%8B%B1-e6ad551ecbf3

= 발견법. 간편추론. '대충 어림짐작하기'.
스윽 보고 대강 이해할 수 있도록 코드 짜기.

# WebAssembly

https://d2.naver.com/helloworld/8257914 https://hacks.mozilla.org/2017/02/what-makes-webassembly-fast/

Wasm. 브라우저에서 네이티브 머신 코드 돌리기 위한 시도. 이제 웹의 언어는 공식적으로 4개 - HTML, CSS, JS(하이레벨 랭귀지), WASM(로우레벨 랭귀지)
1. C/C++, C#, Rust, Go, Kotlin, Swift 등 언어를 Wasm으로 컴파일해서 사용가능.
'언어' 라기보단 '네이티브 코드를 웹에서 실행시켜주는 도구'.
JavaScript랑 같이 JavaScript엔진내에서 나란히 실행됨.
(곧)뭐 할 수 있게되냐?: 멀티스레딩, SIMD(겜이나 VR등에 필요한 복잡한 연산 속도를 음청 높임) 등.
JS에 비해서 더 빠르다
1. JS는 parse > compile+optimize > re-optimize > excute > garbage collection
2. WASM은 decode > compile+optimize > execute
3. 그리고 바이너리 파일이라 크기가 작아 로드 빠름. 또 이미 중간표현식으로 컴파일되어있음으로 파싱 필요x.
지원
1. 크롬/v8: 이전2GB -> 이제4GM(32bit포인터의 최대치)
2. 스레드: Web worker를 기반으로 한 Wasm스레드

# 1/16

# Rust

모질라에서 연구목적으로 개발중인 언어. C/Go처럼 컴파일기반 언어, 현대적인 시스템 프로그래밍 언어.
특징
1. C/C++와 속도 같으면서도 메모리 안정성 up.
2. 함수형 도입.
3. 클래스 대신 Trait를 기반으로 다형성.
4. 모던한 모듈 시스템
스택오버플로 설문조사에서 가장 좋아하는 언어 1위 16년부터 20년까지 달성 (opens new window) (2위는 TS, 3위는 파이썬, 4위는 코틀린, 5위는 Go군)

# 1/17

# 자바스크립트의 성장

https://d2.naver.com/helloworld/4268738

js는 10년 주기로 큰 변화 일어났다
1. 97~07: js와 jQuery등으로 동적인 웹개발 시작. 언어적 표준화(ECMAScript 1) 시작~ 4까지 나옴
2. 09~19: ES5. Nodejs, NPM, 빌드/번들러, 다양한 프레임워크
3. 20~: 레거시 영역 정리, 여러 도구로 형성된 레이어 제거. CommonJS/AMD(RequireJS)와 같은 비표준 모듈 사용에 의존하는애들이 ECMAScript모듈(ESM)으로 전환될것. 그리고 Deno나 Relay처럼 코어 JS도구에 JS가 아닌 Rust도 사용하고 있다.
엣지가 2018년에 크로미움 전환했었네; 몰랐다..
모듈 지원
1. 15년에 ES6로 표준 모듈스펙 나왔지만 호환성 등 이슈때문에 현재 다양한 포맷의 모듈 혼합사용중 ㅠㅠ 12+개 정도 있네 https://weblogs.asp.net/dixin/understanding-all-javascript-module-formats-and-tools
2. jspm 사용해서 ESM import 가능
```
// https://jspm.org/#url-patterns
import module from "https://jspm.dev/NPM_패키지_이름";
```
1. 슬슬 ESM으로 통일되려 하고있슴. CommonJS를 쓰던 Node.js도 ESM 지원 노력중. 근데 번들러는 정적분석 해서 미사용 export 제거해 최적화해준다는 장점도 있음. bundle + optimize하면 훨 빨라짐.
TC39: 이젠 메일링 말고 디스커스로 누구나 제안 가능 https://es.discourse.group/
ECMAScript2020
1. 동적 import: await import("./mymodule.mjs")
2. import.meta: 현재 실행중 모듈에 호스트에서 사용가능한 메타데이터 객체 설정
3. globalThis: 환경에 따라 다른 최상위객체 편히 접근.
4. BigInt: 새로운 primitive 숫자 타입. 기존의 최대정수값 이상 사용가능. BigInt(Number.MAX_SAFE_INTEGER) + 10n - 10n
5. Optional Chaning: data?.article
6. Nullish coalescing operator: null ?? "default"
7. export * as Foo from "module"
ECMAScript2021
1. 'a bb c'.replaceAll('', '_') // a_bb_c (원래는 정규식 써야했음)
2. Promise.any: 첨으로 fulfilled된 프로미스. 모두 에러나면 에러.
3. Numeric seperators: 1_000_000_000 (아 이게 이번스펙에 나온거구나)

# 1/19

# Promise.any와 Promise.race 의 차이

https://developer.mozilla.org/ko/docs/Web/JavaScript/Reference/Global_Objects/Promise/race https://github.com/domenic/promises-unwrapping/blob/master/docs/states-and-fates.md https://stackoverflow.com/questions/61732049/what-is-the-difference-between-promise-any-and-promise-race

ECMAScript2021에 Promise.any가 들어왔다. Promise.race와 비슷해보여서 차이를 찾아보았다.

const promises = [slowPromise, quickPromise];
Promise.race(promises)
  .then((value) => console.log(value))
  .catch(e); // 처음으로 fulfilled나 rejected된 프로미스. then 이나 catch에 잡힌다.
Promise.any(promises).then((value) => console.log(value)); // 처음으로 fulfilled된 프로미스. 만약 모든 promise가 에러나면 AggregateError 난다

Promise 참고
- 용어
  - settled: fulfilled나 rejected
  - fulfilled: 성공적으로 done
- 상태
  - fulfilled: 성공 done
  - rejected: 실패 done
  - pending
- Promise의 운명(Fates)
  - resolved: fulfilled나 rejected되었을때
  - unresolved:

# 1/20

# Deno

https://deno.land/ https://blog.ull.im/engineering/2019/04/14/deno-ryan-dahl-2019-04-04.html https://han41858.tistory.com/50

JS랑 TS 런타임. V8사용. Rust로 만듦. Node.js를 만든 Ryan Dahl이 만듦.
실행가능한 하나의 deno만듦.
Node.js와의 차이
1. 모듈 사용할때 npm안쓰고 URL이나 파일패스로. 모듈 위한 package.json도 x.
2. 모든 비동기처리를 promise로.
3. 핸들링안된 에러 만나면 쥬금
4. require못쓰고 ESM씀
remote코드는 페치하면 --reload 하기 전까진 캐싱되어있음. URL/파일로 가져온 모듈들도.
개발 이유: 09년에 Node만들었다. 아직 자바스크립트가 구릴때. 웹서버로 시작했고, 모듈들은 node_modules에 다 넣음(디자인적 아쉬움) -> 그래서 npm과 같은 중앙서버가 있어야했다. 웹은 분산형태가 맞는데. 글구 보안도 아쉬움(리소스 권한설정 불가)
1. Deno는 Node의 디자인실수를 교정하기 위해 호환성을 과격히 깨부림: ESM사용, 보안강화, 브라우저호환성유지. npm 필요없이 url로 리소스 다운.

간단한 http 서버

import { serve } from "https://deno.land/std/http/server.ts";

async function main() {
  let s = serve(":8000");
  console.log(s);
}

main();

# 1/21

# PoC

https://engineer-mole.tistory.com/35

Proof of Concept. 새 프로젝트가 실현 가능성이 있는지 기술적인 관점에서부터 검증.
프로젝트의 불확실한 요소를 지우는게 목표.
시제품 만들기 -> 사용해보면서 검증 -> 실현여부 판단

# 1/23

# Bundlephobia

https://bundlephobia.com/

번들별 사이즈, 다운로드 시간 검색 사이트
package.json 올려서 한번에 스캔 가능
아무 플젝 스캔해봤더니 ts번들이 무겁네 2.3MB. 3g에서 12.4s가 걸린다는데 로딩이 이렇다는게 말이 되나? 컴파일러로 돌린 이후엔 프로덕션에선 돌릴 일이 없어서 무시해도 되는건가. 그나저나 초 위에 마우스 올리면 그 초에 맞춰서 애니메이션이 재생되는게 재밌다.

# 1/24

# 리액트 서버 컴포넌트

https://reactjs.org/blog/2020/12/21/data-fetching-with-react-server-components.html https://twitter.com/dan_abramov/status/1342261577475633154

서버에서만 실행되는 새로운 컴포넌트. .server.js확장자. 백엔드 리소스(db, filesystem, internal API) 직접접근 가능. (js확장자인 Shared컴포넌트도 만들었음. 서버랑 클라이언트 둘다 사용.)
props는 아무거나 다 가능. 다만 Server컴포넌트에서 Client컴포넌트로 props내릴땐 시리얼라이즈 해야함. 네트워크 통신 하거덩.
클라이언트까지 오지 않고 데이터 fetching과 로직수행을 할 수 있다.
SSR과의 차이
1. SSR: 초기 HTML스냅샷 제공. 페이지 로드되기 전에 돌고 그 다음엔 JS코드 다운로드 해야함. 동기로 일어남(서버 데이터를 못 가지고 있음. prepass등 쓸 수 있지만 이상적인 방법은 아님.)
2. Server 컴포넌트: 확장HTML(HTML로 렌더될거임)(refetch도 가능)을 초기렌더에 보여줌. 비동기로 데이터 가져올 수 있음.

// Note.server.js - 서버 컴포넌트

import db from "db.server";
import NoteEditor from "NoteEditor.client"; // 클라이언트 컴포넌트

function Note(props) {
  const { id, isEditing } = props;
  const note = db.posts.get(id); // 렌더중에 바로 db접근 가능

  return (
    <div>
      <h1>{note.title}</h1>
      <section>{note.body}</section>
      {/* 다이나믹 렌더링 가능 */}
      {isEditing ? <NoteEditor note={note} /> : null}
    </div>
  );
}

# RFC

https://github.com/reactjs/rfcs

Request For Comments. 새로운 기능을 내보내기 전에 사람들 의견 먼저 수집.
언제 쓰냐: 리액트에 실질적인 변경 일으키려할때. 프로포절 내기 전에 의견받기 좋다.
1. 새로운 API쓰는 피쳐
2. 릴리즈 채널에 이미 공유된 피쳐 삭제 (<- 이건 왜지?)
3. 새로운 컨벤션 만들때
예시: 서버 컴포넌트 RFC (opens new window).

# 1/29

# SSR

https://d2.naver.com/helloworld/7804182

SSR: 서버에서 화면 구성해서 클라에 보내줌(CSR보단 느림) - 리액트가 실행되고 페이지가 Interactable됨. SEO도 쉽게 가능.
단계
1. Server Rendering: 완전 서버사이드. (Gmail)
2. Static SSR: SPA처럼 개발되지만 모든 페이지가 빌드 step에서 static HTML로 prerender된다. (Docusaurus)
3. SSR with (Re)hydration: SPA처럼 개발됨. 서버가 페이지들 prerender하지만 전체 앱이 클라이언트에서도 부팅됨. (Next.js)
4. CSR with Prerendering: 빌드타임에 initial shell/skeleton이 빌드시에 prerender된다.(Gatsby, Vuepress)
5. Full CSR: 모든 로직이 프론트에서만.

# 나의 궁금증들

Next.js에서 router.push할 때 global scope에 저장해둔 변수가 날아가지 않는 이유는? SSR은 매 페이지마다 서버를 왔다갔다하면 브라우저가 리프레시되며 날아가야 하지 않는가?
초기 데이터 페칭부터 서버에서 할 방법은 없는가? 그래야 로더 없이 빨리 보여줄 수 있는게 아닌가? 비동기 데이터에 의존하는 UI가 대부분일텐데.
SSR을 빠른렌더 위해 효과적으로 사용하는 방법. FullScreenLoader를 쓰면 SSR의 장점을 모두 쓰는게 아니라던데.

# 1/31

# 웹 렌더링 -

https://developers.google.com/web/updates/2019/02/rendering-on-the-web#terminology

용어
1. SSR: 클라로 만든 앱을 서버의 HTML로 렌더링
2. CSR: 브라우저에서 렌더링
3. Rehydration: 서버에서 렌더한 HTML의 DOM트리와 데이터 재사용가능하도록 자바스크립트뷰를 '부팅'
4. Prerendering: 빌드타임에 클라 애플리케이션을 실행해서 초기상태를 정적HTML로 캡쳐
5. TTFB (Time to first byte): 링크 클릭후 처음으로 들어오는 콘텐츠비트 시간
6. FP(First Paint): 픽셀이 첨으로 표시되는 시간
7. FCP(First Contentful Paint): 요청 콘텐츠가 표시되는 시점
8. TTI(Time To Interactive): 페이지가 상호작용 가능한 시점
서버 렌더링
1. 빠른 FP와 FCP. 서버에서 페이지 생성시간때매 TTFB는 느려짐.
2. Next.js나 Nuxt 등 솔루션은 Hydration사용함 <- 알아둬야함!
3. 서버에서 다 만들고, 클라에선 최소한의 js만 실행시킴
4. 예시
  1. Netflix: 랜딩페이지는 정적으로, 상호작용 많은 페이지는 JS를 프리패치로 유연하게.
정적 렌더링
1. 빌드때 다함(<->서버렌더링은 HTML을 즉석에서 생성해야 함). 일관적이고 빠른 TTFB
2. 단점: 모든 URL의 개별 HTML파일 생성해야함. URL이 미리 예측불가하면 못씀.
3. JS비활성화해도 사용가능하면 보통 정적렌더링. 더 많은 js를 받아와야한다면 사전렌더링일 가능성이 높음.
클라이언트 측 렌더링
1. 앱이 커짐에 따라 js가 무거워짐. js를 쪼개서 필요한것만 필요할때 제공해야함.
2. 쉘캐싱 + PWA로 빠르게 할 수 있음ㅁ

← 2021.02 2020.11-12 →