프론트엔드Explorer

TypeScript는 왜 사용할까?

버그를 줄일 수 있기 때문에 유지보수가 쉬워지고, 이는 곧 질 좋은 코드이니까! 

TypeScript는 JavaScript의 Superset!

TypeScript는 완전히 새로운 언어가 아니다. 

JavaScript를 기반으로 한 언어라는 뜻. 

TypeScript는 JavaScript 코드를 보다 쉽게, 강력하게 작성하도록 도와주는 좀 더 나은 버전의 JavaScript이다. 

TypeScript의 특징: 타입 표기

JavaScript와는 달리, 변수를 정의할 때 데이터 타입을 지정할 수 있다. 

타입을 표기하면 코드가 좀 더 예측 가능하며, 디버깅하기가 쉽다. 

아래 코드를 보면, 왜 타입을 표기하는 것이 좋은지 알 수 있다. 

// JavaScript
function add(a, b){
	return a + b; 
}

console.log(add('3', '5')); // 결과는 35, 어떤 에러 메시지도 출력하지 않음


// TypeScript
function add(a: number, b: number){
	return a + b;
}

console.log(add('3', '5')); // 컴파일 에러 메시지 출력

JavaScript로 작성된 코드는 argument가 string이라도 어떤 에러 메시지도 출력하지 않고,

string을 합쳐버린다. 

반면, TypeScript는 parameter의 type이 number이기 때문에, 

argument에 string을 넣은 경우, 컴파일 에러 메시지를 출력한다. 

*컴파일 에러는 무엇일까?

말그대로, 컴파일 시 나타나는 에러이다. 

컴파일은 어떤 언어의 코드를 다른 언어로 바꿔주는 변환 과정이다. 

TypeScript는 JavaScript 환경에서 실행될 수 없다. 

왜냐하면, JavaScript가 실행될 수 있는 브라우저가 TypeScript 코드를 이해하지 못하기 때문이다. 

그래서 TypeScript로 작성된 코드는 JavaScript로 컴파일 되어야 한다. 

즉, TypeScript는 프로그래밍 언어이자, TypeScript를 JavaScript로 바꿔주는 컴파일러이다!

이 포스팅은 아래 링크를 참고하여 작성했습니다.

https://www.youtube.com/watch?v=VJ8rvsw2j5w&t=211s

아래 포스팅에 자세히 설명을 해두었다. 

dolphinsarah.tistory.com/21?category=467228

그래도 간단히 설명해보자면, map을 도는 배열의 key를 고유한 값으로 설정하라고 하는 것은,

그렇게 하지 않았을 때 => 배열 전체가 리렌더링 될 필요가 없음에도 리렌더링 되는 것을 방지하기 위해서다.  

이를테면, push를 통해 아이템이 배열 끝에 추가될 경우, 마지막 요소만 변경되었으니 전체를 리렌더링할 필요가 없는 경우. 

아래와 같이, 복사하기 버튼을 눌렀을 때 클립보드에 텍스트를 복사하려면 어떻게 해야할까? 

Document.execCommand()를 사용하거나 Clipboard API를 활용하는 방법도 있다.  

Document.exeCommand()

아래는 exeCommand()에 대한 MDN의 설명이다. 

When an HTML document has been switched to designMode, its document object exposes an execCommand method to run commands that manipulate the current editable region, such as form inputs or contentEditable elements.

즉, HTML document가 디자인 모드로 바뀌면서 exeCommand를 사용하면, form의 input과 같이 편집이 가능한 element를 조작할 수 있다는 것이다. 그래서 element의 내용을 클립보드로 복사할 수 있게 되었다고 이해하면 좋을 것 같다. 

따라서, 어떤 element의 innertext를 복사하고자 한다면, 그 element가 editable한 input이나 textarea여야 한다. 

만약, 해당 element가 input이나 textarea가 아니라면, 아래의 코드처럼 textarea를 만들었다가 지우는 방식을 사용하면 된다. 

    const pinyin = pinyinRef.current.innerText;
    const textField = document.createElement('textarea');
    textField.innerText = pinyin;
    document.body.appendChild(textField);
    textField.select();
    document.execCommand('copy');
    textField.remove();

pinyinRef가 내가 복사하려고 하는 text를 가지고 있는 element를 참조하는 ref 객체이다. 

그래서 그 pinyinRef.current의 innerText(복사하고자하는 텍스트)를 가져와서 textField라는 임시 textarea의 innerText로 넣어준다. 

