Thought of the day

게으름은 즐겁지만 괴로운 상태이다. 우리는 행복해지기 위해 무엇인가 하고 있어야 한다.
(Indolence is a delightful but distressing state; we must be doing something to be happy)
- 마하트마 간디 / Mahatma Gandhi

2021년 04월 26일 오늘은 50분정도 운동을 하고, 오전 10시 정각부터 공부를 시작했다.
오늘은 React의 Router에 대한 복습을 시작으로 본격적으로 공부했던 타입스크립트의 개념을 React에서 어떻게 적용할지에 대해서 새롭게 공부를 시작할 것이다. 알고리즘 문제풀이는 5문제정도 풀이할 예정이다.

TO DO LIST

• NextJS

  • SSR과 CSR의 차이에 대해 공부 및 블로그 포스팅 (완료)
  • NextJS 기본 setup 공부 (예정)

• TypeScript - Z

  • React router 공부 (예정)

  • TypeScript + React 공부 (예정)

    
    

• 알고리즘 관련 책 독서

  • ~ 30P (완료)

    
    

• A → V → R → Z

  
  

• Vanilla JS and ReactJS 실습

  • VanillaJS로 Grocery Bud 만들기 (예정)
  • ReactJS로 Grocery Bud 만들기 (예정)

  Read More

DFS(Depth-First-Search) 깊이 우선 탐색은 그래프의 모든 정점을 탐색하는 가장 단순한 방법이다.
현재 정점과 인접한 간선들을 하나씩 검사하다가 방문하지 않은 정점으로 향하는 간선이 있다면 해당 간선을 따라가 정점을 검사하고, 더 이상 갈 곳이 없는 막힌 정점에 도달하면 포기하고 마지막에 따라왔던 간선으로 되돌아간다.
거쳐왔던 모든 정점들에 대한 정보를 저장하기 위해서는 재귀호출을 이용해서 간단하게 해결할 수 있다. 재귀 호출한 함수가 종료하면 호출한 위치로 다시 돌아가기 때문이다.

Read More

DefinitelyTyped에 없는 package인 경우

만약에 사용하고자 하는 package가 기본적으로 type을 제공하지 않고, DefinitelyTyped에도 없는 경우, 이런 경우에는 내가 직접 typing을 해줘야 한다. (전부 typing하지 않고 내가 사용할 부분만 부분 typing한다.)

예를들어, can-use-dom이라는 타입을 제공하지 않는 패키지를 설치해서 사용하는데, DefinitelyTyped에도 없는 경우, 이 경우에는 아래와 같이 프로젝트 폴더 안에 *.d.ts파일을 작성해줘야 한다.
되도록이면 types와 같은 별도 폴더를 생성해서 내부에 *.d.ts파일을 작성해주도록 한다.

/<Project folder>/types/can-use-dom.d.ts

1
2
3
4

declare module "can-use-dom" {
  const canUseDOM: boolean;
  export default canUseDOM;
}

/<Project folder>/index.ts

1
2
3

import canUseDOM from 'can-use-dom';

console.log(canUseDOM);

이제 작성해준 can-use-dom.d.ts파일을 *.ts 파일 내에서 인식시키기 위해서 tsconfig.json파일에서 "typeRoot"옵션의 속성값으로 작성해준 *.d.ts파일의 폴더 경로를 적어줘야 한다.

tsconfig.json

1
2
3
4
5
6
7
8
9
10
11
12

{
  "compilerOptions": {
    ...
    "typeRoots": ["./types", "./node_modules/@types"],
    ...
  },
  "exclude": ["*.js"],
  // "include"에는 구체적으로 특정 파일을 작성하지 않도록 한다.
  // 만약 구체적으로 파일을 명시하게 되면 해당 타입스크립트 파일만 컴파일되기 때문에
  // 내가 작성한 *.d.ts 파일이 컴파일 되지 않는다.
  "include": [],
}

Read More

Thought of the day

