이번에 새로운 책을 샀다! 무려 배민에서 나온 책인데 여태 책들과는 다르게 React에 관한 내용들도 있고, 무엇보다 이 책의 저자가 시니어들이 아닌 주니어라는 것!
그렇기에 많은 공감되는 마음으로 책을 읽을 수 있을 것 같고 요즘 객체에 대한 지식이나 TS, JS에 기초에 대해 다시 관심이 많았기 때문에 (회사의 노예라 그저 일만...) 다시 초심으로 돌아가서 면접을 준비하듯 준비해볼 계획이다!
물론 이번 책도 내가 외우고 싶거나 흥미로운 주제만을 쓸 것이기 때문에 :) 이번에도 화이팅 해보겠도다!
1장 들어가며
1.1 웹개발의 역사
1. 자바스크립트의 탄생
1995년에 넷스케이프의 브랜든 아이크는 웹의 다양한 콘텐츠를 표현하기 위해, 자바스크립트를 만들었음
심지어 별로 유명하지 않던 객체 지향 언어닌 Self의 프로토타입 기반 상속 Lisp 계열 언어인 스킴 (Scheme)의 일급함수를 차용한 경량의 프로그래밍 언어
JS언어 개발을 무려 단 10일만에 함.. a.k.a. 십일만에 웹 역사를 바꾼 사람
2. ECMAScript의 탄생
넷스케이프와 마이크로소프트는 자신들의 브라우저에 새로운 기능을 빠르게 늘리기 시작했지만, 이것들은 각각 자기의 브라우저에서만 동작함
초기의 JS는 브라우저 생태계를 고려하여 작성된 것이 아니었음
결국 자바스크립트와 브라우저의 발전속도 간의 차이가 나기 시작했고 자바스크립트를 따라갈 순 없었음
JS에 어떤 기능이 추가되면 런타임인 브라우저도 이 기능을 지원해야했기 때문
이런 문제를 해결하기 위해 자바스크립트에 폴리필(polyfill)과 트랜스파일(transplie) 같은 개념이 등장
폴리필과 트랜스파일?
폴리필은 브라우저가 지원하지 않는 코드를 브라우저에서 사용할 수 있도록 변환한 코드조각 or 플러그인
트랜스파일은 최신 버전의 코드를 예전 버전의 코드로 변환하는 과정
둘 다 최신 기능을 구버전에서 동작할수록 있도록 해줌
폴리필의 대표 기능 - core.js / polifill.io
트랜스파일러 - 바벨
하지만 이런 라이브러리가 있다하더라도 모든 크로스브라우징 이슈를 해결할 순 없었기에 ECMAScript라는 이름으로 자바스크립트 표준화를 공식화
3. 웹사이트 to 웹 애플리케이션으로의 변환
웹사이트
웹사이트는 수집된 데이터 및 정보를 특정 페이지에 표시하기 위한 정적인 웹
단방향인 정보를 제공하기에 사용자와 상호 작용하지 않고,
HTML에 링크가 연결된 웹페이지 모음으로서 콘텐츠가 동적으로 업데이트 되지 않음
웹 애플리케이션
사용자와 상호작용하는 쌍방향 소통의 웹 (우리가 흔히 알고 사용하는!)
본격적으로 웹 애플리케이션 시대의 서막을 연 건 Google Map
4. 개발 생태계의 발전
하나의 웹페이지를 통으로 개발하는 것이 아닌 컴포넌트 단위로 개발하는 방식이 생김
또한, Ajax로 페이지 전체를 새로고침 하지 않아도 자바스크립트의 비동기를 통한 페이지 일부 데이터를 로드할 수 있게 됨
-> 이렇게 되었기에, 사용자마다 부분적으로 다른 화면을 렌더링할 수 있게 됨
웹 서비스가 애플리케이션이 되고, 다뤄야 하는 데이터 그리고 수많은 디바이스의 연결 등으로
CBD라는 개념이 생김
컴포넌트 베이스 개발 (Component Based Development, CBD) 방법론
재사용할 수 있는 컴포넌트를 개발 또는 조합하여 하나의 애플리케이션을 만드는 개발 방법론
즉, 서비스에서 다루는 데이터를 구분하고 그에 맞는 UI를 표현할 수 있게 컴포넌트 단위로 개발하는 방식
요즘은 작은 컴포넌트를 조합해서 더 큰 컴포넌트를 만드는 것이 주류
컴포넌트는 하나의 독립된 기능을 재사용하기 위한 코드 묶음
하지만, 모듈과는 달리 런타임 환경에서 독립적으로 배포 및 실행될 수 있는 단위
컴포넌트는 의존성을 없애야함 하지만 작은 기능일수록 독립적이지만 조합 과정에서 필연적으로 의존성이 생김
1.2 자바스크립트의 한계
1, 동적 타입 언어
자바스크립트의 큰 특징 중 하나는 동적 타입 언어라는 것
런타임에 변숫값이 할당할 때 타입에 따라 변수 타입이 결정
(실제 코드가 동작할 때 a에 값이 할당될 때 그 순간, 그 값이 1인지 '1'인지에 따라 결정)
2. 동적 타이핑 시스템의 한계
개발자의 의도와 다르게 동작할 수 있음
JS는 동적 타입언어이자 관대한 언어기 때문에 sumNumber 함수를 호출할 때 사요되는 인수값에 따라 타입이 결정됨
3. 한계 극복을 위한 해결 방안
개발자들은 자바스크립트 인터페이스의 필요성을 느끼게 되었고 JSDoc, PropTypes, 다트 같은 해결 방안이 등장
JSDoc - API 문서 생성 도구 주석에 @ts- check 를 추가하여 타입 및 에러 확인
뿐만아니라, 자바스크립트 소스코드에 타입 힌트를 제공하는 HTML 문서 생성 가능
하지만 주석의 성격이라 강제성을 부여해 사용하기는 어려움
PropsType - 리액트에서 컴포넌트 props의 타입을 검사하기 위해 사용하는 속성
prop에 유효한 값이 전달되었는지는 확인할 수 있지만, 전체 애플리케이션의 타입 검사를 할 때는 사용 못하고, 리액트에서만 사용 하다는 단점
다트 - JS를 대체하기 위한 언어지만, JS를 대체할 수 없었음
4. TS의 등장
자바스크립트의 슈퍼셋 언어
슈퍼셋
기존 언어에 새로운 기능과 문법을 추가하여 보완하거나 향상하는 것
기존 언어와 호환되고 기존 언어 코드로 변환되어 실행됨
안정성 보장
TS는 정적 타이핑 -> 컴파일 단계에서 검사 (런타임 에러를 사전에 방지)
개발 생산성 향상
타입 자동 완성 기능 제공, prop의 타입을 사용부에서 바로 검사 가능
협업에 유리
인터페이스, 제네릭등을 지원하여 전체 코드를 쉽게 파악