document에 임시 textarea를 붙여주고, 그 textarea를 select하여 복사하고자 하는 텍스트를 선택하고, 

document.execCommand('copy')를 사용하여 해당 텍스트를 클립보드에 복사한다. 

그리고 다시, 임시 textarea를 지워주면 된다. 

하지만, Document.execCommand()는 MDN 문서에서 알 수 있듯 더 이상 추천하지 않는 방식이다. 

대신, clipboardAPI를 사용한다. 

Clipboard API

Clipboard API는 Promise 기반으로 클립 보드 내용을 비동기적으로 접근할 수 있는 API이다. 

아주 아주 간단하다. 

		const pinyin = pinyinRef.current.innerText;
		navigator.clipboard.writeText(pinyin);

navigator.clipboard.writeText 만을 사용해서 가능하다. 즉, 붙여넣고자 하는 text를 인자로 넣어주면 된다. 

next에서 antd가 적용이 안 되고 있는 것 같다면, 

모든 페이지에서 공통으로 적용되게 하는 pages 폴더 아래, _app.js 파일에 다음 문장이 import 되어 있는지 확인하자. 

import 'antd/dist/antd.css';

antd.css를 import해야 antd 적용이 가능하다. 

쓰로틀링(throttling)과 디바운싱(debouncing). 이름은 꽤 들어봤는데, 언제, 왜 쓰는지 잘 몰라서 정리해보려고 합니다. 

쓰로틀링은 마지막 함수가 호출된 후 일정 시간이 지나기 전에 다시 호출되지 않도록 하는 것입니다. 예를 들어, 스크롤을 올리거나 내릴 때, 스크롤을 움직이는 내내 함수가 호출되면 곤란하겠죠? 이럴 때, 일정 시간이 지나기 전에는 다시 호출하지 않는 쓰로틀링을 사용합니다. 

디바운싱은 연이어 호출되는 함수들 중 마지막 함수(또는 제일 처음)만 호출하도록 하는 것입니다.

예를 들어, 검색창에 '돌고래'라는 검색어를 입력할 때 한 글자 한 글자('ㄷ', '도', '돌' ...) 칠때마다 ajax 요청이 실행됩니다. 

이렇게 한 글자 한 글자에 대해 모두 요청이 가면, 유료 API를 사용하게 될 경우 심각한 비용 문제를 낳을 수 있습니다. 던지는 쿼리 하나 하나가 다 돈이기 때문입니다. 

그러면 '돌고래' 라는 검색어를 다 입력한 후에 ajax 요청을 보내는 것이 좋겠죠? 

어떻게 구현하는 게 좋을까요? '돌고래'를 입력할 때, '돌' 치고 한참 후에 '고' 이런 식으로 입력하지 않고, 대부분의 사람들은 한 번에 '돌고래'라고 입력하지 않을까요? 그러면 이렇게 검색어의 입력이 다 끝난 후에 ajax 요청을 보내면 됩니다. 

검색어를 입력할 때(input 이벤트 발생)마다 타이머를 설정합니다. 이때, 예를 들어, 200ms동안 입력이 없으면, 입력이 끝난 것으로 치고, 만약, 200ms 이전에 타자 입력이 발생하면 이전 타이머는 취소하고 다시 새로운 타이머를 설정하면 됩니다. 

let timer; 
document.querySeletor('#input').addEventListener('input', function(e){
	if(timer){clearTimeout(timer);}
   	timer = setTimeout(function(){ 
    		console.log('200ms가 지났으니, 이제 ajax 요청을 보냅니다.', e.target.value); 
    	}, 200); 
}); 

이렇게 설정하면, 매번 검색어를 입력할때마다 호출되지 않고, 더 이상 입력이 없을 때, ajax 요청을 보냅니다. 이게 디바운싱입니다. 

쓰로틀링은 보통 성능 문제 때문에 많이 사용한다고 합니다. 스크롤을 올리거나 내릴 때를 생각해보면, scroll 이벤트가 매우 많이 발생합니다. scroll 이벤트가 발생할 때 복잡한 작업을 실행하도록 설정했다면, scroll 이벤트가 매우 빈번하게 실행되기 때문에 렉이 엄청나게 걸릴 것입니다. 이럴 때 쓰로틀링을 걸어둡니다. 몇 초에 한 번, 혹은 몇 밀리초에 한 번씩만 실행되게 제한을 걸어 두는 것입니다.  