게으름은 즐겁지만 괴로운 상태이다. 우리는 행복해지기 위해 무엇인가 하고 있어야 한다.
(Indolence is a delightful but distressing state; we must be doing something to be happy)
- 마하트마 간디 / Mahatma Gandhi

2021년 04월 25일 오늘은 새벽 2시 10분경에 공부를 시작했다.
오늘은 어제 공부했던 타입스크립트의 모듈 시스템에 대한 공부를 시작으로 타입스크립트에 대한 기본 개념에 대한 공부를 마무리한다. 그리고 공부했던 타입스크립트의 개념을 React에서 어떻게 적용할지에 대해서 새롭게 공부를 시작 할 것이다. 알고리즘 문제풀이는 10문제정도 풀이할 예정이다.

TO DO LIST

• TypeScript - Z

  • TypeScript 기본 실습 및 개념 공부 - TypeScript module system (완료)

    
    

• 알고리즘 관련 책 독서

  • ~ 30P (완료)

    
    

• A → V → R → Z

  
  

• Vanilla JS and ReactJS 실습

  • VanillaJS로 Grocery Bud 만들기 (예정)
  • ReactJS로 Grocery Bud 만들기 (예정)

  Read More

NodeJS의 모듈 시스템과 TypeScript의 모듈 시스템

타입스크립트의 모듈 시스템을 이해하기 전에 자바스크립트의 모듈 시스템 아니 더 정확하게는 NodeJS의 모듈 시스템에 대해서 알아보도록 하겠다.

• NodeJS의 모듈 시스템 = commonJS

• TypeScript의 모듈 시스템 = JavaScript의 최신 문법(ES2015(ES6))을 모듈 시스템에서 그대로 계승

우선 module을 이해하기 이전에 스크립트와 모듈을 구분할 수 있어야 한다.
만약에 자바스크립트 파일 안에 import와 export가 있는 경우, module이며, 없다면 script이다.

그렇다면 모듈이란 무엇일까? 모듈은 다른 자바스크립트 파일에서 특정 자바스크립트 파일을 사용할 수 있도록 만들어주는 것이다. 다시말해 파일을 잘개 쪼개는 효과를 줌으로써 코드의 가독성과 재사용성이 가능하도록 해주는 것이다.

자 이제 모듈의 개념에 대해서 간단하게 이해했으니 이제 NodeJS의 모듈 시스템과 TypeScript의 모듈 시스템의 차이에 대해서 살펴보도록 하겠다.

commonJS

1
2
3
4
5
6
7
8
9
10

// module.js
exports.a = 'b';
exports.b = false;
module.exports = {
  a: 'b',
  b: false
};

// run.js
const { a, b } = require('./module');

Read More

93일 243개 포스팅

2021년 4월 24일 12시 32분 오늘은 지난 1월 22일부터 하루도 빠짐없이 자기개발을 하며 블로그를 운영한 93일 동안의 나를 되돌아보며 회고록을 작성해보려고 한다.
여지까지 243개의 글을 포스팅했다.
내가 현재 어떤 방향으로 블로그를 운영하고 있으며, 향후 어떻게 자기개발을 하며 블로그를 운영할지에 대해서 자기반성의 시간을 갖으려고 한다.

console.log(지속적인 자기개발을 위한 나침반 === 개인 블로그);// true

우선 블로그 관리를 93일동안 하루도 빠짐없이 하면서 느꼈던 좋은 점은 나의 블로그가 지속적인 학습을 위한 나의 버팀목이자 공부 방향을 위한 나침반이었다는 점이다. 내가 개발자로 취업준비를 하면서 가장 중요하게 생각했던 것은 바로 꾸준한 자기개발이었다.

주변에서는 현재 개발자로 취업준비하는 것에 대해 취업준비 기간이 늘어나는 것을 걱정한다. 물론 나 역시 취업 준비기간이 늘어나는 것에 대해 아예 걱정이 안되는 것은 아니지만, 그보다 더 걱정되었던 것은 바로 내가 다시 개발자로 일을 하게 되었을때 퇴근한 뒤에 혹은 휴일에 나 스스로 꾸준히 자기개발을 하며 자기성장을 할 수 있을까?였다.

