TypeScriptSTUDY _ 1장 . 들어가며...

zeroha·2024년 11월 17일

우아한타입스트립트with리액트 우아한테크

TypeScriptStudy

목록 보기

1/32

1.1 웹 개발의 역사

.
.
.

1. JSscript의 탄생

1995년 넷스케이프의 브랜든 아이크는 웹의 다양한 콘텐츠를 표현하기 위해 이미지, 플러그인 요소를 쉽게 조합할 수 있는 새로운 언의 필요성을 느끼고 개발.

2. 자바스크립트 표준, ECMAScript의 탄생

크로스 브라우징 이슈 발생 -> 브라우저가 자바스크립트의 변화를 따라가지 못함.
새로운 버전 브라우저 - 자바스크립의 새로운 기능 개발
...but 예전 버전의 브라우저를 써버리면 무용지물
이를 해결하기 위해
폴리필 & 트랜스 파일 등장,
모든 브라우저에서 동일하게 동작하는 표준화된 자바스크립트 필요성 제기 -> ECMASxript의 등장

Cross Browsing : 인터넷 익스플로러와 내비게이터의 DOM구조는 완전히 다르기 때문에 브라우저마다 웹 페이지가 다르게 동작하거나 제대로 동작하지 않음.
polyfill : 지원하지 않는 코드를 브라우저에서 사용할 수 있도록 변환한 코드 조각이나 플러그인
transpile : 최신 버전의 코드를 예전 버전의 코드로 변화하는 과정

3. 웹사이트 -> 웹 애플리케이션 전환

웹사이트
: 수집된 데이터 및 저보를 특정 페이지에 표시하기 위한 정적인 웹
: 단방향 정보 제공 ( 사용자와 상호작용 x )
: HTML에 링크가 연결된 웹 페잊 모음 -> 콘텐츠가 동적으로 업데이트 x
웹 애플리케이션
: 방향 정보 제공 ( 사용자와 상호작용 o )
: 현재 대부분의 웹 사이트 ( 대표 : 구글 지도 Google Map )

기존의 웹 개발 환경 : 대규모 웹 애플리케이션을 만드는데 적합 x -> 변화 필요

4. 개발 생태계의 발전

하나의 웹페이지 통으로 개발 x -> 컴포넌트 단위로 개발하는 방식 o
: 사용자마다 부분적으로 다른 화면을 렌더링 o

과거의 웹
: 주로 PC와 연결
: 디스플레이 종류 제한적
요즘의 웹
: 수많은 디바이스와 연결
: 디스플레이 종류(모아일, 패드, 랩톱pc...) 매우 다양

-> 이런 상황과 맞물려 컴포넌트 베이스 개발( CBD )등장

컴포넌트 베이스 개발( Compoment Based Development, CBD )
: 재사용할 수 있는 컴포넌트를 개발 또는 조합해서 하나의 애플리케이션을 만드는 개발 방법론, 서비스에서 다루는 데이터를 구분하고 그에 맞는 Ui를 표현할 수 있게 컴포넌트 단위로 개발

컴포넌트 : 모듈과 유사하게 하나의 독립된 기능을 재사용하기 위한 묶음
( 모듈과는 달리 런타임 환경에서 독립적으로 배포.실행할 수 있는 단위 )

따라서 개발자는 컴포넌트 간의 의존성을 파악해야 하고, 제대로 컴포넌트를 사용하고 변화에 대응해야 한다.

의존성 : 대상의 변경에 영향받을 수 있는 가능성

5. 개발자 협업의 필요성 증가

개발에 투입된 인원이 많아질수록 코드를 파악하기 어려워지는 것은 당연 -> 협업 필요

1.2 자바스크립트의 한계

.
.
.

1 . 동적 타입 언어

자바스크립트 = 동적 타입 언어
: 변수에 타입을 명시적을 지정 x -> 런타임에 변숫값이 할당될 때 해당 값의 타입에 따라 변수 타입이 결정
ex) 변수 a의 타입이 number인지 string인지 결정되는 때 = 코드가 동작할 때 a에 할당되는 순간, 그 값이 1인지 '1'인지 결정

2. 동적 타이핑 시스템의 한계

const sumNumber = (a,b) => {
	return a+b;
};

sumNumber(1,2)//3

정상작동 o

const sumNumber = (a,b) => {
	return a+b;
};

sumNumber(100)//NaN
sumNumber("a","b")//ab

정상작동 o ... but 개발자 의도와는 다르게 동작
-> 자바스크립트는 동적 타입 언어이자 상당히 관대한 언어...
sumNumber 함수를 호출할 때 사용되는 인수 값에 따라 a와 b의 타입이 결정.
b가 undefined이기 때문에 +연산자의 피연산자가 될 수 없지만 오류 발생 x, b를 적절한 타입인 NaN으로 형변환 다음 실행

3. 한계 극복을 위한 해결 방안

협업의 필요성 o -> 자바스크립트 인터페이스의 필요성 o

< 해결방안 >

JSDoc : API 문서 생성 도구

주석에 @ts- checkfmf cnrk : 타입 및 에러 확인이 가능
강제성을 부여해 사용하기 어렵다

propTypes : 리액트에서 컴포넌트 props의 타입 검사

전체 애플리케이션의 타입 검사를 하는데 사용 x
리액트라는 특정 라이브러리에서만 사용 o

다트Dart : 자바스크립트 대체 구글에서 나온 새로운 언어

근본 해결 x , 개발 파편화

4. 타입스크립트의 등장

마이크로소프트는 자바스크립트의 슈퍼셋언어인 타입스크립트 공개

슈퍼셋 : 기존언어에 새로운 기능&문법 추가 , 기능 보완
기존 언어와 호환, 일반적으로 컴파일러 등으로 기존 언어 코드로 변환되어 실행

안전성 보장
: 정적 타이핑을 제공 ( 타입 에러를 줄임 )
개발 생산성 향상
: VSCode 등의 IDE에서 타입 자동 완성 기능을 제공(:변수와 함수 타입 추론 o), props 매번 확인 x
협업에 유리
: 인터페이스.interface, 제네릭.generic 등을 지원 -> 코드 더 쉽게 이해 o

타입스크립트 인터페이스 (interface)
: 객체 구조를 정의하는 역할 , 특정 객체가 가져야 하는 속성과 메서드의 집합을 인터페이스로 정의 -> 객체가 그 구조를 따르게

자바스크립트에 점진적으로 적용 가능
: 점진적 도입 가능 = 전체 프로젝트x, 일부 프로젝트o, 일부 기능o 에서부터 점진적으로 도입 가능

_ 도서 참조 : 우아한 타입스크립트 with 리액트

zeroha

하 영

다음 포스트

TypeScriptSTUDY _ 1장 . 들어가며...