위에서 디바운싱으로 구현했던 ajax 검색을 쓰로틀링으로 대체해도 됩니다. 똑같이 200ms 제한을 걸어둡니다. 타이머가 설정되어 있으면 아무 동작도 하지 않고, 타이머가 없다면 타이머를 설정합니다. 타이머는 일정 시간 후에 스스로 해제하고, ajax 요청을 날리게 하면 됩니다. 

let timer;
document.querySelector('#input').addEventListener('input', function(e){
	if(!timer){
    		timer = setTimeout(function(){
        		timer = null; 
            		console.log('200ms가 지나면 ajax 요청', e.target.value); 
         	}, 200);
   	}
}); 

이렇게 설정하면 200ms마다 요청을 보내게 됩니다. 물론, 디바운싱으로 구현하는 게 요청을 덜 보내게되겠지만, 중간 중간 검색 결과를 보여주고 싶다면 쓰로틀링도 나쁘지 않은 방법인 것 같습니다. 

아래 링크를 참고하여 작성했습니다.

www.zerocho.com/category/JavaScript/post/59a8e9cb15ac0000182794fa

해외 디자인 아티클 번역 뉴스레터 '디독'의 'OK 버튼은 왜 오른쪽에 있을까?'를 정리한 글입니다. 

디자이너들은 종종 대화 상자에서 'OK'와 '취소' 버튼이 어떤 배치로 있는 것이 좋은지 고민한다고 한다. 

'OK' 버튼은 태스크를 완료하기 위한 핵심 동작이고, '취소' 버튼은 사용자가 작업을 완료하지 않고 원래 스크린으로 돌아가기 위한 보조 동작이다. 

'취소' 버튼은 'OK' 버튼 앞에 와야 할까? 뒤에 와야 할까? 

일부 디자이너들은 보조 액션보다 주된 액션을 왼쪽에 두는 것이 더 가깝고, 클릭하기까지의 시간이 적기 때문에 사용자에게 더 좋을 것이라고 생각한다고 한다. 

하지만, 사용자가 어떤 행동을 하기 전에 모든 옵션을 본다는 사실을 무시할 수는 없다. 즉, 대부분의 사용자가 옆에 있는 보조 액션 버튼을 보지 않고 주된 액션 버튼을 맹목적으로 클릭하지는 않는다는 뜻이다. 

만약, 'OK' 버튼이 왼쪽에 있고 '취소' 버튼이 오른쪽에 있다면, 'OK' 버튼을 보고, '취소' 버튼을 보고, 다시 'OK' 버튼을 볼 것이다. 

즉, 'OK' 버튼이 왼쪽에 있을 때 시각적인 고정이 더 많아지고, 여러가지 방향으로 흐르게 된다. 

아래처럼 'OK' 버튼이 오른쪽에 있다면 시각적인 고정이 줄어들고, 한 방향으로 흐를 수 있다. 

즉, 주된 액션을 왼쪽에 두면 더 쉽게 도달할 수는 있지만, 정신적인 프로세스와 시각적 고정의 관점에서 주된 액션을 오른쪽에 두는 게 실제로 더 빠르다. 

Redux란? 

Redux는 JavaScript app을 위한 predictable state container이다. React의 보완재 역할을 하는데, action에 반응하여 상태를 변경하기 때문에 React처럼 UI를 상태에 대한 함수로 기술하는 framework와 잘 어울린다. 

React에 Redux가 필요한 이유? 

React로 프로젝트를 진행했을 때, component는 local state를 가지고 application은 global state를 가지게 된다. local state는 각각의 component가 가지는 state, application은 이 state를 기반으로 만들어진다.  global state는 예를 들어, 유저의 로그인 유무에 따라 application의 state가 달리 보인다고 할 때, application 전체에서 global state는 유지, local state는 global state를 공유하게 되는 것이다. 

local state의 전달이 어려워서 

React로만 프로젝트를 진행하게 될 경우, application이 local state, global state를 관리하기 어렵다. 예를 들어, shopping mall에서 장바구니를 관리하기 위해 최상단 Component인 App.js에서 cart state를 만들고, 각각의 Component에 이를 props로 전달하여 프로젝트를 관리했다고 하자.