이전에 회사에서 짧게나마 개발자로 근무를 하면서 느꼈던 점은 개발자가 성장을 하려면 일 외적으로 꾸준하게 끊임없이 자기개발을 해야된다는 점이다.
일을 하다보면 자기개발을 소홀히 하는 경우가 많다. “업무가 힘들어서” “늦게 퇴근해서” “체력이 안되서” 등 여러가지 변명들로 자기합리화를 하면서 자기개발을 등한시 하는 경우가 많다. 이런 부분 때문에 혹여 지금 어느 회사에 들어간다고 하더라도 나 스스로 이런 자기개발 습관이 잡혀있지 않다면 어쩌면 이 개발 일을 업으로 삼으며 오래하지 못할 것 같다고 생각했다.

그래서 이전에도 물론 자기개발을 했지만 1월 22일부터는 하루도 빠지지 않고 자기개발을 하고 공부한 내용중에 다른 사람들과 공유하고 싶은 내용이나 스스로 다시 보면서 반복학습이 필요한 내용에 대해서 블로그 포스팅을 하고 있다.
이전에는 생각보다 내가 알고 있는 내용에 대해서 남에게 설명하려고 하면 어려웠는데 지금은 블로그 글을 작성하면서 글을 정제하다보니, 이전보다는 남에게 내가 알고 있는 것에 대해 설명을 잘 할 수 있게 된 것 같다.

Read More

복잡한 인수를 넘겨줄때는 객체 타입으로 작성

함수의 매개변수가 단순한 경우에는 그냥 각 각의 인수를 넣어서 호출해줘도 되지만, 만약에 함수의 매개변수로 넘겨줘야 되는 인수의 갯수가 많아지는 경우, 각 각의 인수가 어떤 역할을 하는지 파악하려면 다시 그 함수를 참조해야 한다.
따라서 넘겨줘야 되는 인수의 갯수가 늘어나는 경우 객체 타입으로 작성해서 각 인수의 역할에 대해서 유추할 수 있도록 작성을 해주면 코드의 가독성이 높아진다.

1

Example({ flag: true, id: '1' });

함수의 구조분해 매개변수에 타입 지정해주기

구조분해한 매개변수의 경우에는 구조분해한 변수의 뒤에 타입을 지정하지 않고 구조분해한 {}뒤에 콜론을 찍고 타입을 지정해준다.

1
2
3

function Example({ flag, id }: { flag: boolean, id: string }) {
  ...
}

타입 가드(Type Guard)

타입 가드를 사용하면 조건문에서 객체의 타입을 좁혀나갈 수 있다.
타입 가드란 함수의특정 인자가 어떤 타입인지 구분하기 위한 값을 반환하는 함수이다.

사용자 정의 Type Guard

만약 Data 객체가 A 또는 B 객체로 구분된다면 아래와 같이 사용자 정의 Type Guards 방식으로 data 객체의 타입을 좁힐 수 있다.

Read More

Thought of the day

게으름은 즐겁지만 괴로운 상태이다. 우리는 행복해지기 위해 무엇인가 하고 있어야 한다.
(Indolence is a delightful but distressing state; we must be doing something to be happy)
- 마하트마 간디 / Mahatma Gandhi

2021년 04월 24일 오늘은 11시 9분에 공부를 시작했다. 오늘은 어제 공부했던 타입스크립트 내용을 복습하고, 모듈 시스템에 대한 내용을 새롭게 공부할 예정이다. 알고리즘 문제풀이는 3문제정도 풀이를 예정으로 한다.

TO DO LIST

• 알고리즘 관련 책 독서

  • ~ 30P (완료)

    
    

• A → V → R → Z

  
  

• ReactJS - Z

  • TypeScript 기본 실습 (진행중...)
  • 
    