프로젝트 규모가 작을 때는 단 한 번의 data 이동으로 cart state가 전달된다. 하지만, 프로젝트의 규모가 커지고 Component 수가 늘어난다면 어떨까? 단순히 cart state를 CartItem.js로 전달하고 싶을 뿐인데, 이를 위해 cart props를 사용하지 않는 Component에도 cart props를 전달하게 된다. 

즉, 프로젝트 규모가 커질수록 props로 data를 전달하기 위해 위와 같은 필요 없는 data의 흐름이 생기게 된다. 그리고 만약 CartItem.js로 cart props가 제대로 전달이 되지 않을 경우, 중간에 낀 모든 Component에서 일일이 문제점을 찾아봐야 한다. 

global state의 유지가 어려워서 

Shopping mall을 포함한 대부분의 application에서는 로그인 기능이 구현되어야 한다. 유저의 개인 정보, 결제 정보 등이 있어야 하기 때문이다. 하지만 React만으로 프로젝트를 진행할 경우, global state를 모든 Component에 유지하기가 어렵다. 유저의 인증 정보를 모든 Component에 props로 계속해서 전달해야 하는데, 이때 복잡한 절차를 거쳐야 한다.

하지만 Redux를 사용하게 되면 하나의 store를 통해 global state를 포함한 모든 state를 저장하고 유지할 수 있게 되고, 원하는 Component로만 data를 전달할 수 있게 되어 위와 같은 문제가 해결된다.  

Flux 구조

Flux는 대규모 프로젝트에서 너무 복잡해지는 MVC 구조 단점을 보완하는 단방향 데이터 흐름의 구조이다. Redux는 Flux의 몇 가지 중요한 특성에 영감을 받아 개발되었다. Redux는 Flux 패턴을 좀 더 쉽고 정돈된 형태로 쓸 수 있게 도와주는 라이브러리라고 볼 수 있다.

Redux 기본 개념

Actions

Application의 store, 즉 저장소로 data를 보내는 방법. view에서 정의되어있는 action을 호출하면 action creators는 application의 state를 변경해준다.

Reducer

Action을 통해 어떠한 행동을 정의했다면, 그 결과 application의 상태가 어떻게 바뀌는지 특정하게 되는 함수. Action의 type에 따라 변화된 state를 반환하게 된다.

Store

'무엇이 일어날지'를 나타내는 action, action에 따라 상태를 수정하는 reducer를 저장하는 application에 있는 단 하나의 객체.

*잘 정리된 다른 분의 블로그 글을 참고, 요약했습니다. 

medium.com/@jsh901220/react%EC%97%90-redux-%EC%A0%81%EC%9A%A9%ED%95%98%EA%B8%B0-a8e6efd745c9

UX에서 white space란?

White Space는 디자인 레이아웃을 만들 때 매우 유용한 테크닉이다. 

It's important when you're putting together a design layout that you let elements on the page breathe. The best way to do that is by introducing what's known as white space.

How to make White Space?

White Space를 만드는 것은 어렵지 않다. 각 element가 text든 image든 graphic이든 그들 사이에 공간을 만들어주면 된다. 각 요소들이 자신만의 visual focus를 받을 수 있도록 각 요소 사이에는 충분한 여백을 넣어줘야 한다. 

That way when someone is viewing your design they can get an easy feel for it and they can take on board what you are trying to say. Due to this, empty space is a legitimate design element that has a great influence on the user experience.

Negative Space, Empty Space라고도 불리는 White Space가 꼭 White일 필요는 없다. 어떤 컬러든, 어떤 텍스쳐든 패턴이든 Background Image든 상관 없다.

Types of White Space

웹사이트와 모바일 어플을 위한 UI Design을 할 때, White Space는 high usability와 navigation ability of the interface에 매우 중요한 역할을 한다.

두 가지 타입의 공간이 있는데, 
1. Macro space: This term refers to spaces between the main elements of a web page or mobile and the space around each part. 
2. Micro space: These are small gaps within an element. Line spacing in the text, gaps between pictures, separators, and more.

Why is negative space important? 

디자이너/클라이언트들은 되도록 많은 요소, 기능들을 한 페이지에 추가해야 소비자들에게 유용할 것이라고 생각하지만, 아니다.

Users do not need everything at once.

충분한 여백 없는 너무도 많은 요소들(Overloaded with information and interactive elements)은 distraction의 level을 높일 뿐이다. 사용자들은 그속에서 자신이 필요한 것을 찾기 위해 시간을 더 들이게 된다.

White space leaves separation between the content, it makes the important things stand out, and it creates balance.

Specific advantages of using whitespace

Easy page reading

content 사이에 공간이 충분하지 않다면, 읽기가 어려워지고 content를 파악하기 위한 노력이 필요하게 된다. Negative space의 밸런스를 맞추고, 특히 micro-space 를 잘 활용하면 reading process가 더 자연스러워질 수 있다. 

Improves the visual hierarchy 

Empty space는 사용자들이 content를 easy-to-read piece로 나눌 수 있게 해주고, detail에 집중할 수 있게 도와준다. 이것은 아티스트들이 stage에서 performance를 잠시 멈출 때와 유사한데, 리스너에게 파악하고 이해할 시간을 주는 것이다.

Design composition does not feel cluttered

Element들 사이의 여백이 충분히 확보되기 때문에 어수선하게 보이지 않는다. 즉, whitespace는 content의 easy accessibility와 ux를 향상시키는 데에 아주 좋은 도구이다.

Focuses the user's attention on the main elements

White space는 사용자의 눈이 search bar나 company logo에 집중하게 해준다. Whitespace의 도움으로 web page의 구조적 스트레스를 줄이고, 중요한 정보에 주의를 집중하게 할 수 있다. 

Adds style and elegance to the page 

White space 자체로 디자인 스타일을 unique하게 만들 수도 있다. White space를 활용한 디자인이 user에게 기억되어, 다른 경쟁사 사이트와의 구별점을 만들어내는 요소가 되기도 한다. 

Empty space는 그저 빈 공간이 아닌, 강력한 디자인 툴이다. 좋은 레이아웃을 만들기 위한 빈 공간 배치는 연습을 충분히 해야겠지만, 많이 만들어볼수록 많이 배우게 될 것이다. 

*위 포스트는 아래의 링크를 요약, 정리하였습니다.

link.medium.com/64PJsHiGY8

JSON

브라우저 위에서 동작하는 웹사이트나 웹어플리케이션과 같은 Client가 어떻게 Server와 통신할 수 있는지를 정의한 것이 바로 HTTP이다. HTTP는 Hypertext Transfer Protocal의 약자로, 어떻게 Hypertext를 서로 주고받을지를 규약한 프로토콜의 하나이다. Client는 Server에 data를 요청할 수 있고, Server는 Client에 응답하는 방식으로 진행된다. 그리고 여기서, Hypertext는 hyperlink, 문서, image 등 전반적인 resource를 일컫는다. 이렇게 Client가 Server와 데이터를 주고 받는 방식 중, 요즘 가장 많이 사용되는 것이 JSON이다. 아래가 그 예시이다. 

{
  "users": [
    {
      "Name": "gildong",
      "Nickname": "hong",
      "joined": {
        "month": "December",
        "day": 24
      }
    },
    {
      "Name": "sejong",
      "Nickname": "king",
      "joined": {
        "month": "November",
        "day": 13
      }
    }
  ]
}

JSON은 아래와 같은 특징을 가지고 있다. 

- Simplest data interchange format 

- Lightweight text-based structure 

- Easy to read

- Key-Value pairs

- Used for serialization(직렬화) and transmission of data between the network and network connection

- Independent programming language and platform (모든 언어, 플랫폼에서 사용가능하다는 점이 가장 좋은 점)

예를 들어, Client에서 토끼라는 object를 Server에 전송한다고 하면, {key: value}형태로 전송하면 된다. Server에서 다시 토끼를 받아올 때도, {key: value}의 string type으로 받아와서 다시 토끼라는 object로 변환해서 브라우저에 표기하게 된다. 

JSON 공부 Point

*serialization(직렬화) : 어떠한 데이터 구조를 송수신하거나 저장하기 위해 전송에 적합한 포맷으로 변환하는 과정.

Object를 어떻게 serialize(직렬화)해서 JSON으로 변환할지! 직렬화된 JSON을 어떻게 deserialize해서 Object로 변환할지!

Object to JSON

이때, 사용하는 것이 stringify()!

let json = JSON.stringify(true);
console.log(json); // object -> json: true

json = JSON.stringify(['apple', 'banana']);
console.log(json); // object -> json: ["apple", "banana"]

JSON to Object 

이때, 사용하는 것은 parse()!

json = JSON.stringify(rabbit); // json으로 만들었던 object를 
const obj = JSON.parse(json); // 다시 object로 만들고자 하면 parse를 쓰면 된다! 
console.log(obj); 