• Vanilla JS and ReactJS 실습

  • VanillaJS로 Grocery Bud 만들기 (예정)
  • ReactJS로 Grocery Bud 만들기 (예정)

  Read More

TypeScript는 HTML을 인지하지 못한다.

TypeScript는 HTML 자체를 인식하지 못하기 때문에 HTML 내의 요소를 참조할때 null로 인식하는 경우가 있다.

따라서 확실하게 HTML에 요소가 존재하는 경우에는 개발자가 !로 존재를 보증해주거나 if 문으로 조건처리를 해서 작성을 해줘야 한다.

1
2
3

if (document.querySelector('#id')) {
    (document.querySelector('#id') as HTMLElement).style.background = '......';
}

TypeScript에서 inline styling

타입스크립트에서 inline 스타일링을 하기 위해 HTML element를 참조하게 되면 .style을 하거나 .textContent를 하는 경우에 에러가 발생한다.
그 이유는 아래와 같이 querySelector로 HTML 요소를 참조하게 되면 해당 참조 요소의 타입은 Element를 상속받는 제네릭 타입 E가 된다. 이 Element에는 style, textContent 속성이 없다.

1

querySelector<E extends Element = Element>(selectors: string): E | null;

따라서 Element type을 HTMLDivElement로 타입의 범위를 좁게 잡아줘야 한다.

1
2
3
4
5
6
7

document.querySelector('#id').style.background = '...'; // error

// as로 Type casting
(document.querySelector('#id') as HTMLDivElement).style.background = '...';

// generic으로 Type casting
document.querySelector<HTMLDivElement>('#id').style.background = '...';

tsc로 타입스크립트 파일을 컴파일할때에는 파일명을 넣지 않는다.

타입스크립트 파일을 컴파일할때 npx tsc -w과 같이 컴파일할 파일을 명시하지 않도록 한다. 그 이유는 파일명을 구체적으로 명시해주게 되면, 프로젝트 폴더 내에 정의한 타입스크립트 설정파일(tsconfig.json)이 무시가 되서 설정된 사항들이 적용이 안될 수 있기 때문이다.

비슷한 속성의 객체는 같은 interface로 타입을 정의할 수 있다.

타입스크립트의 장점은 interface에 작성해준 타입의 정의를 보고 프로그램의 구조에 대한 힌트를 얻을 수 있다.

아래에 사람(Person)과 레스토랑(Restaurant) 인터페이스를 작성해보았다. 아래 예시 코드를 통해 "strictNullCheck": true일 경우의 null과 undefined에 대한 내용도 한 번 정리해보겠다.

Read More

as const와 readonly의 사용

객체를 as const로 정의를 해주게 되면 객체내의 모든 타입 속성들이 readonly로 바뀌는 것을 확인할 수 있다. 만약 일부의 타입 속성들만 상수로써 바뀌지 않게 하고 싶다면 해당 타입 속성의 변수명의 앞에 readonly를 붙여주도록 한다.
만약 변수의 타입이 상수 타입으로 고정되는 경우, 이 경우에는 별도로 as const나 readonly를 붙여주지 않아도 상관없다.

interface와 type alias 비교 및 사용

interface와 type alias를 사용해서 객체의 타입을 정의할때 그 용도를 일관되게 나눠서 사용하는 것이 좋다.
예를들어, 객체의 타입은 interface를 사용해서 정의하고 custom type은 type alias를 사용해서 정의하도록 하는 것이다.
interface와 type 모두 아래와 같이 객체의 타입을 정의할 수는 있지만 코드를 작성할때 일관성을 지켜서 코드를 작성하는 편이 좋다.

interface의 특징

• interface내에 정의한 타입 속성은 ,(콤마)나 ;(세미콜론), \n(줄바꿈)으로 구분할 수 있다.

• 다른 type interface를 상속할 수 있다.

  1 2 3 4 5 6 7 8

  interface ParentExample{ readonly A: string, readonly B: string } interface ChildExample extends ParentExample{ readonly C: string }

  Read More