www.youtube.com/watch?v=FN_D4Ihs3LE

TypeScript는 왜 만들어졌나?

JavaScript는 C나 Java와 같은 C-family 언어와는 구별되는 특성이 있다. 

- Prototype-based Object Oriented Language 

- Scope와 this 

- 동적 타입(dynamic typed) 언어 or 느슨한 타입(loosely typed) 언어 

이와 같은 특성은 클래스 기반 객체지향 언어(Java, C++, C# 등)에 익숙한 개발자를 혼란스럽게 하며, 코드가 복잡해질 수 있고, 디버그와 테스트 공수가 증가하는 등의 문제를 일으킬 수 있다. 특히 규모가 큰 프로젝트에서는 주의하여야 한다. 

이런 Javascript의 태생적 문제를 극복하고자 AltJS(JavaScript의 대체 언어)가 등장하였다. 

TypeScript 또한 JavaScript의 대체 언어의 하나로, JavaScript(ES5)의 Superset(상위확장)이다.

TypeScript는 ES5의 Superset이므로 기존의 Javascript(ES5) 문법을 그대로 사용할 수 있다. 또, ES6의 새로운 기능을 사용하기 위해 Babel 같은 별도의 transpiler를 사용하지 않아도, ES6의 새로운 기능을 기존의 JavaScript 엔진(현재 브라우저 or Node.js)에서 실행할 수 있다.   

TypeScript 기초 of 기초

TypeScript와 JavaScript의 차이 

- TypeScript는 JavaScript와 달리 Type을 적는다. 

- JavaScript는 약타입 언어, TypeScript는 강타입 언어 

타입은 왜 적을까? 

- 코드가 조금 길어지더라도 명시적인 코드가 더 좋아서  

- 타입이 있으면, 코드를 읽을 때 이해하기가 더 쉬워서 

- TypeScript는 transpile 때 오류를 찾을 수 있어서 

암묵적 타입 vs 명시적 타입 

타입을 지정해주지 않으면, 알아서 타입을 추론해 타입을 대입한다. 하지만, JavaScript와는 달리 다른 타입을 같은 변수에 대입하려고 하면 오류가 발생한다. 이것은 명시적으로 작성한 변수에서도 마찬가지다. 

명시적으로 작성하기 

예전 JavaScript 개발자들은 암묵적인 코드를 많이 작성했다. 하지만 그런 방식은 코드를 이해하기 힘들게 만든다. 그래서 요즘에는 아래와 같이 arguments를 사용해서 함수를 작성한다고 한다. (*spread operator를 사용하는 이유는 arguments가 몇 개인지 딱 정해지지 않기 때문이다.) 

function bar(...args){
  console.log(args[0], args[1]);
  return 0; 
}
bar(10, 20); 

기본적인 타입

- 변수 뒤에 선언된 number는 숫자 전체를 나타내는 타입

- 조금 더 범위를 좁히고 명확하게 타입을 나타내는 방법은 line 6처럼 'type Age'와 같이 타입을 선언하는 것 

- Age는 나이라는 타입을 나타낸다. 나이는 숫자여야 하기 때문에 'type Age = number'로 선언함 

TS compile

- TypeScript는 컴파일해서 JavaScript 파일이 된다. 프로그램은 컴파일된 JavaScript 파일이 실행되어 돌아간다. 

- 타입은 TypeScript에서 JavaScript로 컴파일될 때 사용된다. 컴파일 된 JavaScript는 우리가 아는 JavaScript와 똑같다. 즉, 그곳에는 타입이 없다. 

- TypeScript에서 컴파일 된 JavaScript가 실행될 때 작동되는 것도 있다. 

객체 타입

객체의 타입을 선언할 때는 아래 코드처럼 표현하고자 하는 객체와 동일 구조를 가진 타입을 선언하면 된다. 이러한 방식을 type Alias라고 한다. 

객체의 타입을 선언하는 방법은 하나가 더 있다. interface는 아래 코드처럼 type 대신 interface를 사용해 선언할 수 있다.

poiemaweb.com/typescript-introduction

velog.io/@wooder2050/%EC%9A%B0%EC%95%84%ED%95%9C-%ED%85%8C%ED%81%AC%EB%9F%AC%EB%8B%9D-ReactTypescript-1%ED%9A%8C%EC%B0%A8