스코프(scpoe : 유효범위) 는 자바스크립트를 포함한 모든 프로그래밍 언어의 기본이며 중요하다. 특히, 자바스크립트의 스코프는 다른 언어의 스코프와 구별되는 특징이 있다.

13.1 스코프란?

모든 식별자(변수이름, 함수이름, 클래스 이름 등)는 자신이 선언된 위치에 의해 다른 코드가 식별자 자신을 참조할 수 있는 유효 범위가 결정된다.

즉, 식별자가 유효한 범위

코드의 문맥과 환경 "코드가 어디서 실행되며 주변에 어떤 코드가 있는지" 를 렉시컬 환경 이라고 부른다. 코드의 문맥은 렉시컬 환경으로 이루어지고, 이를 구현한 것이 실행 컨텍스트 이며, 모든 코드는 실행 컨텍스트에서 평가되고 실행된다.

13.2 스코프의 종류

코드는 전역(global) 과 지역(local) 로 구분 할 수 있다.

13.3 스코프 체인

스코프는 함수의 중첩에 의해 계층적인 구조를 갖는다. 이렇게 스코프가 계층적으로 연결된 것을 스코프 체인 이라고 한다.

변수를 참조할 때 자바스크립트 엔진은

• 스코프 체인을 통해 변수를 참조하는 코드의 스코프에서 시작하여
• 상위 스코프 방향으로 이동하며 선언된 변수를 검색 한다.

• 절대 하위 스코프로 내려가면서 식별자를 검색하는 일은 없다.

• 이를 통해 사위 스코프에서 선언한 변수를 하위 스코프에서도 참조할 수 있다.

13.4 함수 레벨 스코프

• 함수 몸체 내부를 말하고 지역 스코프 를 만드는데, 이는
  • 코드 블록이 아닌 함수에 의해서만 지역 스코프가 생성 된다는 의미이다.
• C, Java 등을 비롯한 대부분의 프로그래밍 언어는 함수 몸체만이 아니라 모든 코드 블록 (if, for, while, try/catch 등) 이 지역 스코프를 만드는데
  • 이러한 특성을 블록 레벨 스코프라 한다.
• 하지만 var 키워드로 선언된 변수는 오로지 함수의 코드 블록 만을 지역 스코프로 인정
  • 이러한 특성을 함수 레벨 스코프 라고 한다.

var x = 1;

if (true) {
  // var 키워드로 선언된 변수는 함수의 코드 블록만을 지역 스코프로 인정한다.
  // 함수 밖에서 var 키워드로 선언된 변수는 코드 블록 내에서 선언되었다 할지라고 모두 전역 변수다.
  // 따라서 x 는 전역 변수다. 이미 선언된 전역 변수 x 가 있으므로 x 변수는 중복 선언된다.
  // 이는 의도치 않게 변수 값이 변경되는 부작용을 발생시킨다.
  var x = 10;
}

console.log(x); // 10

var i = 10;

// for 문에서 선언한 i는 전역 변수다. 이미 선언된 전역 변수 i 가 있으므로 중복 선언된다.
for ( var i = 0; i < 5; i++ ){
    console.log(i); // 0 1 2 3 4
}

// 의도치 않게 변수의 값이 변경되었다.
console.log(i); // 5

var 키워드로 선언된 변수는 오로지 함수의 코드 블록만을 지역 스코프로 인정하지만 ES6 에서 도입된 let, const 키워드는 블록 레벨 스코프를 지원 한다.

13.5 렉시컬 스코프

함수를 어디서 정의했는지에 따라 함수의 상위 스코프를 결정하는 것

자바스크립트는 렉시컬 스코프를 따르므로,

• 함수를 어디서 호출했는지가 아니라,
• 함수를 어디서 정의 했는지에 따라서 상위 스코프 를 결정한다.
• 함수가 호출된 위치는 상위 스코프 결정에 어떠한 영향도 주지 않는다.

이처럼 함수의 상위 스코프는 함수 정의가 실행될 때 정적으로 결정된다.

12.1 함수란?

프로그래밍 언어의 함수는

• 일련의 과정을 문(statement)으로 구현하고
• 코드 블록으러 감싸서 하나의 실행 단위로 정의한 것 이다.

각 용어에 대한 간단한 설명은,

• 함수 내부로 입력을 전달받는 변수를 매개변수(parameter)
• 입력을 인수(argument)
• 출력을 반환값(return value)

함수는 정의만으로 실행되는 것은 아니므로, 실행을 명시적으로 지시해야 한다. -> 이를 함수 호출 이라 한다.

12.2 함수를 사용하는 이유

• 함수는 몇 번이든 호출할 수 있으므로 코드의 재사용 이라는 측면에서 매우 유용하다.
• 코드의 중복을 억제하고 재사용성을 높이는 함수는 유지보수의 편의성 을 높이고 코드의 신뢰성 을 높인다.

12.3 함수 리터럴

함수 리터럴은,

• function 키워드
• 함수 이름
• 매개 변수 목록
• 함수 몸체

위와 같이 구성된다.

함수 리터럴은 평가되는 값을 생성 하며 함수는 객체 이다.

// 변수에 함수 리터럴을 할당
const funcAdd = function add(x, y) {
  return x + y;
}

12.4 함수 정의

함수를 호출하기 이전에 인수를 전달받은 매개변수 와 실행할 문들, 그리고 반환할 값을 지정 하는 것을 말한다.

함수를 정의하는 방법은,

• 함수 선언문
• 함수 표현식
• function 생성자 함수
• 화살표 함수(ES6)

12.4.1 함수 선언문

함수 선언문은 함수 리터럴과 형태가 동일하다, 단, 함수 리터럴은 함수 이름은 생략 할 수 있으나, 함수 선언문은 함수 이름을 생략 할 수 없다.

function add(x, y) {
  return x+y;
}

12.4.2 함수 표현식

함수는 일급 객체 이므로 함수 리터럴로 생성한 함수 객체를 변수에 할당 할 수 있는데, 이러한 함수 정의 방식을 함수 표현식 이라 한다.

일급 객체란? 자바스크립트의 함수는 값처럼 변수에 할당할 수도 있고, 프로퍼티 값이 될 수도 있으며 배열의 요소가 될 수도 있다. 이처럼 값의 성질을 갖는 객체를 일급 객체라 한다. 자바스크립트의 함수는 일급 객체다.

12.4.3 함수 생성 시점과 호이스팅

함수 표현식으로 정의한 함수 와 함수 선언문으로 정의한 함수 의 생성 시점이 다르다.

• 함수 선언문으로 정의한 함수는 함수 선언문 이전에 호출할 수 있다.

  • 함수 선언문으로 정의하면 런타임 이전에 함수 객체가 먼저 생성되고
  • 자바스크립트 엔진은 함수 이름과 동일한 이름의 식별자를 암묵적으로 생성하고, 생성된 함수 객체를 할당한다. ➔ 즉, 런타임 시점에는 이미 함수 객체가 생성되어 있고, 함수 이름과 동일한 식별자에 할당까지 완료된 상태이다. (= 호이스팅)

• 함수 표현식으로 정의한 함수는 함수 표현식 이전에 호출할 수 없다.

  • 함수 표현식은 변수에 할당되는 값이 함수 리터럴인 문이다.
  • 따라서 함수 표현식은 변수 선언문과 변수 할당문을 한 번에 기술한 축약 표현과 동일하게 동작한다.
  • 변수 선언은 런타임 이전에 실행되어 undefined로 초기화된다.
  • 함수 표현식 이전에 함수를 참조하면 undefined로 평가되는데, 이때 함수를 호출하면 undefined를 호출하는 것과 마찬가지이므로 타입 에러가 발생하니 주의!! ➔ 함수 표현식으로 정의한 함수는 반드시 함수 표현식 이후에 참조 또는 호출해야 타입 에러가 발생하지 않는다.

12.4.4 Function 생성자 함수

자바스크립트가 기본 제공하는 빌트인 함수인 Function 생성자 함수에 매개변수 목록 과 함수 몸체 를 문자열로 전달하면서 new 연산자와 함께 호출하면 함수 객체를 생성해서 반환한다.

생성자 함수는 객체를 생성하는 함수

var add = new Function('x', 'y', 'return x + y');

주의 !! Function 생성자 함수로 함수를 생성하는 방식은 일반적이지 않으며 바람직하지도 않다. 클로저를 생성하지 않는 등, 함수 선언문이나 함수 표현식으로 생성한 함수와 다르게 동작한다

12.4.5 화살표 함수

ES6에서 도입된 화살표 함수(arrow function) 은 function 키워드 대신에 화살표( => ) 를 사용해서 좀 더 간략한 방법으로 함수를 선언 할 수 있다.

• 화살표 함수는 생성자 함수로 사용할 수 없으며
• 기존 함수와 this 바인딩 방식이 다르고,
• prototype 프로퍼티가 없으며
• arguments 객체를 생성하지 않는다.

var add = (x, y) => x + y;
console.log(add(2, 5)); // 7

12.5 함수 호출

함수는 함수를 가리키는 식별자와 한 쌍의 소괄화() 인 함수 호출 연산자로 호출된다.

12.5.1 매개변수와 인수

함수를 실행하기 위해 필요한 값을 함수 외부에서 내부로 전달할 필요가 있는 경우, 매개변수를 통해 인수를 전달한다.

• 인수 : 함수를 호출할 때 지정하며, 개수와 타입에 제한이 없다.
• 매개변수 : 함수를 정의할 때 선언하며, 스코프(유효범위)는 함수 내부이다.

// 함수 선언문
function add(x, y) {
  return x + y;
}

// 함수 호출
// 인수 1과 2는 매개변수 x와 y에 순서대로 할당되고 함수 몸체의 문들이 실행된다.
var result = add(1, 2);

12.5.2 인수 확인

function add(x, y) {
  return x + y;
}

console.log(add(2)); // NaN
console.log(add('a', 'b')); // 'ab'

위 코드는 자바스크립트 문법상 어떠한 문제도 없으므로 자바스크립트 엔진은 아무런 이의 제기없이 실행할 것이다. 이러한 상황이 가능한 이유는,

• 자바스크립트 함수는 매개변수와 인수의 개수가 일치하는지 확인하지 않는다.
• 자바스크립트는 동적 타입 언어다. 따라서 자바스크립트 함수는 매개변수의 타입을 사전에 지정할 수 없다.

그래서 자바스크립트는 함수를 정의할 때 적절한 인수가 전달되었는지 확인할 필요가 있다.

function add(x, y) {
  if (typeof x !== 'number' || typeof y !== 'number') {
    // 매개변수를 통해 전달된 인수의 타입이 부적절한 경우 에러를 발생시킨다.
    throw new TypeError('인수는 모두 숫자 값이어야 합니다.');
  }

  return x + y;
}

console.log(add(2));        // TypeError: 인수는 모두 숫자 값이어야 합니다.
console.log(add('a', 'b')); // TypeError: 인수는 모두 숫자 값이어야 합니다.

12.5.3 매개변수의 최대 개수

ECMAScirpt 사양에서는 매개변수의 최대 개수에 대해 명시적으로 제한하고 있지는 않지만, 물리적 한계는 있으므로 자바스크립트 엔진마다 매개변수의 최대 개수에 대한 제한은 있다.

• 매개변수는 순서에 의미가 있다.

• 따라서 매개변수가 많아지면 함수를 호출할 때 전달해야 할 인수의 순서를 고려해야 한다.

• 함수의 매개변수는 코드를 이해하는 데 방해되는 요소이므로,

• 이상적인 매개변수의 개수는 0개이며

• 최대 3개 이상을 넘지 않는 것을 권장

• 매개변수의 개수가 많다는 것은 함수가 여러가지 일을 한다는 증거이므로 바람직하지 않다.

• 이상적인 함수는 한 가지 일만 해야 하며 가급적 작게 만들어야 한다.

12.5.4 반환문

함수는 return 키워드와 반환 값으로 이뤄진 반환문을 사용해 실행 결과를 함수 외부로 반환 할 수 있다.

반환문은 두 가지 역할을 하는데,

• 첫째, 반환문은 함수의 실행을 중단하고 함수 몸체를 빠져나간다.

• 반환문 이후에 다른 문이 존재하면 그 문은 실행되지 않고 무시된다.

• 둘째, 반환문은 return 키워드 뒤에 오는 표현식을 평가에 반환한다.

• return 키워드 뒤에 반환값으로 사용할 표현식을 명시적으로 지정하지 않으면 undefined가 반환된다.

12.6 다양한 함수의 형태

12.6.1 즉시 실행 함수

함수 정의와 동시에 즉시 호출되는 함수

• 단 한 번만 호출되며 다시 호출 할 수 없다.

// 즉시 실행 함수는 익명 함수로 사용하는 것이 일반적이다.
(function () {
  var a = 3;
  var b = 5;
  return a*b;
} ());

12.6.2 재귀 함수

함수가 자기 자신을 호출하는 것

• 재귀 함수는 자기 자신을 호출하는 행위
• 재귀 함수는 자신을 무한 재귀 호출 하므로 탈출 조건을 만들어야 스택 오버 플로 에러가 발생하지 않는다.

// 함수 표현식
var factorial = function foo(n) {
  // 탈출 조건: n이 1 이하일 때 재귀 호출을 멈춘다.
  if (n <= 1) return 1;
  // 함수를 가리키는 식별자로 자기 자신을 재귀 호출
  return n * factorial(n - 1);

  // 함수 이름으로 자기 자신을 재귀 호출할 수도 있다.
  // console.log(factorial === foo); // true
  // return n * foo(n - 1);
};

console.log(factorial(5)); // 5! = 5 * 4 * 3 * 2 * 1 = 120

12.6.3 중첩 함수

중첩 함수 ( = 내부 함수 )

• 함수 내부에 정의된 함수
• 중첩 함수는 외부 함수 내에서만 호출 할 수 있다.
• 일반적으로 중첩 함수는 자신을 포함하는 외부 함수를 돕는 헬퍼 함수 의 역할을 한다.

function outer() {
  var x = 1;

  // 중첩 함수
  function inner() {
    var y = 2;
    // 외부 함수의 변수를 참조할 수 있다.
    console.log(x + y); // 3
  }

  inner();
}

outer();

12.6.4 콜백 함수

함수의 매개변수를 통해 다른 함수의 내부로 전달되는 함수

• 매개변수를 통해 함수의 외부에서 콜백 함수를 전달받은 함수를 고차 함수 라고 한다.
• 고차 함수는 콜백 함수를 자신의 일부분으로 합성하며
• 매개변수를 통해 전달받은 콜백 함수의 호출 시점을 결정해서 호출한다.

// 외부에서 전달받은 f를 n만큼 반복 호출한다
function repeat(n, f) {
  for (var i = 0; i < n; i++) {
    f(i); // i를 전달하면서 f를 호출
  }
}

var logAll = function (i) {
  console.log(i);
};

// 반복 호출할 함수를 인수로 전달한다.
repeat(5, logAll); // 0 1 2 3 4

var logOdds = function (i) {
  if (i % 2) console.log(i);
};

// 반복 호출할 함수를 인수로 전달한다.
repeat(5, logOdds); // 1 3

자바스크립트에서 제공하는 데이터 타입은 크게 원시 타입(premitive type) 과 객체 타입(obejct/reperence type) 으로 구분 하는데, 둘 사이는 차이점이 존재한다.

• 원시 타입 값은 변경 불가능 한 값 이고, 객체(참조) 타입 값은 변경 가능한 값 이다.
• 원시 타입 값을 변수에 할당하면 변수(확보된 메모리 공간) 에는 실제 값이 저장 객체(참조) 타입 값은 변수(확보된 메모리 공간)에는 참조 값이 저장
• 원시 타입 값을 갖는 변수를 다른 변수에 할당하면 원본의 원시 값이 복사되어 전달 객체 타입 값을 갖는 변수를 다른 변수에 할당하면 원본의 참조 값이 복사되어 전달

11.1 원시 타입 값

11.1.1 변경 불가능한 값

원시 타입은 변경 불가능한 값으로 읽기 전용(read only) 값이다.

JavaScript에서 원시 값(primitive, 또는 원시 자료형)이란 객체가 아니면서 메서드도 가지지 않는 데이터입니다. 원시 값에는 7종류, string, number (en-US), bigint (en-US), boolean, undefined, symbol, 그리고 null이 존재합니다. ( 출처 : MDN )

• 원시 값 자체를 변경 불가능하다는 것이지, 변수 값을 변경 할 수 없다는 것이 아님을 유의!

// const 키워드를 사용 해 선언한 변수는 재할당이 금지된다. 상수는 재할당이 금지된 변수일 뿐이다.
const o = {};

// const 키워드를 사용해 선언한 변수에 할당한 원시 값(상수)은 변경할 수 없다.
// 하지만 const 키워드를 사용해 선언한 변수에 할당한 객체는 변경할 수 있다.
o.a = 1;
console.log(o); // {a: 1}

원시 값을 할당한 변수에 새로운 원시 값을 재할당 하면,

• 메모리 공간에 저장되어 있는 재할당 이전의 원시 값을 변경하는 것이 아니라,
• 새로운 메모리 공간을 확보 하고 재할당한 원시 값을 저장한 후,

• 변수가 참조하던 메모리 공간의 주소가 변경된 이유는, 변수에 할당된 원시 값이 변경 불가능한 값이기 때문

• 변수는 새롭게 재할당한 원시 값을 가리킨다.

• 이러한 특성을 불변성이라고 한다

• 불변성을 갖는 원시 값을 할당한 변수는 재할당 이외에 값을 변경 할 수 있는 방법이 없다.

11.1.2 문자열과 불변성

문자열은 유사 배열 객체로서 배열과 유사하게 각 문장에 접근 할 수 있으나, 변경 불가능 한 값 이기 때문에 일부 문자를 변경해도 반영되지 않는다. 원시 타입은 문자열은 읽기 전용 이기 때문이다.

원시 값을 저장하려면 먼저 확보해야 하는 메모리 공간의 크기를 결정해야 한다.

• 이를 위해 원시 타입별로 메모리 공간의 크기가 미리 정해져 있다.
• ECMAScript 사양에

• 문자열 타입(2바이트) 와 숫자 타입(8바이트)

• 이외의 원시 타입은 크기를 명확히 규정하고 있지 않다.

var str = 'string';

// 문자열은 유사 배열이므로 배열과 유사하게 인덱스를 사용해 각 문자에 접근할 수 있다.
// 하지만 문자열은 원시값이므로 변경할 수 없다. 이때 에러가 발생하지 않는다.
str[0] = 's';

console.log(str); // string

11.1.3 값에 의한 전달

변수에 원시 값을 할당하면, 할당받는 변수에는 할당되는 변수의 원시 값이 복사되어 전달 된다.

var score = 90;
var copy = score;

console.log(score); // 90
console.log(copy);  // 90

score = 100

console.log(score); // 100
console.log(copy);  // 100

score 변수와 copy 변수는 숫자 값 100을 갖는다는 점에서는 동일하지만, score 변수와 copy 변수의 값 100은 다른 메모리 공간에 저장된 별개의 값이다.

즉, 값에 의한 전달은 사실 값을 전달하는 것이 아니라 메모리 주소를 전달한다.

중요한 것은 변수에 원시 값을 갖는 변수를 할당하면, ( 위와 같이 ) 변수 할당 시점 이든, 두 변수 중 어느 하나의 변수에 값을 재할당 하는 시점 이든 두 변수의 원시 값은 서로 다른 메모리 공간에 저장된 별개의 값 이 되어 어느 한쪽에서 재할당을 통해 값을 변경하더라도 서로 간섭할 수 없다.

11.2 객체

• 프로퍼티의 개수가 정해져 있지 않아 동적으로 추가되고 삭제할 수 있고
• 프로퍼티의 값에도 제약이 없다.
• 원시 값과 같이 확보해야 할 메모리 공간의 크기를 사전에 정해 둘 수 없고 복합적인 자료구조라서 ,원시 값과는 다른 방식으로 동작하도록 설계되어 있다.
• 객체를 변경할 때 마다 복사해서 생성 후 변경하면 비용이 많이 든다.
• 원시 값처럼 이전 값을 복사해서 새롭개 생성한다면

• 명확하고 신뢰성이 확보되겠지만

• 객체는 크기가 매우 클 수도 있고

• 원시 값처럼 크기가 일정하지도 않으며,

• 프로퍼티 값이 객체일 수도 있어서

따라서 메모리를 효율적으로 사용하기 위해, 그리고 객체를 복사해 생성하는 비용을 절약하여 성능을 향상시키기 위해 -> 객체는 변경 가능한 값으로 설계되어 있다.

11.2.1 변경 가능한 값

객체(참조) 타입의 값은 변경 가능한 값 이다.

• 객체를 할당한 변수는 재할당 없이 객체를 직접 변경 할 수 있다.
• 즉, 재할당 없이 프로퍼티를 동적으로 추가 할 수 있고
• 값을 갱신 할 수 있으며, 자체를 삭제 할 수 있다.

얕은 복사와 깊은 복사

객체를 프로퍼티 값으로 갖는 객체인 경우

• 얕은 복사 는 한 단계 까지만 복사하는 것을 말하고 ➔ 참조 값을 복사
• 깊은 복사 는 객체에 중첩되어 있는 객체 까지 복사하는 것을 말한다. ➔ 객체에 중첩되어 있는 객체까지 모두 복사해서 원시 값처럼 완전한 복사본을 만드는 복사

const o = { x: { y: 1 } };

// 얕은 복사
const c1 = { ...o };       // 스프레드 문법
console.log(c1 === o);     // false
console.log(c1.x === o.x); // true

// lodash의 cloneDeep을 사용한 깊은 복사
// "npm install lodash"로 lodash를 설치한 후, Node.js 환경에서 실행
const _ = require('lodash');
// 깊은 복사
const c2 = _.cloneDeep(o);
console.log(c2 === o);     // false
console.log(c2.x === o.x); // false

const v = 1;

// "깊은 복사"라고 부르기도 한다.
const c1 = v;
console.log(c1 === v);     // true

const o = { x: 1 };

// "얕은 복사"라고 부르기도 한다.
const c2 = o;
console.log(c2 === o);     // true

얕은 복사와 깊은 복사로 생성한 객체는 원본과는 다른 객체다. -> 원본과 복사본은 참조 값이 다른 별개의 객체다.

11.2.2 참조에 의한 전달

객체를 가리키는 변수(원본 person) 을 다른 변수(사본 copy)에 할당하면, 원본의 참조 값이 복사되어 전달 되는 것

var person = {
  name: 'Lee'
};

// 참조값을 복사(얕은 복사)
var copy = person;

위의 코드에서 person과 copy 모두 동일한 객체를 가리키는데 이는 두 개의 식별자가 하나의 객체를 공유 한다는것을 의미한다.

정리

값에 의한 전달 과 참조에 의한 전달 은

• 식별자가 기억하는 메모리 공간에 저장되어 있는 값을 복사해서 전달한다는 면에서 동일하지만,
• 식별자가 기억하는 메모리 공간(변수)에 저장되어 있는 값이 원시 값이냐 참조 값이냐에 차이가 있다.

10.1 객체 ?

객체는 객체의 상태를 나타내는 값(프로퍼티) 과 그 값을 참조하고 조작 할 수 있는 동작(메서드) 을 모두 가지고 있는 것

• 상태(데이터) 와 동작(메서드) 을 하나의 단위로 구조와 할 수 있어 유용하다.

자바스크립트는 객체(object) 기반의 프로그래밍 언어 이며, 자바스크립트를 구성하는 것은 대부분 객체이다.

• 원시 값을 제외한 나머지 값(함수, 배열, 표현식 등)은 모두 객체
• 원시 타입은 단 하나의 값만 나타내지만, 객체 타입은 다양한 타입의 값을 하나의 단위로 구성한 복합적인 자료구조다.
• 원시 타입의 값은 변경 불가능한 값이지만, 객체는 변경 가능한 값이다.
• 객체는 0개 이상의 프로퍼티로 구성된 집합이며, 프로퍼티는 키(key) 와 값(value) 으로 구성된다.

자바스크립트에서 사용할 수 있는 모든 값은 프로퍼티 값이 될 수 있다.

• 자바스크립트의 함수는 일급 객체 이므로 값이 될 수 있고,
• 일급 객체 또한 프로퍼티 값으로 사용 할 수 있다.

일급 객체 ? 다른 객체들에 일반적으로 적용 가능한 연산을 모두 지원하는 객체를 가리킨다. 보통 함수에 매개변수로 넘기기, 수정하기, 변수에 대입하기와 같은 연산을 지원할 때 일급 객체라고 한다. (출처 : 위키백과)

즉, 특정 언어에서 객체를 값으로 취급하는 것을 말한다. ✅ 자바스크립트에서는 함수가 일급객체이다.

• 무명의 리터럴로 생성할 수 있다. (런타임 생성이 가능하다.)
• 변수나 자료구조(객체, 배열 등)에 저장할 수 있다.
• 함수의 매개변수에 전달할 수 있다.
• 함수의 반환값(return)으로도 사용할 수 있다.

자바스크립트의 함수는 위 조건을 모두 만족하므로 일급 객체이다.

10.2 객체 리터럴에 의한 객체 생성

객체 리터럴은 자바스크립트의 유연함 과 강력함 을 대표하는 객체 생성 방식이다.

• 객체를 생성하기 위해 클래스를 먼저 정의하고, new 연산자와 함께 생성자를 호출할 필요가 있다.
• 숫자 값이나 문자열을 만드는 것과 유사하게 리터럴로 객체를 생성한다.
• 객체 리터럴에 프로퍼티 값을 포함시켜 객체를 생성함과 동시에 프로퍼티를 만들 수 있고,
• 객체를 생성한 이후에 프로퍼티를 동적으로 추가할 수 있다.

C++이나 자바같은 클래스 기반 객체지향 언어는

• 클래스를 사전에 정의하고
• 필요한 시점에 new 연산자와 함께 생성자를 호출하여 인스턴스(instance)를 생성하는 방식으로 객체를 생성한다.

인스턴스(instance) 클래스에 의해 생성되어 메모리에 저장된 실체를 의미

하지만, 자바스크립트는 프로토타입 기반 객체 지향 언어 로, 클래스 기반 객체 지향언어와는 달리 다양한 객체 생성 방법을 지원한다.

• 객체 리터럴
• Object 생성자 함수
• 생성자 함수
• Object.create 메서드
• 클래스(ES6)

프로토타입 기반 객체 지향 언어 객체지향 프로그래밍의 한 형태의 갈래로 클래스가 없고, 클래스 기반 언어에서 상속을 사용하는 것과는 다르게, 객체를 원형으로 하여 복제의 과정을 통하여 객체의 동작 방식을 다시 사용할 수 있다. ( 출처 : 위키백과 )

객체 생성 방법 중에서 가장 간단한 방법은 객체 리터럴 이다.

• 중괄호({...}) 내에 0개 이상의 프로퍼티를 정의한다.
• 변수에 할당되는 시점에 자바스크립트 엔진은 객체 리터럴을 해석해 객체를 생성한다.

리터럴 (literal) 사람이 이해할 수 있는 문자 또는 약속된 기호를 사용하여 값을 생성하는 표기법

var person = {
    name: 'april',
    sayHello: function () {
      console.log(`Hello! My name is ${this.name}.`);
    }
};
console.log(typeof person); // object
console.log(person);        // {name: "april", sayHello: ƒ}

// 중괄호 내에 프로퍼티를 정의하지 않으면 빈 객체가 생성된다.
var empty = {};
console.log(typeof empty); // object

Point 객체 리터럴의 중괄호는 코드 블록을 의미하지 않는다. 따라서 코드블록의 닫는 중괄호 뒤에는 세미콜론(;)을 붙이지 않지만 객체 리터럴의 닫는 중괄호 뒤에는 세미콜론을 붙인다.

10.3 프로퍼티

객체는 프로퍼티의 집합이며 프로퍼티는 키와 값으로 구성된다.

var person = {
  // 프로퍼티 키는 name, 프로퍼티 값은 'april'
  name: 'april',
  // 프로퍼티 키는 age, 프로퍼티 값은 20
  age: 20
};

프로퍼티를 나열 할 때는 쉼표로 구분한다. 프로퍼티 키와 값으로 사용 할 수 있는 값은 아래와 같다.

• 키 : 빈 문자열을 포함하는 모든 문자열 또는 심벌값
• 값 : 자바스크립트에서 사용할 수 있는 모든 값

10.4 메서드

자바스크립트의 함수는 객체(일급 객체) 라서 값으로 취급 할 수 있다.

• 즉, 함수는 값으로 취급 할 수 있기 때문에 프로퍼티 값 으로 사용 할 수 있다.
• 프로퍼티 값이 함수일 경우 일반 함수와 구분하기 위해 메서드 라고 부른다.

var circle = {
  radius: 5, // ← 프로퍼티

  // 원의 지름
  getDiameter: function () { // ← 메서드
    return 2 * this.radius;  // this는 circle을 가리킨다.
  }
};

console.log(circle.getDiameter()); // 10

10.5 프로퍼티 접근

• 마침표 : 프로퍼티 접근 연산자(.) 를 사용하는 마침표 표기법
• 대괄호 : 프로퍼티 접근 연산자([...]) 를 사용하는 대괄호 표기법

var person = {
  name: 'april'
};

// 마침표 표기법에 의한 프로퍼티 접근
console.log(person.name);    // april

// 대괄호 표기법에 의한 프로퍼티 접근
console.log(person['name']); // april

// undefined 반환
console.log(person.age)

10.7 프로퍼티 동적 생성

존재하지 않는 값을 프로퍼티에 할당하면

• 동적으로 생성되어 추가되고,
• 값이 할당된다.

var person = {
  name: 'april'
};

// person 객체에는 age 프로퍼티가 존재하지 않는다.
// 따라서 person 객체에 age 프로퍼티가 동적으로 생성되고 값이 할당된다.
person.age = 20;

console.log(person); // {name: "april", age: 20}

10.8 프로퍼티 삭제

delete 연산자는 객체의 프로퍼티 값을 삭제한다.

var person = {
  name: 'april'
};

// 프로퍼티 동적 생성
person.age = 20;

// person 객체에 age 프로퍼티가 존재한다.
// 따라서 delete 연산자로 age 프로퍼티를 삭제할 수 있다.
delete person.age;

// person 객체에 address 프로퍼티가 존재하지 않는다.
// 따라서 delete 연산자로 address 프로퍼티를 삭제할 수 없다. 이때 에러가 발생하지 않는다.
delete person.address;

console.log(person); // {name: "april"}

10.9 ES6에서 추가된 객체 리터럴의 확장 기능

10.9.1 프로퍼티의 축약 표현

객체 리터럴의 프로퍼티는 키와 값으로 구성된다.

• 프로퍼티 값은 변수에 할당된 값, 식별자 표현식일 수도 있다.

ES6에서는 프로퍼티 값으로 변수를 사용하는 경우 변수 이름과 프로퍼티 키가 동일한 이름일 때 프로퍼티 키를 생략 할 수 있다.

// ES5
var x = 1, y = 2;
var obj = {
  x: x,
  y: y
};

console.log(obj); // {x: 1, y: 2}



// ES6
let x = 1, y = 2;

// 프로퍼티 축약 표현
const obj = { x, y };

console.log(obj); // {x: 1, y: 2}

10.9.2 계산된 프로퍼티 이름

문자열 또는 문자열로 타입 변환 할 수 있는 값 으로 평가되는 표현식을 통해 프로퍼티 키를 동적으로 생성 할 수 있다.

• 단, 프로퍼티 키로 사용할 표현식을 대괄호([...])로 묶어야 한다.
• 이를 계산된 프로퍼티 이름라고 한다.

// ES5
var prefix = 'prop';
var i = 0;
var obj = {};

// 계산된 프로퍼티 이름으로 프로퍼티 키 동적 생성
obj[prefix + '-' + ++i] = i;
obj[prefix + '-' + ++i] = i;
obj[prefix + '-' + ++i] = i;

console.log(obj); // {prop-1: 1, prop-2: 2, prop-3: 3}


// ES6
const prefix = 'prop';
let i = 0;

// 객체 리터럴 내부에서 계산된 프로퍼티 이름으로 프로퍼티 키 동적 생성
const obj = {
  [`${prefix}-${++i}`]: i,
  [`${prefix}-${++i}`]: i,
  [`${prefix}-${++i}`]: i
};

console.log(obj); // {prop-1: 1, prop-2: 2, prop-3: 3}

10.9.3 메서드 축약 표현

메서드를 정의 할 때 function 키워드를 생략 한 축약 표현을 사용할 수 있다.

// ES5
var obj = {
  name: 'april',
  sayHi: function() {
    console.log('Hi! ' + this.name);
  }
};

obj.sayHi(); // Hi! april


// ES6
const obj = {
  name: 'april',
  // 메서드 축약 표현
  sayHi() {
    console.log('Hi! ' + this.name);
  }
};

obj.sayHi(); // Hi! april

9.1 타입 변환 ?

자바스크립트의 모든 값은 타입을 가지는데,

• 개발자의 의도에 따라 값의 타입을 변환하는 것을

• 명시적 타입 변환 또는 타입 캐스팅 이라고 한다.

• 개발자의 의도와는 상관없이 표현식을 평가하는 도중에 자바스크립트 엔진에 의해 암묵적으롤 타입이 자동 변환되는 것을

• 암묵적 타입 변환 또는 타입 강제 변환 이라고 한다.

자바스크립트는 가급적 에러를 발생시키지 않도록 암묵적으로 타입 변환을 통해 표현식을 평가

• 그렇다고 명시적 타입 변환이나 암묵적 타입 변환이나 기존 원시값을 직접 변경하는 것은 아니다.

• 원시 값은 변경 불가능한 값 이다.

즉, 타입변환이란

• 기존 원시 값을 사용해 다른 타입의 새로운 값을 생성 하는 것

9.2 암묵적 타입 변환

자바스크립트 엔진이 표현식을 평가할 때, 개발자의 의도와 상관없이 코드의 문맥을 고려해 암묵적으로 데이터 타입을 강제 변환 하는 것

9.2.1 문자열 타입으로 변환

• + 또는 템플릿 리터럴
• 템플릿 리터럴은 표현식의 평가 결과를 문자열 타입으로 암묵적 변환
• 문자열 연결 연산자는 코드의 문맥상 모두 문자열 타입 이어야 한다.

자바스크립트 엔진은 문자열 연결 연산자를 만나면, -> 문자열 타입이 아닌 값을 문자열 타입으로 암묵적 타입 변환하여 수행

// 숫자 타입
0 + ''              // "0"
  -0 + ''             // "0"
1+ ''               // "1"
  -1 + ''             // "-1"
NaN + ''            // "NaN"
Infinity + ''       // "Infinity"
  -Infinity + ''      // "-Infinity"

// boolean 타입
true + ''           // "true"
false + ''          // "false"

// null 타입
null + ''           // "null"

// undefined 타입
undefined + ''      // "undefined"

// 심벌 타입
(Symbol()) + ''     // "TypeError"

// 객체 타입
({}) + ''           // "[object Object]"
Math + ''           // "[object Math]"
[] + ''             // ""
[10, 20] + ''       // "10, 20"
(function(){}) + '' // "function()"
Array + ''          // "function Array() {[native code]}"

9.2.2 숫자 타입으로 변환

• +, -, / 는 모두 산술 연산자
• 산술 연산자의 모든 피연산자는 코드 문맥상 모두 숫자 타입 이어야 한다.
• 자바스크립트 엔진은 + 단항 연산자를 만나면

• 피연산자가 숫자 타입의 값이 아니면 숫자 타입의 값으로 암묵적 타입 변환을 수행

자바스크립트 엔진은 산술 연산자를 만나면, -> 숫자 타입이 아닌 값을 숫자 타입으로 암묵적 타입 변환하여 동작 -> 이 때, 숫자 타입으로 변환할 수 없는 경우는 산술 연산을 수행할 수 없으므로 표현식의 결과는 NaN이 된다.

// 숫자 타입
+''               // 0
+'0'              // 0
+'1'              // 1 
+'string'         //  NaN

// boolean 타입
+true             //  1
+false            //  0

// null 타입
+null             //  0

// undefined 타입
+undefined        //  NaN

// 심벌 타입
+Symbol()         //  TypeError

// 객체 타입
+{}               //  NaN
+[]               //  0
+[10, 20]         //  NaN
+(function(){})   //  NaN

비교 연산자

'1' > 0 // true

• 비교 연산자는 피연산자의 크기를 비교하므로, 코드의 문맥상 모두 숫자 타입 이어야 한다.

9.2.3 boolean 타입으로 변환

• if 문과 for 문과 같은 제어문 또는 삼항 조건 연산자의 조건식은

• 논리적 참 / 거짓 으로 평가되어야 하는 표현식 으로

• 조건식의 평과 결과를 불리언 타입으로 암묵적 타입 변환을 한다.

• 자바스크립트 엔진은 불리언 타입이 아닌 값을

• Truthy 값 또는 Falsy 값으로 구분해 각각 true와 false로 암묵적 타입 변환 한다.

• Truthy 값 또는 Falsy 값 앞에 느낌표(!)를 붙어주면 각각 true와 false로 전달된다.

• false로 평가되는 Falsy 값

• false

• undefined

• null

• 0, -0

• NaN

• ‘’(빈 문자열)

9.3 명시적 타입 변환

9.3.1 문자열 타입으로 변환

1. String() 생성자 함수 사용

// 숫자 타입 => 문자열 타입
String(1);              // "1"
String(NaN);            // "NaN"
String(Infinity);       // "Infinity"

// 불리언 타입 ➔ 문자열 타입
String(true)            // "true"
String(false)           // "false"

2. Object.prototype.toString 메서드를 사용하는 방법

// 숫자 타입 ➔ 문자열 타입
(1).toString();         // "1"
(NaN).toString();       // "NaN"
(Infinity)toString();   // "Infinity"

// 불리언 타입 ➔ 문자열 타입
(true).toString();      // "true"
(false).toString();     // "false"

3. 문자열 연결 연산자를 이용

// 숫자 타입 ➔ 문자열 타입
1 + ''                  // "1"
NaN + ''                //  "NaN"
Infinity + ''           // "Infinity"

// 불리언 타입 ➔ 문자열 타입
true + ''               // "true"
false + ''              // "false"

9.3.2 숫자 타입으로 변환

1. Number() 생성자 함수를 사용

// 문자열 타입 ➔ 숫자 타입
Number('0');     // 0
Number('-1');    // -1
Number('10.53'); // 10.53

// 불리언 타입 ➔ 숫자 타입
Number(true);    // 1
Number(false);   // 0

2. parseInt, parseFloat 함수 사용 (문자열 만)

parseInt('0');       // 0
parseInt('-1');      // -1
parseFloat('10.53'); // 10.53

3. + 단항 산술 연산자를 사용

// 문자열 타입 ➔ 숫자 타입
+'0';     // 0
+'-1';    // -1
+'10.53'; // 10.53

// 불리언 타입 ➔ 숫자 타입
+true;    // 1
+false;   // 0

4. * 산술 연산자 사용

// 문자열 타입 ➔ 숫자 타입
'0' * 1;     // 0
'-1' * 1;    // -1
'10.53' * 1; // 10.53

// 불리언 타입 ➔ 숫자 타입
true * 1;    // 1
false * 1;   // 0

9.3.3 boolean 타입으로 변환

1. Boolean() 사용

// 문자열 타입 ➔ 불리언 타입
Boolean('x');       // true
Boolean('');        // false
Boolean('false');   // true

// 숫자 타입 ➔ 불리언 타입
Boolean(0);         // false
Boolean(1);         // true
Boolean(NaN);       // false
Boolean(Infinity);  // true

// null 타입 ➔ 불리언 타입
Boolean(null);      // false

// undefined 타입 ➔ 불리언 타입
Boolean(undefined); // false

// 객체 타입 ➔ 불리언 타입
Boolean({});        // true
Boolean([]);        // true

2. ! 부정 논리 연산자를 두 번 사용하는 방법

// 문자열 타입 ➔ 불리언 타입
!!'x';       // true
!!'';        // false
!!'false';   // true

// 숫자 타입 ➔ 불리언 타입
!!0;         // false
!!1;         // true
!!NaN;       // false
!!Infinity;  // true

// null 타입 ➔ 불리언 타입
!!null;      // false

// undefined 타입 ➔ 불리언 타입
!!undefined; // false

// 객체 타입 ➔ 불리언 타입
!!{};        // true
!![];        // true

9.4 단축 평가

타입 변환을 하지 않고 그대로 반환 하는데 이를 단축 평가 라고 한다.

• 단축 평가는 표현식을 평가하는 도중에 평가결과가 확정된 경우

• 나머지 결과를 생략

• 단축평가를 사용하면 if문 대체

• 삼항 조건 연산자는 if-else 문을 대체

단축 평가 표현식    평과 결과
true ¦¦ anything    true
false ¦¦ anything    anything
true && anything    true
false && anything    false

9.4.1 논리 연산자를 사용한 단축 평가

논리합|| 또는 논리곱&&.

• 표현식의 평가 결과는 불리언 값이 아닐 수도 있다

• 논리합|| 또는 논리곱&&. 연산자 표현식은 언제나 2개의 피연산자 중 어느 한쪽으로 평가된다

• 논리곱&& 연산자 는 두 개의 피연산자가 모두 true로 평가될 때 true 를 반환.

• 좌항에서 우항으로 평가가 진행.

• 논리합|| 연산자는

• 두 개의 피연산자 중 하나만 true로 평가되어도 true 를 반환.

'cat' || 'dog'   // cat
false || 'dog'   // dog
'cat' || false   // cat

'cat' && 'dog'   // dog
false && 'dog'   // false
'cat' && false   // false

제어문은

• 조건에 따라 코드 블록을 실행 하거나(조건문)
• 반복 실행(반복문) 할 때 사용

코드는 위에서 아래로 순차적으로 실행하는데,

• 제어문을 사용하면 코드 실행 흐름을 인위적으로 제어할 수 있다. 하지만 직관적인 코드의 흐름을 혼란스럽게 만들어서 코드의 가독성을 해치는 단점이 있다.
• forEach, map, filter, reduce 같은 함수형 프로그래밍 기법에서는 제어문의 사용을 억제하여 복잡성을 해결하고자 노력한다.

8.1 블록문

0개 이상의 문을 중괄호 {} 로 묶은 것으로 코드 블록 이라고 부르기도 한다.

• 자바스크립트에서는 블록문을 하나의 실행단위 로 취급한다.

// 블록문
{
  var foo = 10;
}

// 제어문
var x = 1;
if (x < 10) {
  x++;
}

// 함수 선언문
function sum(a, b) {
  return a + b;
}

8.2 조건문

주어진 조건식의 평가 결과에 따라 코드 블록의 실행을 결정 한다.

• 자바스크립트는 if-else 문과 switch 두가지 조건문을 제공한다.

8.2.1 if-else 문

• 주어진 조건식에 따른 참과 거짓(true / false) 으로 평가
• 조건식의 개수에 따라 코드 블록을 늘리고 else if 문을 사용
• 대부분의 if-else 문은 삼항 조건 연산자로 바꾸어 사용 할 수 있다.

if (조건식) {
  // 조건식이 참이면 이 코드 블록이 실행
} else {
  // 조건식이 거짓이면 이 코드 블록이 실행
}

if (조건식1) {
  // 조건식1이 참이면 이 코드 블록이 실행
} else if (조건식2) {
  // 조건식2이 참이면 이 코드 블록이 실행
} else {
  // 조건식1, 2 모두 거짓이면 이 코드 블록이 실행
}

8.2.2 switch 문

• 주어진 표현식을 평가하여 그 값과 일치하는 표현식을 가지는 case 문으로 실행
• case 문은

1. 상황(case) 을 의미하는 표현식을 저장하고
2. 콜론(:) 으로 끝난다.
3. 그 뒤에 실행할 문들을 위치시킨다.

• switch 문의 표현식과 일치하는 case 문이 없다면

• default 문으로 이동

• default 문에서 break 문을 생략하는 것이 일반적

switch(표현식) {
  case 표현식1: 
    표현식과 표현식1이 일치하면 실행될 문;
    break;
  case 표현식2: 
    표현식과 표현식2이 일치하면 실행될 문;
    break;
  case 표현식3: 
    표현식과 표현식3이 일치하면 실행될 문;
    break;
  default: 표현식과 일치하는 case문이 없을 때 실행될 문;
}

__풀 스루(fall through) ? __ switch 문을 탈출하지 않고 switch 문이 끝날 때 까지 모든 case 문과 default 문을 실행되는 것을 말한다.

• 풀 스루 예시

  // 월을 영어로 변환한다. (4 -> 'April')
  var month = 4;
  var monthName;
  

switch(month) { case 1: monthNAme = 'January'; case 2: monthNAme = 'February'; case 3: monthNAme = 'March'; case 4: monthNAme = 'April'; case 5: monthNAme = 'May'; case 6: monthNAme = 'June'; case 7: monthNAme = 'July'; case 8: monthNAme = 'August'; case 9: monthNAme = 'September'; case 10: monthNAme = 'October'; case 11: monthNAme = 'November'; case 12: monthNAme = 'December'; default: monthName = "Invalid month" } console.log(monthName); // Invaild month

***

## 8.3 반복문
반복문은
- __조건식의 평가 결과가 참인 경우 코드 블록을 실행__
- 자바스크립트는 __for__, __while__, __do-while__ 문을 제공

<br>

### 8.3.1 for 문
> __조건식이 거짓으로 평가될 때까지 코드 블록을 반복 실행__

- for 문의 변수 선언문, 조건식, 증감식은 모두 옵션이므로 반드시 사용할 필요는 없다.

```js
for (변수 선언문 또는 할당문; 조건식; 증감식) {
  // 조건식이 참인 경우 반복 실행할 문;
}

8.3.2 while 문

주어진 조건식의 평가 결과가 참이면 코드 블록을 계속 실행하며 반복

• for 문은 반복 횟수가 명확할 때 주로 사용
• while 문은 반복 회수가 불명확할 때 주로 사용

while(조건식) {
  // 조건식이 참일 때 실행할 문;
}

// 무한 루프
while(true) {
  // ...
}

• 무한 루프를 탈출하기 위해서는

• 코드 블록 내의 if 문으로 탈출 조건을 만들고, break 문으로 코드 블록을 탈출

8.3.3 do-while 문

코드 블록을 먼저 실행하고 조건식을 평가

• 따라서 코드 블록은 무조건 한 번 이상 실행

do {
  //  ...
} while (조건식);

8.3.4 break 문

주 사용은 반복문 또는 switch 문의 코드 블록을 탈출 할 때 사용

8.3.5 continue 문

반복문의 코드 블록을 현 지점에서 중단하고 증감식으로 실행 흐름을 이동

• break 문처럼 반복문을 탈출하지는 않는다.

var string = 'Hello world';
var search = 'l';
var count = 0;

// 문자열은 유사 배열이므로 for 문으로 순회할 수 있다.
for(var i = 0; i < string.length; i++) {
  // 'l' 이 아니면 현 지점에서 실행을 중단하고 반복문의 증감식으로 이동한다.
  if(string[i] !== search) continue;
  count++;
}
console.log(count); // 3

// 참고로 String.prototype.match 메서드를 사용해도 같은 동작을 한다.
const regexp = new RegExp(search, 'g');
console.log(string.match(regexp).length);  // 3

[slug] 값은 어떻게 활용할 것 인가? - pages/category/[slug].js

• slug 값에 따라서 우리가 원하는 페이지가 다르게 보여져야 합니다.

1. useRouter

• Next.js 에서 제공하고 있는 라이브러리

import { useRouter } from 'next/router' // 선언 const router = useRouter(); const { slug } = router.query;

1.1 category.js

import { useRouter } from "next/router";

const CategorySlug = () => {
    const router = useRouter()
    const { slug } = router.query

    return (
        <h1>Category {slug}</h1>
    )
}

export default CategorySlug;

query 가 있다면 ? /category/food?from=event {"slug" : "food", "from" : "event" }

2. 다중 슬러그

2.1

• pages/[username]/[info].js
• const { username, info } = router.query

2.1.2 폴더 구조

2.1.3 info.js

import { useRouter } from "next/router";

const userInfo = () => {
    const router = useRouter()
    const { username, info } = router.query

    return (
        <h1>Username's {username} {info}</h1>
    )
}

export default userInfo;

3. slug 는 배열

• pages/cart/[...slug].js
• const { slug } = router.query

3.1.1 폴더 구조

4. 옵셔널 slug

• 저번 포스팅 처럼 pages/cart/[...slug].js 를 /cart 로 접근하면 404가 나옵니다.
• 이유는 해당 폴더의 index.js 가 없기 때문입니다.
• 하지만 pages/cart/[[...slug]].js 해주면 존재하지 않아도 기본 페이지가 생성 됩니다.

4.1 폴더 구조

5. router.push

router 를 사용하면서 페이지 이동이 가능 합니다.

5.1 코드

import Link from "next/link";
import { useRouter } from "next/router";

const CartSlug = () => {
    const router = useRouter()
    const { data } = router.query

    return (
        <>
            <h1>CartSlug {JSON.stringify(data)}</h1>
            <Link href="/cart/2022/08/07">
                <a>2022년 8월 7일로</a>
            </Link>
            <button onClick={() => router.push('/cart/2022/08/10')}>2022년 8월 10일로</button>
        </>
    )
}

export default CartSlug;

6. Shallow Routing

• Next.js 에서 페이지를 그릴 때는 pre-render 를 우선적으로 고려 합니다.

  getServerSideProps / getStaticProps 등을 다시 실행시키지 않고, 현재 상태를 잃지 않고 url 을 바꾸는 방법

예를 들어, 상태는 유지하면서 url 만 바꾸고 싶은 경우 ?

• 사용자가 어떤 동작을 했고, 그 기록을 query 로 남기고 싶을 때

• query 로 남기면 사용자가 새로고침을 해도 유지 됩니다.

6.1 url 을 바꾸는 3가지 방식

• location.replace('url') : 로컬 state 유지 안됨 ( 리렌더 )
• router.push(url) : 로컬 state 유지 / data fetching 은 일어남
• router.push(url, as, { shallow : true }) : 로컬 state 유지 / data fetching X

6.1.1 location.replace

import { useRouter } from "next/router";
import { useState } from "react";

const userInfo = () => {
    const router = useRouter()

    const [clicked, setClicked] = useState(false)
    const { status = 'initial'} = router.query

    return (
        <>
            <h1>My Info</h1>
            <h1>click :  {String(clicked)}</h1>
            <h1>Status : {status} </h1>
            <button onClick={() => {
                alert('change')
                setClicked(true)
                location.replace('/username/info?status=change')
            }}>Edit : (replace)</button>
        </>
    )
}

export default userInfo;

• 버튼을 누르면 true -> false 가 되는 이유는
• url 을 바꾸기 위해서 페이지를 새로 가져왔기 때문 입니다.

6.1.2 router.push

import { useRouter } from "next/router";
import { useState } from "react";

const userInfo = () => {
    const router = useRouter()

    const [clicked, setClicked] = useState(false)
    const { status = 'initial'} = router.query

    return (
        <>
            <h1>My Info</h1>
            <h1>click :  {String(clicked)}</h1>
            <h1>Status : {status} </h1>
            <button onClick={() => {
                alert('change')
                setClicked(true)
                router.push('/username/info?status=change')
            }}>Edit : (push)</button>
        </>
    )
}

export async function getServerSideProps(){
    console.log('server')

    return {
        props : {},
    }
}

export default userInfo;

• 로컬의 상태는 유지되지만, 서버에서 지속적인 data fetching 은 발생 합니다.

6.1.3 shallow

import { useRouter } from "next/router";
import { useState } from "react";

const userInfo = () => {
    const router = useRouter()

    const [clicked, setClicked] = useState(false)
    const { status = 'initial'} = router.query

    return (
        <>
            <h1>My Info</h1>
            <h1>click :  {String(clicked)}</h1>
            <h1>Status : {status} </h1>
            <button onClick={() => {
                alert('change')
                setClicked(true)
                router.push('/username/info?status=change', undefined, {shallow : true})
            }}>Edit : (push)</button>
        </>
    )
}

export async function getServerSideProps(){
    console.log('server')

    return {
        props : {},
    }
}

export default userInfo;

• 로컬의 값, URL 전부 바뀌고 server 또한 불리지 않습니다.
• 정말 아무것도 안바뀌고 url 만 바뀐 상황입니다.
• 물론 동일한 페이지에서 query 만 바뀌는 상황만 입니다.

간단한 예시

index.js

{noticeList &&
     noticeList.map((item, index) => {
           return (
                  <Items
                     key={index}
                     onClick={() => router.push(
                          {pathname : `/setting/notice/[id]`, 
                           query : { id : `${item.notice_id}` }})}
                  >

[id].js

 const router = useRouter()
 const id = Number(router.query.id);

• 위와 같은 방법으로 변수에 값을 담을 수 있습니다.

정리

• Shallow Routing 은 Dynamic Routes -> slug 를 활용하는 방법
• 다중 slug -> [user]/[info].js/ , [...slug].js
• 옵셔널 slug -> [[...slug]].js
• Shallow Routing -> router.push(url, as, {shallow : true })

참고

• https://fastcampus.co.kr/dev_online_nextjs

Next.js 의 Router 는 file-system 기반

• file-system : 파일을 만들면 그 즉시 라우터로 인지되고 주소가 맵핑이 됩니다.
• pages/
• src/pages/

리액트에서는 별도의 Router 를 제공하지 않기 때문에 별도의 라이브러리를 사용해야 하지만, Next.js 는 기본적으로 제공을 합니다.

pages/ OR src/pages 둘 중 우선순위는?

• 우선순위는 pages/ 가 우선 입니다.

pages/index.js

import Link from 'next/link'
import { useEffect, useState } from 'react'

export async function getStaticProps(){
  console.log('server')

  return {
    props : {time : new Date().toISOString()}
  }
}

export default function Home() {

  return (
    <div>
      <h1><Link href="/ssg">SSG로 - pages -</Link></h1>
      <h1><Link href="/isr">ISR로 - pages -</Link></h1>
    </div>
  )
}

src/pages/index.js

import Link from 'next/link'
import { useEffect, useState } from 'react'

export async function getStaticProps(){
  console.log('server')

  return {
    props : {time : new Date().toISOString()}
  }
}

export default function Home() {

  return (
    <div>
      <h1><Link href="/ssg">SSG로</Link></h1>
      <h1><Link href="/isr">ISR로</Link></h1>
    </div>
  )
}

• 화면에는 pages 의 index.js 가 나옵니다.

즉, pages 폴더가 있다면, src 폴더 안의 pages 는 무시가 됩니다.

Nested routes

• pages/product/first-item.js => /product/first-item
• pages/settings/my/info.js => /settings/my/info

Tip, next.js 는 절대 경로 접근이 가능 합니다.

• 파일 깊이가 깊어질수록 ../ 을 하는 일이 많아집니다.
• 하지만 아래 설정을 하면 손쉽게 절대 경로로 접근이 가능 합니다.

jsconfig.json

{
    "compilerOptions" : {
        "baseUrl" : "src"
    }
}

first-item.js

// import Hello from '../../src/components/Hello'; // 기존
import Hello from '/src/components/Hello';

const first_item = () => {
    return (
        <>
            <h1>first_item</h1>
            <Hello/>
        </>
    )
}

export default first_item;

• 위의 이미지 처럼 동일한 결과가 나옵니다.

Nested routes 주의할점

/product/first-item 까지는 접근이 가능하지만, product 로는 접근이 안될까?

정답은 그냥 /product 를 입력하면 404 가 나옵니다.

• product 에 바로 접근하고 싶으면 해당 index.js 가 있어야 합니다.

slug

• pages/category/[slug].js => /category/:slug (ex. /category/food )
• pages/[username]/info.js => /:username/info (ex. /hyunho/info )

대괄호를 하고 어떤 값을 넣으면 그 값의 와일드카드처럼 동작을 합니다.

• 지금은 slug 를 한 뎁스만 사용했지만 [...slug].js 하면

• (ex. /cart/2022/06/24) 무한하게 접근 가능 합니다.

정리

• Router -> File system 을 토대로 구현
• pages/ 혹은 src/pages -> pages/ 가 우선순위, 하나만 가능
• 프로젝트 설정 -> jsconfig.json(절대경로)
• Slug -> 다양한 위계의 Dynamic 제공

참고

• https://fastcampus.co.kr/dev_online_nextjs

데이터 가져오기 -> 화면에 무엇인가를 그리려면 어디선가 데이터를 가져와야 합니다.

1. SSR (Server Side Render)

페이지에 대한 요청이 있을 때마다 서버에서 페이지를 만들어 반환 합니다. 서버에서 매번 연산을 해야하며 캐시를 사용하는 것이 상대적으로 어렵기 때문에 SSG에 비해 느립니다. 하지만 항상 최신의 정보를 보여주어야하는 경우, SSR를 사용하는 것이 좋다.

(프론트)서버에서 HTML 파일을 만들어서 보내기 때문에 CSR에 비해 사용자가 더 빠르게 화면을 인식할 수 있습니다. 하지만 이벤트 등 페이지의 동작을 위해서는 hydrate라는 과정을 통해서 JS 코드가 실행되어야 합니다.

• 서버가 그립니다.
• 그린다 : 데이터를 가져와서 나타낸다.

즉, 서버가 데이터를 가져와서 그린다.

1.2 SSR 을 담당하는 함수

getServerSideProps()

Next.js에서 SSR을 사용하기 위해서는 페이지에서 getServerSideProps() 를 통해 데이터를 받아와야 합니다.

• 빌드타임에만 실행되는 getStaticProps()와는 달리 getServerSideProps()는 페이지에 대한 요청이 있을 때마다 실행된다.

예시 1

function Page({ data }) {
  // 데이터를 통해 페이지 렌더링...
}

export async function getServerSideProps() {
  // 페이지를 요청할 때마다 매번 실행된다.
    // 데이터를 받아온다.
  const res = await fetch(`https://.../data`)
  const data = await res.json()

  // Pass data to the page via props
  return { props: { data } }
}

export default Page

예시 2

export async function getServerSideProps(){
  console.log('server')
  return {
    props : {time : new Date().toISOString()}
  }
}

export default function Home({time}) {
  return (
    <div className={styles.container}>
      {time}
    </div>
  )
}

• 위 코드를 실행시키면 터미널에서 server 라는 로그가 지속적으로 발생합니다.
• 이유는 서버에서 그리기 때문 입니다.
• 화면 콘솔창에는 찍히지 않습니다!!
• 페이지에서 props 를 받아서 자유롭게 사용 할 수 있습니다.

즉, getServerSideProps 는 서버에서 데이터를 가져왔고, 그것을 페이지에다가 props 로 전달한 것 입니다.

2. CSR ( Client Side Render )

Next.js 에서 CSR을 사용하는 경우는 두가지로 나누어볼 수 있다.

1. url을 입력을 통해 pre-rendering 된 페이지를 받고 useEffect()를 통해 데이터를 추가로 불러오는 경우
2. <Link/> 나 router.push()를 통해 페이지 전환이 일어나는 경우이다.

• SSR 과 정반대로 클라이언트가 그립니다.

  즉, 클라이언트가 데이터를 가져와서 그립니다.

2.1 CSR 을 권장하는 경우

페이지를 pre-rendering 할 필요가 없거나, 데이터의 업데이트가 자주 일어난다면 CSR을 사용하는 것을 권장 합니다. 예를 들어 유저 대시보드 페이지는 해당 유저만을 위한 비밀 페이지이기 때문에 SEO가 필요하지 않으며 따라서 pre-rendering할 필요도 없습니다. 또한 데이터가 자주 변경되기때문에 CSR이 적합 합니다.

2.2 CSR 을 담당하는 함수

• 따로 존재하지 않습니다.
• 기존 React 사용법과 동일 합니다.
• next.js 의 Link 등...

3. SSG ( Static-Site Generation )

빌드시 HTML 파일을 미리 렌더링하는 것이 SSG 입니다. 정적인 페이지에 주로 쓰이며, HTML 파일을 미리 생성하기 때문에 서버에서 매번 연산을 하지 않아도 될 뿐 아니라, 별다른 설정 없이 CDN 캐시 사용이 가능하기 때문에 SSR 보다도 훨씬 빠른 속도를 보여줍니다.

SSG는 Next.js 의 기본적인 렌더링 방식 입니다. 하지만 백엔드 서버로부터 데이터를 받아서 렌더링하는 경우, 페이지에서 useEffect()를 사용한다면 url을 통한 페이지 접근시 SSG로는 데이터가 필요없는 부분만 구성하고, 데이터를 필요로하는 부분은 CSR로 렌더링하게 됩니다.

페이지에서 데이터를 필요로 하는 부분이 클수록 사용자가 화면을 인식하는데 시간이 오래걸리며 이는 SSG의 장점을 전혀 활용하지 못하게 되는 것을 의미 합니다.

이는 Next.js 에서 제공하는 페이지 단위 함수 getStaticProps()를 통해 해결할 수 있습니다.

3.1 SSG 를 담당하는 함수

getStaticProps()

• yarn dev 를 사용하는 개발환경에서는 제대로 동작하지 않습니다. (SSG 가 SSR 처럼 동작 합니다!)
• 정확하게 확인하려면 빌드를 한 후 yarn start 를 해야 합니다.
• SSG 에서는 새로고침을 해도 페이지가 변함없이 동일 합니다. ( 콘솔조차 찍히지 않습니다. )

yarn build 를 할 때 페이지를 미리 만들었다는 뜻 입니다. 즉, 빌드하는 타이밍에 데이터를 다 가져와서 보여줄 페이지를 static 한 페이지를 미리 생성한 것입니다.

예시 1

function Blog({ posts }) {
  return (
    <ul>
      {posts.map((post) => (
        <li>{post.title}</li>
      ))}
    </ul>
  )
}

// getStaticProps 함수는 server-side에서 build 타임에만 실행된다.
export async function getStaticProps() {
  // build 타임에 데이터를 받아온다.
  const res = await fetch('https://.../posts')
  const posts = await res.json()

  // { props: { posts } }를 반환함으로써, 
  // Blog 컴포넌트는 빌드타임에 props 로 posts를 받을 수 있다.
  return {
    props: {
      posts,
    },
  }
}

export default Blog

• 보이는 바와 같이 getStaticProps는 빌드타임에 서버로부터 데이터를 받아와 반환하고
• getStaticProps를 사용하는 페이지는 빌드타임에 getStaticProps 로부터 props를 받아올 수 있습니다.
• 따라서 빌드타임에 데이터에 따른 화면 구성이 가능

예시 2

export async function getStaticProps(){
    console.log('server')

    return {
    props : {time : new Date().toISOString()}
    }
}

export default function ssg({time}) {

    return (
        <div>
            <h1>{time}</h1>
        </div>
    )
}

• 위의 예시처럼 dev 환경에서는 새로고침하면 시간이 계속 변하지만 (SSR 처럼 node에 로그가 찍힙니다.)
• 빌드하고 배포한 후 실행하면 정적인 페이지가 만들어집니다. (새로고침해도 시간이 화면의 시간이 변하지 않습니다.)

3.2 동적이지도 않고 정적인데 필요한 이유는 ?

• SSR 은 항상 접근 할 때 마다, 즉 새로고침 할 때 마다 서버가 동작 합니다

즉, 데이터를 그릴 때 마다 서버가 동작하고 여러 사용자가 접근한다고 하면 서버의 부하가 많아집니다.

• 하지만 SSG 를 사용하면

정적인 페이지 한정이지만, 그 페이지는 누가 접근해도 빌드할 때 이미 만들어져있는 것을 보여주기 때문에 서버의 부하 없이 서비스를 제공 할 수 있습니다.

3.3 SSG 페이지의 데이터가 변경되면 ? : revalidate

빌드 타임에 정적파일을 생성하기 때문에 이후 데이터 변경이 일어나도 페이지에 반영이 되지 않습니다.

이런 문제를 해결하기 위해 getStaticProps() 에는 revalidate라는 옵션이 존재하며 초 단위로 입력할 수 있다.

빌드를 통해 페이지가 생성된 후 revalidate 값(초)이 지나기 전 들어오는 요청에 대해서는 기존의 페이지를 반환 합니다. revalidate 값이 지나고 들어오는 최초 요청에 대해서는 기존 페이지를 반환하고 페이지를 새로 빌드 합니다. 이후 들어오는 요청에 대해서는 새로 빌드된 페이지를 반환.(반복)

즉 revalidate에 10을 입력했다면 10초마다 재빌드 되는 것이 아니라, 10초 이후 요청이 새로 들어왔을 때 재빌드 하여 새로운 페이지를 만드는 것 입니다.

export async function getStaticProps() {
  const res = await fetch('https://.../posts')
  const posts = await res.json()

  return {
    props: {
      posts,
    },
    // Next.js will attempt to re-generate the page:
    // - When a request comes in
    // - At most once every 10 seconds
    revalidate: 10, // 초 단위
  }
}

• 아래 ISR 에서 한번 더 나옵니다.

4. ISR ( Incremental Static Regeneration )

• 증분 정적 사이트를 재생성 합니다.
• 재생성한다 : (특정 주기로) 데이터를 가져와서 다시 그립니다.

즉, (특정 주기로) 정적인 사이트의 데이터를 가져와서 다시 그린다.

4.1 getStaticProps ( with revalidate )

• revalidate 에 얼마 주기로 재생성 될지를 결정 합니다.
• SSG 처럼 개발환경이 아닌 빌드 후 배포해서 확인 합니다.

isr.js

export async function getStaticProps(){
    console.log('server')

    return {
    props : {time : new Date().toISOString()},
    revalidate : 1, // 1 초
    }
}

export default function isr({time}) {

    return (
        <div>
            <h1>{time}</h1>
        </div>
    )
}

• 기존 SSG 는 새로고침해도 페이지의 숫자나 값이 동적으로 변하지 않습니다.
• 하지만 ISR 은 설정한 특정 주기대로 화면을 동적으로 변화시킬 수 있습니다.

• 새로고침을 아무리해도 1초 간격으로 실행이 됩니다.

정리 ( Data Fetching )

• 페이지를 그리는 방식 -> 데이터를 가져와서 그린다.
• 3 + 1 -> SSR / CSR / SSG / ISR
• SSG -> yarn dev 로는 SSR 처럼 동작
• 필요에 맞춰서 -> SSR은 서버 부하 / SSG + ISR

참고

• https://fastcampus.co.kr/dev_online_nextjs
• https://velog.io/@sj_dev_js/Next.js-%EC%97%90-%EB%8C%80%ED%95%9C-%EA%B1%B0%EC%9D%98-%EB%AA%A8%EB%93%A0-%EA%B2%83

1. 문제는 어디서 발생하는가?

협업과 제품을 만들어나가는 과정에서

1.1 프로덕트의 문제

• Scale 이 커져가는 과정에서 주로 발생한다.(즉, 서비스의 규모가 어느정도 될 때)
• 기업은 리소스가 제한적이며, 시간이 부족하다.

이는 스타트업와 일반기업 또한 크게 다르지 않다. 제한된 리소스와 부족한 시간은 둘다 같다. 그나마 차이점은, 스타트업은 시니어 엔지니어가 없는 경우가 주로 있고 실패 비용이 크게 다가오기도 한다.

1.2 제한된 리소스란

• 인적 자원의 부족
• 부족한 시간

이를 해결하기 위해서는 역랑 한계를 인정 하고 드러내야 한다.

1.3 리스크를 줄이기 위한 노력

1. 필요없는 기능 최대한 배제 -> MVP 에 집중
2. 클린 코드에 집착 X -> 동작하는 코드가 가장 가치있는 시기가 있다.

1.4 MVP 란

“Minimum Viable Product”, 즉 최소 기능 제품의 줄임말. 최소한의 기능을 가진 제품이라는 뜻이다.

참고 : https://www.itworld.co.kr/t/61023/%EA%B0%9C%EB%B0%9C%EC%9E%90/212179

1.4.1 서비스 관점의 MVP

1. 개발자가 판단한 MVP가 정답인지 의심하라.
2. 직관이 통하는 세계가 존재함을 인정하라. 직관은 과학이 아님을 인정하라.
3. 개발자의 역할은 직관의 실패 리스크를 최소화하며 피봇할 수 있게 지원하는 것이다.

1.4.2 기술 관점의 MVP

1. 어떤 기술이 적정기술인가?
2. 최대한 포기하라, 포기할 것과 포기하지 못하는 것을 분류하고 검토하라.
3. 기술보다 중요한건 속도다. 언제나 서비스의 생존이 최우선이다.

2. 웹을 설계하는 방식

2.1 환경(mobile이든, pc이든)에 무관한 고려사항

• 웹의 철학과 특징을 고려하기
• 기술이 서비스 성공의 촉매 역할이 될 수 있다.
• 모든 것이 공유될 수 있는 자원이 될 수 있다.
• 외부 서비스 연동 정보를 정리하여 관리하기

2.2 디자인과 디테일한 UX/UI

• 신규 서비스의 어설퍼 보이는 UX는 좋은 이미지를 만들 수 없고, 가치가 하락한다.
• 발빠른 테스트와 릴리즈를 위한 아키텍처를 처음부터 고려하기
• UX의 견고함과 기능이 경합을 벌이면 견고함을 선택하기

2.3 최신기술을 사용하기

• 레거시 없는 서비스라는 장점
• 낮은 브라우저 버전에 목매이지 않기

  레거시는 낡은 기술이나 방법론, 컴퓨터 시스템, 소프트웨어를 말합니다.

2.4 사용자 로그를 수집하고 분석하기

• 로그는 필수, 초기부터 로그를 수집하는 것이 좋음

3. 웹뷰 개발을 설계하는 방식

현대의 서비스는 대게 앱을 중심으로 서비스를 운영한다. 앱은 안드로이드와 IOS 양강체제 -> 2개의 환경이 제공하는 것을 통해 개발하는 것이 native app 하지만, Native app 형태로만 개발하기에는 많은 비용이 필요하기에 웹 기술을 활용한 하이브리드 형태가 많이 시도되고 발전되어 왔다.

대부분의 앱은 네이티브 앱 아키텍처에 기반한 웹 기술을 섞어서 사용하고 있다. 그 중 하나가 웹 뷰

3.1 네이티브 앱 패키징 아키텍처

1. 네이티브 컨테이너 + 단일 웹뷰

• 앱스토어 규약 위반 가능성, 네이티브 기능을 탑재해야 함
• 모바일 웹 채널을 운영하고 있고 빠르게 앱을 출시하기를 원할 경우 유용 ex) 푸시, 카메라, 네이티브 인증(페이스 타임, 지문 인식 등)

2. 네이티브 + 멀티 웹뷰

• 웹 뷰간 데이터 교환 방법을 초기부터 고안해야 함
• 앱에 저장소를 만들고 웹 뷰에게 인터페이스를 제공

3. 네이티브 + RN

• 변화가 많은 지면은 RN 으로 개발, 그 외의 지면은 네이티브 개발
• 웹뷰 개발 시 존재할 수 있는 사용성 관련 이슈를 방지
• 역량 있는 네이티브 개발자 필요

3.2 앱 패키징 아키텍처와 무관한 고려 사항

1. 네이게이션 룰을 확립

• 웹 페이지는 각각의 URL이 존재하지만 네이티브에서는 그렇지 않다.
• 깊이가 깊은 화면에 직접 접근할 수 있는 방법을 초기에 설계해야 함(Deep Link)

  사용자가 어떤 상황에서도 direct 로 접근 할 수 있는 deep link 를 모든 화면에 설계 하는 것이 좋다.

2. 공개용 웹뷰와 내부용 웹뷰를 분리

• URL이 노출될 경우 보안상 문제가 생길 위험이 있는지 고려하여 웹뷰를 분리

3. 보안을 고려

• API 연동 토큰 및 앱 메타 정보 등 서버가 필요로하는 정보를 어떻게 관리할 것 인가

4. 개발환경을 구축

• 웹뷰 vs 브라우저, 시뮬레이터 vs 실기기의 차이점이 존재함을 인지
• 개발 단계에서 개발자가 경험할 수 있는 환경을 미리 준비
• 개발자간 쉽게 방법을 공유할 수 있도록 문서화하고 변경사항을 업데이트

5. 런타임 오류를 수집

• 특정 기기에서 발생하는 오류일 경우 개발자가 발견하기 어려움
• 고객 입장에서 개발팀이 원하는 수준의 리포팅을 하는 것은 현실적으로 불가능

6. 캐싱을 적극적으로 활용

• 모바일 특성상 네트워크 상태가 불안정한 경우에도 동일한 사용자 경험을 제공
• 프리젠테이션 컴포넌트는 독립적으로 운영
• 아키텍처를 변경해야 할 여지가 있으므로 충분한 가치가 있는 작업인지 신중히 고려
• 웹뷰의 생명주기를 알 수 있는 인터페이스 설계 ex) 웹뷰가 캐싱된 데이터로 렌더할지 데이터 페칭이 필요한지 여부를 네이티브에서 제공

4. 신규 개발 관점에서의 리스크

4.1 리스크 종류

4.1.1 커뮤니케이션

무엇이 문제인가 ?

• 회의는 커뮤니케이션의 종료가 아닌 시작이다.
• 문서를 보고 이해했다는 피드백은 진짜 이해한 것이 아니다.
• 기획자, 디자이너, 테스트, 개발자는 생각하는 방식이 다르며 이는 자연스러운 것이다.

일반적인 개발 진행

브레인스토밍 -> 기획 -> 디자인 & 백엔드 개발 -> 프론트앤드 개발 -> QA -> 릴리즈

즉, 같은 문제에 대한 다른 이해는 자연스럽다는 것을 이해하는 것이 문제 해결의 시작이다. 그러나 이해한다고 해서 모든 문제가 해결되는 것은 아니다.

4.1.2 해결책

1. 프로젝트 사전을 만들고 지속적으로 운영하며 공유

프로젝트 사전?

1. 압축된 용어는 의미를 포괄

-> 전문적인 일을 할수록 압축된 용어로 커뮤니케이션 비용을 줄인다. 2. 합의를 이루어 용어와 의미의 관계를 1:1 로 만든 사전을 만들어 운영 -> 사전에 당연해 보이는 용어조차 생략해선 안되며 모든 용어가 존재해야 한다.

2. 프로토타입을 만들어라 ( 작동 시켜라)

• 정적인 것은 상상력을 자극한다. -> 즉, 다양한 해석을 낳는다.
• 제품 개발 전반의 과정 중 70% 를 정적인 결과물을 기반으로 커뮤니케이션 된다.
• 수 많은 프로토타입 개발 도구가 있다. ( 적극적으로 활용 하자 )

동작하는 제품만이 오해를 막을 수 있는 유일한 방법이다.

프로토타입에 대한 오해

1. 프로토타입은 POC 가 아니다.

   POC ? 새로운 프로젝트가 실제로 실현 가능성이 있는가, 효과와 효용, 기술적인 관점에서부터 검증을 하는 과정을 의미 출처: https://engineer-mole.tistory.com/35 [매일 꾸준히, 더 깊이:티스토리]

• 프로토타입에 사용한 코드를 프로덕션 코드로 가지고 가지 말아야 한다,

• 프로토타입에 코드가 사용될 필요는 없다.

• 중요한 것은 동작하는 결과물이다.

2. 디자인이 나온 후 프로토타입을 만든다.

• 프로토타입은 가능하다면 모든 단계 만들어야 한다.
• 이상적이라면 프로토타입의 결과가 기획서, 디자인 이어야 한다.

• 디자인이 나왔다면 이미 프로토타입을 개발할 타이밍은 지나갔다.

3. 프로토타입은 정적인 데이터로 만든다.

• 프로토타입의 가장 빛나는 가치는 올바른 사용자 흐름 확인이다.
• 화면을 정적인 데이터로 채우지 마라
• 웹앱의 데이터는 네트워크를 통해 전달되며 네이트워크는 언제나 예외의 잔치다.
• 서버 데이터를 이용하고 레이턴시를 프로토타입에 반영하라.

레이턴시란? '잠복' 혹인 '대기시간' 이라는 사전적 의미를 가진다. IT 에서는 컴퓨터가 원하는 결과물을 만들어 내기까지 발생하는 지연시간의 총합이라고 볼 수 있다.

4. 프로토타입은 기획과 디자인을 위한 것이다.

• 데이터는 구조(스펙)를 가진다.
• 구조는 UI 를 구성하는 핵심 요소이다.
• 백엔드 개발자에게 영감을 주어라

3. 네트워크를 묘사해라

웹앱은 네트워크 어플리케이션이다.

• 화면과 하면 사이, 데이터와 데이터 사이에 비동기 상황이 존재한다.
• 비동기 상황 처리의 단단함은 서비스의 품질에 직결된다.

5. 유지, 개선 관점에서의 리스크 관리

5.1 Legacy

레거시 시스템 은 낡은 기술이나 방법론, 컴퓨터 시스템, 소프트웨어 등을 말한다. 이는 현대까지도 남아 쓰이는 기술을 부르는 말일 수도 있지만, 더 이상 쓰이지 않더라도 현대의 기술에 영향을 주는 경우도 포함한다. 출처 : 위키백과

5.2 Legacy 를 대하는 자세

존중

• 모든 코드는 릴리즈 되는 순간 레거시 코드다.

• 서비스를 생존시킨 레거시 코드는 존중받아 마땅하다.

비난 받아 마땅한 코드는 없다. 그러나 개선하기 힘든 코드는 있다.

5.3 개선하기 어려운 코드를 개선하기 위한 전략

시각화를 하자 -> 시각화 되지 않은 문제는 불만일 뿐이다.

5.4 레거시 코드 분석 실패의 이유

1. 기술 난이도가 높은 코드

-> 역량 한계를 인정하고 공개한 후 함께 해결책을 찾아라

2. 잘못된 구조로 규모가 커진 코드

-> 엔지니어의 역할은 깨끗한 코드를 깨끗하게 유지하는 것이 아니다. -> 개발자의 역할은 제품을 만드는 것이다. -> 좋은 코드는 좋은 제품을 만들기 위한 요소 중 하나일 뿐, 필수 조건은 아니다.

6. 소프트웨어의 생명주기

6.1 제품의 수명은 몇년일까

프론트엔드는 1년 이상 쓰이는 코드는 많지 않다.

6.2 안정적인 프로덕트를 위한 코드 구조와 관리

6.2.1 유형

-> 뒤섞이면 문제가 발생한다.

• HTML
• CSS
• Code/Logic/Rule
• Domain/Data/State
• Effect

6.2.2 변형 주기

• Design/Visual/Struct
• Config

• 분리가 안 되어 있으면 서버가 바뀔 때마다 코드가 새로 배포되어야 한다.

• Assets/Information

• 약관 같은 것들도 Information에 포함이 된다.

6.2.3 오너십

• Library
• Framework
• Service

6.2.4 위치

• Internal
• External

참고

• https://fastcampus.co.kr/dev_red_kmt

https://redux-toolkit.js.org/

사용하는 이유

Redux Toolkit은 Redux를 더 사용하기 쉽게 만들기 위해 Redux에서 공식 제공하는 개발도구 Redux Toolkit은 아래와 같은 Redux의 문제점을 보완하기 위해 등장 하였습니다.

기존 리덕스의 문제

• 저장소 구성의 복잡성
• 많은 패키지 필요성(의존성) + 미들웨어 등..
• 한 작업 시 필요한 수 많은 코드양(boilerplate)

Redux Toolkit 설치

npm
npm install @reduxjs/toolkit

yarn
yarn add @reduxjs/toolkit

기존 redux 를 이용한 카운터

import './App.css';
import { createStore } from 'redux';
import { useSelector } from 'react-redux'; // useSelector 를 통해 카운터가 스토어의 value 값을 가져온다
import { Provider } from 'react-redux'; //  provider 를 통해 애플리케이션에 공급
import { useDispatch } from 'react-redux' // 버튼을 눌렀을 때 state 값을 바꾸는 dispatch 


// 초기값
const initialState = {value : 0};

// 스토어
const store = createStore(reducer, initialState);

// 리듀서
function reducer(state, action){
  if(action.type === 'up'){
    return {...state, value : state.value + action.step} 
    // 불변하게 코드를 다루기 위해 기존의 코드를 복제 ({...state} 부분)
  }
  return state;
}

// 버튼을 누르면 숫자가 증가하는 카운터
function Counter(){
  const dispatch = useDispatch();
  const count = useSelector(state => state.value)
  return (
    <div>
      <button onClick={()=>{
        dispatch({type : 'up', step : 2}); 
      }}>+</button>{count}
    </div>
  )
}


function App() {
  return (
    <Provider store={store}>
      <div>
        <Counter></Counter>
      </div>
    </Provider>
  );
}

export default App;

지금까지는 하나의 store 안에 모든 정보를 담았다.

하지만 프로그램이 커지면 기능별로 작은 스토어를 만들고 싶어질수 있습니다. 이러한 작은 스토어를 slice 라고 부르겠습니다.

그러면 작은 스토어들을 합쳐서 리덕스 툴킷이 리덕스가 요구하는 큰 스토어로 알아서 만들어 줍니다.

카운터라는 기능을 위한 - slice

import {createSlice} from '@reduxjs/toolkit'; 

const counterSlice = createSlice({
  name : 'counter', // 슬라이스의 이름
  initialState : {value : 0}, // 스토어는 초기 값이 필요
  reducers : {
    up : (state, action) => {
      state.value = state.value + action.payload; 
      // up 타입일 때 처리해야하는 리듀서 (dispatch 역할)
    }
  }
});

• 위와 같은 작은 slice 를 모아서 하나의 큰 스토어로 만들때는 configureStore 사용

하나의 큰 스토어 - configureStore

const store = configureStore({
  // 객체를 전달하고 필수적으로 reducer 전달
  reducer : {
    counter : counterSlice.reducer 
    // up을 포함하여 counterSlice 안에 들어있는 리듀서 여러가지들을 하나로 해준다.
  }
}) 

• counterSlice 안에 있는 리듀서들이 있다면, 즉 up 말고 down 이나 여러가지가 있을 수 있는데 이것들을 하나로 합쳐서 하나로 만든 리듀서를 자동으로 만들어줍니다.
• 그렇게 만들어진 리듀서가 counter

useSelector 사용

const count = useSelector(state => state.value) // 기존 리덕스의 useSelector

const count = useSelector(state => {
    return state.counter.value // 0
  // count 값은 counterSlice의 전달한 value 초기값
  }) 

dispatch 사용

function Counter(){
  const dispatch = useDispatch();
  //const count = useSelector(state => state.value) // 기존 리덕스의 useSelector
  const count = useSelector(state => {
    return state.counter.value // count 값은 counterSlice의 전달한 value 초기값
  }) 

  return (
    <div>
      <button onClick={()=>{
        // dispatch({type : 'up', step : 2}); 기존 리덕스
        dispatch(counterSlice.actions.up(2)) 
      }}>+</button>{count}
    </div>
  )
}

전체 코드

import './App.css';
import { createStore } from 'redux';
import { useSelector } from 'react-redux'; // useSelector 를 통해 카운터가 스토어의 value 값을 가져온다
import { Provider } from 'react-redux'; //  provider 를 통해 애플리케이션에 공급
import { useDispatch } from 'react-redux' // 버튼을 눌렀을 때 state 값을 바꾸는 dispatch 

import {createSlice, configureStore} from '@reduxjs/toolkit'; 

const counterSlice = createSlice({
  name : 'counter', // 슬라이스의 이름
  initialState : {value : 0}, // 스토어는 초기 값이 필요
  reducers : {
    up : (state, action) => {
      state.value = state.value + action.payload;
    }
  }
});

const store = configureStore({
  // 객체를 전달하고 필수적으로 reducer 전달
  reducer : {
    counter : counterSlice.reducer 
    // up을 포함하여 counterSlice 안에 들어있는 리듀서 여러가지들을 하나로 해준다.
  }
}) 

function Counter(){
  const dispatch = useDispatch();
  //const count = useSelector(state => state.value) 기존 리덕스의 useSelector
  const count = useSelector(state => {
    return state.counter.value // count 값은 counterSlice의 전달한 value 초기값
  }) 

  return (
    <div>
      <button onClick={()=>{
        // dispatch({type : 'up', step : 2}); 기존 리덕스
        dispatch(counterSlice.actions.up(2)) 
      }}>+</button>{count}
    </div>
  )
}


function App() {
  return (
    <Provider store={store}>
      <div>
        <Counter></Counter>
      </div>
    </Provider>
  );
}

export default App;

참고

• https://www.youtube.com/watch?v=9wrHxqI6zuM
• https://redux-toolkit.js.org/

서적을 읽고 내용과 개인 생각을 정리한 글 입니다.

1. 학습 : 이론과 실전

프론트엔드 를 시작하려는 많은 개발자들이 커리어 로드맵을 따라 HTML, CSS, JS 를 먼저 배워야만 개발을 시작 할 수 있다고 생각 한다. -> 물론 언어적 특성과 문법을 아는 것은 개발을 하는데 굉장히 큰 도움이 된다. ( 나도 그랬다... 하고 싶은데 방향을 못 잡아서 이런거 저런거 보다 언어 배우기 부터 했었다.)

하지만 그것이 개발의 전부는 아니다.

1.1 개발자로서 개발을 학습 할 때 두 가지의 영역

1.1.1 제품을 만드는 영역

말 그대로 제품을 만들어내는 능력

• 스펙을 분석해서 적절한 수준의 기술 스택을 선택하여 만들어내서 어딘가에 가치를 만드는 것 ex) 개인 블로그를 누구는 워드프레스, 누군가는 React 를 사용해서 블로그를 만든다.

이 영역에서 가장 중요하다고 생각 하는 것은 '문제를 해결하는 능력' 이라고 생각 한다.

• 만들어나가는 과정에서 다양한 문제들을 직면하고, 하나씩 해결해나가면서 제품을 만든다.
• 이게 중요한 이유는 특히 프론트엔드 개발자들은 유저들이 사용하는 제품을 만드는 것이 주된 업무이기 때문이다.

만약 이론을 아무리 많이 알고 있어도 제품을 만들 수 없다면 능력을 제대로 활용하기 있다고 보기 어렵고, 오히려 이론을 완벽히 이해했다고 보기 어려운 상태일 수도 있다.

1.1.2 원리를 이해하는 영역

원리를 이해하는 영역은 내가 만든 코드, 혹은 다른 사람이 만든 코드가 어떻게 동작하는지 ex) '자바스크립트 엔진이 어떻게 동작하는가', '렌더링 엔진은 어떻게 동작하는가' 등

원리를 이해하는 영역을 모른다고 제품을 만들지 못하는 것은 아니지만, -> 좋은 제품을 만들기 위해서는 원리를 이해하고 있어야 한다.

원리를 이해해야 디버깅하기 좋은코드, 유지보수 하기 좋은 코드, 성능이 좋은 코드가 나온다. -> 무엇보다 다른 사람의 코드를 리뷰 할 때도 명확한 이유를 바탕으로 리뷰할 수 있다.

위의 두 가지 영역은 뗄 수 없는 관계다.

개발자들에게 위의 영역들은 뗄 수 없는 관계임에도,

• 많은 개발자들이 원리에만 치우쳐 제품을 만들지 않거나
• 제품에만 치우쳐 원리를 이해하지 못하는 상황이 종종 존재한다.

위와 같은 상황이되면, 프로젝트는 많이 해봤지만 실속은 부족한 사람이 될 수 있고, 지식은 많지만 경험이 적은 사람이 될 수 있다.

1.2 솔루션

제품을 만드는 것만 초점을 맞추다보면 '이 코드가 왜 동작하는지 모르지만 어쨌든 동작은 하는 상태' 가 완성된다.

이를 방지하기 위해서는

• 개발을 하다가 원리가 이해되지 않았던 부분을 키워드별로 정리하고, 프로젝트가 끝나면 블로그나 개별적으로 정리해서 발행하는 습관을 들이면 좋다.

2. 학습 : 선택과 집중

이제 막 개발 공부를 시작했다면, 배워야 할 내용이 많다.

이 말은 개발 시장이 성숙해졌다는 증거이기도 하지만, 그 만큼 수준 높은 개발자를 요구한다는 것 이다.

최근 개발을 배우는 학생들에게서 공통적으로 보이는 것은 조급함 이며, 굉장히 많은 내용을 한 번에 습득 하려다가 중요한 지식을 습득하지 못하는 경우를 많이 본다.

예를 들어, 자바스크립트가 어떻게 동작하는가에 대한 디테일한 지식은 지금 단계의 여러분에게 필요하지 않을 수 있다.

• 오히려, 당장 코드 한 줄이라도 쳐보면서 친해지는 과정을 거치고
• 버그가 나도 당황하지 않고 에러 로그를 보는 습관을 들이거나
• 제품 하나가 돌아가기 위해 어떤 일을 해야 하는지 파악하는 등의 일들이 우선시 되야 한다고 생각 한다.

처음부터 너무 많은 지식을 습득해야 할 것 같다고 지레 겁먹지 말자. -> 개발에서는 적어도 사용 사례를 이해하고 원리를 이해했을 때 더 이해가 잘된다고 생각하기 때문에, 개발에서의 학습 방법은 지금 내가 프로젝트에서 사용하고 있는 기술 중 모르는 것을 중점적으로 공부하자!

3. 비전공자 : CS 지식에 대해

만약 컴퓨터공학을 전공하지 않았다면 항상 '내가 비전공자 라서' 라는 생각이 들 수 있다. -> 어떻게 보면 당연하다. 전공을 한 사람이 개발을 잘할 가능성이 높다.

역으로 전공자라면 다른 전공자들은 다 잘하는 것 같은데 유독 나만 못하는게 아닌가, 라는 생각이 들 수 있다.

3.1 CS 지식은 어떻게 공부할까요 ?

기초 CS 지식을 다루고 있는 책은 많다.

• <1일 1로그 100일 완성 IT 지식>
• <한 권으로 읽는 컴퓨터 구조와 프로그래밍>

문제 해결 능력을 키우기 위해서는 코드를 많이 작성하는 것도 중요하지만, 문제와 계속 마주하며 친해지는 것도 중요하다.

• <알고리즘 문제 해결 전략>
• <코딩 인터뷰 완전 분석>

책을 좋아하는 이유는, 저자의 여러 노하우를 흡수할 수 있기 때문이다.

3.2 조급해하지 말자

시장은 심플하게 동작한다. 기업은 여러분의 능력이 자사의 문제를 해결하고 비즈니스에 도움이 될 거라고 생각하면 여러분을 채용 한다.

지금 채용에 떨어졌다고 해서 1년 뒤 또는 3년 뒤에 또 떨어진다고 보기는 어렵다. 계속 도전하면 적절한 상황이 도래했을 때 얼마든지 합격이 가능하다.

만약 기업의 채용 과정에서 탈락했다고 본인의 실력이 부족하다고 생각하지는 않았으면 한다. 회사마다 원하는 인재의 수준이나 상황도 다르기 때문에 '내가 실력이 부족해서 떨어졌구나' 라고 생각하는 건 감정 소모에 불과하다.

여러분은 스스로 생각하는 것보다 충분히 잘하고 있을 수 있다.

4. 블로그 : 기억은 짧다

이 책의 독자 대부분은 나를 블로그나 강의, 강연을 통해 알게 되었을 테다. 내가 강의, 강연을 시작하게 된 계기는 블로그였다. 내 모든 실무와 관련된 경험은 나의 블로그 속에 녹아있다.

개발자가 블로그를 해야 하는 이유는 여러 가지가 있겠지만, 가장 중요한 이유는 우리가 겪는 이슈 대부분은 언젠가 우리의 기억속에서 사라지기 때문이다. 이렇게 될 경우 훗날 비슷한 이슈를 겪게 될 때 지금까지 한 수고를 반복할 가능성이 높다는 것이다.

블로그에 작성하면 좋은 점은

• 프로젝트를 하면서 마주했던 문제와
• 그 문제의 해결 방안이다.

블로그의 또 다른 역할은

• 내가 얼마나 많은 지식을 보유하고 있는지를 나타내준다는 것이다.

과거 나는 구글 검색엔진의 동작에 대한 글을 작성했다. 글을 써나가면서 구글 검색 엔진의 동작 방식을 깊게 공부했기 때문에 누군가가 내 블로그를 볼 때 '조은 님은 적어도 검색엔진의 동작 방식을 잘알겠구나' 라고 인지할 수 있을 것이다.

개발자의 실력 증명은 의외로 어렵다.

내가 네이버에 다녔으니까 나를 뛰어난 개발자라고 부를 수 있을까 ? 우아한 형제들에 다녔으니까 뛰어난 개발자라고 부를 수 있을까 ?

• 내가 거쳐온 회사가 나의 커리어에 도움이 될 수는 있겠지만, 어떤 회사에 다녔다는 사실 자체가 나의 실력을 일방적으로 증명해주지는 못한다.

4.1 아무튼 글쓰기

이 글을 읽는 대부분이 글쓰기에 거부감 또는 어색함을 느낄 거라 생각한다. 하지만, 지금은 본인이 충분히 관심만 가진다면 양질의 콘텐츠에 접근하는게 얼마든지 가능하다.

• <개발자의 글쓰기>
• <개발자를 위한 글쓰기 가이드>

글쓰기에서 무엇보다 중요한 것은 완성이다. 지금 좀 마음에 들지 않더라도 혹은 부족하게 느껴져도, 잘못된 내용이 아니라면 발행해야 완성이 되고 글에 생명이 불어넣어진다.

일단 공개해보자. 의외로 많은 사람이 당신의 글에서 도움을 얻을 것이다.

4.2 블로그의 목표가 취업을 위해서라면

예전에는 취업을 위해 블로그를 운영한다는 사실 자체에 분개했던 적도 있지만, 모든 것이 스펙이 되어가는 이 시대에는 취업을 위해 블로그를 운영하는 것은 나쁘지 않다고 생각한다.

오히려 나는 블로그가 더 좋은 직장으로 가기 위한 적절한 전략 중 하나라고 생각한다.

작성한 블로그의 내용은 면접 질문으로 이어질 가능성이 높다. 따라서 블로그를 작성할 때는, 어느 정도 본인이 이해하고 있는 내용을 작성하는 것이 중요하다.

Today I Learned (TIL)

주변에 많은 취업 준비생들이 작성한다. 작성하는 행위 자체는 나쁘지 않은 습관이지만, 많은 사람이 TIL 을 하나의 업무라고 생각하면서도 결과적으로 그다지 좋은 글을 작성하지 못하는 경우가 종종 있다.

누군가 쓰라고 하니까 쓰기는 하는데 스스로 TIL의 필요성을 인지하지 못하는 것이다,

TIL 은

1. 기억이 휘발되기 전에 오늘 있었던 일들을 정리 하려는 목적
2. 오늘 공부한 내용을 나중에 다시 갈무리하기 위해 키워드를 수집하려는 목적으로 쓴다.

• 따라서 TIL 그 자체로 취업 등에 전략적으로 사용하기는 어렵다.

적어도 주니어 개발자, 현업에서 일하는 개발자에게는 업무에서 익힌 내용을 바탕으로 매일 무엇을 공부하고 경험했는지 글로 정리해놓는 게 도움이 될 수 있다.

TIL 전략

• 작성에 30분 이상 쓰지 않는다. 일단 쓰는 데만 집중
• 공개되지 않은 장소에 올린다. 학습 내용을 공유하고 싶다면 별도 블로그 게시물로 작성
• 공개된 장소에 업로드한다면 일주일치를 몰아서 올린다.

5. 이력서

이력서를 쓰는 방법에 대해서는 많은 글이 존재한다. 하지만 나는 이력서에 어떤 걸 쓰지 말아야 하는가에 집중해보고자 한다.

좋은 이력서란 추상적인 영역으로 면접관의 주관에 따라 그 형태가 다를 수 있기 때문이다.

5.1 이력서는 카탈로그다

이력서는 스스로를 판매하기 위한 내용을 여러 회사에 공유하며 '나를 채용하면 당신들 비즈니스에 도움이 될 거야' 라는 내용을 담은 일종의 카탈로그다.

이력서에 어떤 내용을 담을 때 고민해보면 좋은 내용은

1. 다른 사람과 비교할 때 내가 가진 이점
2. 내가 회사의 비즈니스에 어떤 도움을 줄 수 있는지 이다.

5.1.1 보편적인 좋은 점을 작성하지 않기

예를 들어 '열정 있는', '개발을 즐기는', '어제보다 오늘 더 성장하는' 등의 다양한 키워드를 사용하겠지만 생각해보면 그렇지 않은 개발자는 드물다.

한 줄 평을 작성할 때는 면밀하게 자기 자신에 대해 고민할 필요가 있다.

예를 들어 '열정 있는 개발자' 라고 한다면,

• 일일 커밋을 2 ~ 3 년 동안 했다거나,
• 지속해서 공부한 내용을 정리했다거나,
• 토이 프로젝트를 많이 했다거나 하는 액션이 필요하다.

액션 없이 말로만 '열정 있는 개발자' 라고 하는 건 무의미하다.

5.1.2 내용을 꾸역꾸역 채우지 않기

이력서에 쓰는 내용은 정제된 언어로, 꼭 필요한 내용 위주로 작성한다.

서류를 검토하는 사람들은 여러 사람의 이력서를 보기 때문에 필요한 내용만 정리된 이력서를 선호하며, 너무 많은 내용은 노이즈로 인식 할 수 있다.

5.1.3 클론 코딩 프로젝트 Only

클론 코딩은 어떤 기술을 학습하는 데 도움을 주며, 방식 자체도 나쁘다고 할 수는 없다. 하지만, 학습을 위해서가 아니라 취업을 위해 클론 코딩을 사용하겠다면 조금은 전략적이 될 필요가 있다.

1. 클론 코딩은 말 그대로 클론 코딩이어야 한다.

-> 많은 사람이 필요한 부분만 구현하고, 디테일은 놓치는 경우가 많다.

2. 목표 기업의 서비스를 클론해보는 것이 취업에 도움을 줄 수 있다.

-> 카카오에 지원한다면 카카오에서 제공하는 서비스를 클론해보고 -> 거기에서 UX를 개선한 형태로 프로젝트를 진행해 볼 수 있다. -> 이것은 당신이 해당 회사에 관심을 가지고 있다는 걸 확실히 어필해준다.

중요한 것은 회사가 실제 겪고 있을 문제를 추측함과 동시에, 제품이 가진 문제를 개선하는 경험을 해보는 것이다.

5.2 그렇다면 이력서에 어떤 내용을 담을까 ?

이력서에 담아야 하는 건 현재까지 살아온 삶이 아니라, 앞으로 개발자로서 삶을 잘 영위해나갈 수 있다는 내용이다.

아래와 같은 내용을 넣으면 좋다.

• 내가 현재 보유하고 있는 기술들과 그 수준
• 내가 현재 관심을 가지고 있는 내용들
• 커리어와 직접 연관된 프로젝트의 정보
• 내가 담당한 부분 기능에 대한 Overview
• 내가 겪은 문제, 해결 방안

될 수 있다면

• (가능하다면) 블로그를 통해 내가 가진 지식을 증명
• (가능하다면) Github를 통해 프로젝트를 공유
• (가능하다면) 지금까지 진행한 커리어에 도움이 되는 프로젝트

• 혹은 커리어에 직접 도움이 되지 않더라도 관심을 가질 수 있는 프로젝트

6. 면접

어느 회사의 면접을 보느냐에 따라 경험이 다르고, 면접 차수에 따라서도 면접 경험은 달라진다. A 회사는 기술면접에 무게를 싣는 데 반해, B 회사는 인성 면접에 무게를 싣기도 한다. 또한, 경력인지 신입인지에 따라 면접의 형태는 달라진다.

6.1 면접이라는 자리

회사 입장에서는 지원자가 우리와 핏(Fit) 이 맞는지 체크하는 시간이며 동시에 지원자 입장에서는 자기와 핏이 맞는지 체크하는 시간이기도 하다.

다시말해, 면접을 보러 가는 자리라고 해서 일방적으로 기가 죽을 필요는 없다.

6.2 기술 자체에 대해 물어보는 질문

기술 면접에서 물어보는 내용 중 순수하게 기술 지식과 관련한 질문은 준비만 잘하면 의외로 쉽게 풀어나갈 수 있다.

• 최근 기술력이 뛰어나다고 평가받는 기업들은 대부분 기술 블로그를 운영하기 때문에 그것을 보는 것도 좋은 전략이 될 수 있다.
• 면접에서는 보통 그 회사에서 쓰는 기술에 대한 질문이 나올 가능성이 높다.

기술 질문에서는 단골로 등장하는 질문이 있기 때문에 그런 것들을 공부해두는 게 좋다.

6.3 경험에 대해 물어보는 질문

예를 들어, 리액트를 이용해서 에디터를 만들어본 경험이 있는 지원자가 있다면

• 왜 에디터에서 React 를 사용하셨나요? -> React 의 장점과 단점은 어떤 것이 있나요?
• 에디터 자체는 어떤 식을 구현하셨나요? -> Contenteditable 을 사용하셨나요?
• 자동 저장 기능도 고려하셨나요? -> 했다면 어떻게 구현하셨나요?

경험에 대해 물어보는 질문은 크게 문제에 대한 정의와 그 문제를 해결하는 파트로 나누어지고, 문제에 대한 정의는 면접관이 대부분 질문을 통해 내리게 된다.

-> 이 질문에 대한 해답을 본인의 경험을 바탕으로 답변한다.

경험에 대한 질문에서는 꼬리 물기 식의 질문이 많이 나와 심리적 압박감을 느낄 수 있다. 그러나 물어보는 내용 중 답이 정해진 질문은 없기 때문에, 최대한 본인이 알고 경험한 것을 적극 공유하는 것이 좋다.

6.4 회사에 대한 질문

많은 면접에서 '회사에 궁금한 점을 말해보세요' 라는 질문을 던진다. 이 질문은 내가 이 회사에 얼마나 관심이 있는지, 또 기술적으로 얼마나 성장을 원하고 있는 지 어필 할 수 있는 중요한 시간이다.

6.4.1 물어보며 좋은 질문들

• 면접 중 답변을 못했거나, 애매하게 답했다고 생각되는 지식들
• 내가 합류할 조직의 서비스에 대한 질문
• 조직의 기업 문화, 코드 문화에 대한 질문
• 조직의 일하는 방식에 대한 질문
• 기술 블로그 중 인상 깊었던 부분

책을 읽으며, 프론트엔드 개발자가 되고 싶다고 처음 준비할 때 부터 봤다면, 준비하는 방향과 방식이 많이 달랐을 것 같다. 또한 이력서나 면접 부분 등 그리고 전공자이지만 부족하다고 느끼는 CS 지식에 대한 학습 방향까지 이제 막 인턴을 하고있는 지금이라도 읽게 되서 다행이라고 생각한다.

이 게시물을 종종 다시 읽으면서 나의 방향성과 지식들을 풍성하게 채울 수 있는 길을 가도록 노력해야 겠다.

1. Web Front End ?

1.1 Web

개방형 표준 기술

1.2 Front

프론트엔드의 프론트는 가장 앞에있는 시각적인 요소를 포함하고 사람들을 직접 마주 합니다.

• 시각적 요소가 많고 그렇기에 주관적인 부분도 많습니다.
• 개발자가 기술만 알고 있다고 해서 뛰어나다고 평가 받지 않을 수 있으며, UX 같은 부분들도 많이 고려 됩니다.
• 또한 빠르게 변화가 일어납니다.

1.3 End

프로세스적 관점에서 기획 -> 디자인 -> 백엔드 -> 프론트 등 사이클의 끝에 있습니다.

• 릴리즈 일자를 선정하나 계획이 변경되고 앞선 부분에서 기간의 조정될 때 프론트가 많은 부담을 가지게 됩니다.

2. 과거, 현재, 미래의 Front

1992

• http의 탄생과 같이 웹이 시작됨

2007

• 아이폰의 탄생, 모바일 생태계로 중심이 이동함 (1년 뒤, 앱스토어를 선보임)

2008

• 구글 크롬이 출시되며 V8 엔진을 선보임. 웹이 발전해야 하는데 가장 병목은 브라우저의 JavaScript 실행 부분이었음 (V8 엔진)

2009

• JavaScript를 일반 시스템에서 실행하기 위해서 빠른 V8 엔진을 사용한 node JS를 만듬 (지금의 프론트엔드 환경을 만들었다고 평가할 수 있음)

2010

• node 패키지 매니저인 npm의 등장 (08 ~ 10의 변화가 이후의 FE 10년의 환경의 기반이 됨)
• Angular과 knockout JS의 탄생 (이전의 WebApp은 jquery로 만들던 시절이었으며, Angular가 나오며 라이브러리 단계에서 프레임워크로 발전시킴, 보다 큰 앱을 단단하고 아키텍쳐를 가지고 설계될 수 있도록 하였음, knockout JS는 데이터 흐름을 라이브러리나 프레임워크 단계로 내릴 수 있는 설계를 제시함 - Two-Way Binding)

2012

• TypeScript 출시 

2013

• React 출시. Angular가 Two-Way binding의 장점과 동시에 단점이 부각되었으며 React는 대비적으로 One-way binding의 장점을 살림 (Virtual DOM 등과 같이)

~ 2020

• React, VueJS가 주류로 사용됨. 안정화

3. Front 개발자 유형

1. System 에 대한 지식이 있는 / 없는 개발자
2. Graphics(그래픽 시스템) 에 대한 관심이 있는 / 없는 개발자
3. UX 에 관심이 있는 / 없는 개발자

• 나는 어떤 유형의 개발자인가 생각을 해보고 전략을 세워보자!
  

3.1 프론트 엔드 개발자의 학습 전략

1. 개발자 모두가 알아야 하는 지식

-> Network, Memory, performance

2. 필요한 상황이 생기면 알고 싶지만 쉽게 배울 수 없는 지식

-> Graphics, Math

3. 필요하다면 쉽게 배울 수 있는 지식

-> JS, TS, React 등 같은 라이브러리 및 프레임워크

참고

• https://fastcampus.co.kr/

리덕스 모듈이란 다음 항목들이 모두 들어있는 자바스크립트 파일을 의미합니다.

• 액션 타입
• 액션 생성함수
• 리듀서

리덕스를 사용하기 위해 필요한 위 항목들을 각 다른 파일에 저장 할 수도 있습니다. 하지만, 코드들이 꼭 분리되어 있을 필요는 없습니다.

그래서 리듀서와 액션 관련 코드들을 하나의 파일에 몰아서 작성 할 것 인데 이것을 Ducks 패턴 이라고 부릅니다.

• 리덕스 관련 코드를 분리하는 방식은 정해져 있는 방식이 없으므로 자유롭게 분리해도 됩니다.

counter 모듈

modules/counter.js

/* 액션 타입 만들기 */
// Ducks 패턴을 따를땐 액션의 이름에 접두사를 넣어주세요.
// 이렇게 하면 다른 모듈과 액션 이름이 중복되는 것을 방지 할 수 있습니다.
const SET_DIFF = 'counter/SET_DIFF';
const INCREASE = 'counter/INCREASE';
const DECREASE = 'counter/DECREASE';

/* 액션 생성함수 만들기 */
// 액션 생성함수를 만들고 export 키워드를 사용해서 내보내주세요.
export const setDiff = diff => ({ 
    type: SET_DIFF, 
    diff
 });

export const increase = () => ({ 
    type: INCREASE
 });

export const decrease = () => ({ 
    type: DECREASE
 });

/* 초기 상태 선언 */
const initialState = {
  number: 0,
  diff: 1
};

/* 리듀서 선언 */
// 리듀서는 export default 로 내보내주세요.
export default function counter(state = initialState, action) {
  switch (action.type) {
    case SET_DIFF:
      return {
        ...state,
        diff: action.diff
      };
    case INCREASE:
      return {
        ...state,
        number: state.number + state.diff
      };
    case DECREASE:
      return {
        ...state,
        number: state.number - state.diff
      };
    default:
      return state;
  }
}

todos 모듈

modules/todos.js

/* 액션 타입 선언 */
const ADD_TODO = 'todos/ADD_TODO';
const TOGGLE_TODO = 'todos/TOGGLE_TODO';

/* 액션 생성함수 선언 */
let nextId = 1; // todo 데이터에서 사용 할 고유 id
export const addTodo = text => ({
  type: ADD_TODO,
  todo: {
    id: nextId++, // 새 항목을 추가하고 nextId 값에 1을 더해줍니다.
    text
  }
});
export const toggleTodo = id => ({
  type: TOGGLE_TODO,
  id
});

/* 초기 상태 선언 */
// 리듀서의 초기 상태는 꼭 객체타입일 필요 없습니다.
// 배열이여도 되고, 원시 타입 (숫자, 문자열, 불리언 이여도 상관 없습니다.
const initialState = [
  /* 우리는 다음과 같이 구성된 객체를 이 배열 안에 넣을 것입니다.
  {
    id: 1,
    text: '예시',
    done: false
  } 
  */
];

export default function todos(state = initialState, action) {
  switch (action.type) {
    case ADD_TODO:
      return state.concat(action.todo);
    case TOGGLE_TODO:
      return state.map(
        todo =>
          todo.id === action.id // id 가 일치하면
            ? { ...todo, done: !todo.done } // done 값을 반전시키고
            : todo // 아니라면 그대로 둠
      );
    default:
      return state;
  }
}

루트 리듀서 만들기

한 프로젝트에 여러 개의 리듀서가 있을 때는 하나의 리듀서로 합쳐서 사용 합니다. -> 이를 곧, 루트 리듀서라고 부릅니다.

리듀서를 합치는 작업은 combineReducers 라는 함수를 사용 합니다.

modules/index.js

import { combineReducers } from 'redux';
import counter from './counter';
import todos from './todos';

const rootReducer = combineReducers({
  counter,
  todos
});

export default rootReducer;

리덕스 스토어 만들기

src 디렉토리 -> index.js

src/index.js

import React from 'react';
import ReactDOM from 'react-dom/client';
import './index.css';
import App from './App';
import { createStore } from 'redux';
import rootReducer from './modules';

const store = createStore(rootReducer); // 스토어를 만듭니다.
console.log(store.getState()); // 스토어의 상태를 확인해봅시다.

const root = ReactDOM.createRoot(document.getElementById('root'));
root.render(
  <React.StrictMode>
    <App />
  </React.StrictMode>
);

리액트 프로젝트에 리덕스 적용

리액트 프로젝트에 리덕스를 적용 할 때는 react-redux 라이브러리를 사용 해야 합니다.

yarn add react-redux

사용법

index.js 에서 Provider 컴포넌트를 불러와서 App 컴포넌트를 감싸줍니다 그리고, Provider 의 props 에 store 를 넣어줍니다.

Provider 로 App 을 감싸게 되면 렌더링 하는 어떤 컴포넌트던지 리덕스 스토어에 접근 할 수 있습니다.

import React from 'react';
import ReactDOM from 'react-dom/client';
import './index.css';
import App from './App';
import { createStore } from 'redux';
import rootReducer from './modules';
import { Provider } from 'react-redux';

const store = createStore(rootReducer); // 스토어를 만듭니다.
console.log(store.getState()); // 스토어의 상태를 확인해봅시다.

const root = ReactDOM.createRoot(document.getElementById('root'));
root.render(
  <React.StrictMode>
    <Provider store={store}>
    <App />
    </Provider>
  </React.StrictMode>
);

참고

• https://react.vlpt.us/redux/04-make-modules.html

리액트 컴포넌트 없이, 리덕스에서 제공되는 기능들을 먼저 연습 해보겠습니다.

설치

yarn 사용 시

yarn add redux

폴더 구조

src 안에 -> exercise.js 생성 -> index.js 에 import 그 후, yarn start

exercise.js

import { createStore } from 'redux';

// createStore는 스토어를 만들어주는 함수입니다.
// 리액트 프로젝트에서는 단 하나의 스토어를 만듭니다.

/* 리덕스에서 관리 할 상태 정의 */
const initialState = {
  counter: 0,
  text: '',
  list: []
};

/* 액션 타입 정의 */
// 액션 타입은 주로 대문자로 작성합니다.
const INCREASE = 'INCREASE';
const DECREASE = 'DECREASE';
const CHANGE_TEXT = 'CHANGE_TEXT';
const ADD_TO_LIST = 'ADD_TO_LIST';

/* 액션 생성함수 정의 */
// 액션 생성함수는 주로 camelCase 로 작성합니다.
function increase() {
  return {
    type: INCREASE // 액션 객체에는 type 값이 필수입니다.
  };
}

// 화살표 함수로 작성하는 것이 더욱 코드가 간단하기에,
// 이렇게 쓰는 것을 추천합니다.
const decrease = () => ({
  type: DECREASE
});

const changeText = text => ({
  type: CHANGE_TEXT,
  text // 액션안에는 type 외에 추가적인 필드를 마음대로 넣을 수 있습니다.
});

const addToList = item => ({
  type: ADD_TO_LIST,
  item
});

/* 리듀서 만들기 */
// 위 액션 생성함수들을 통해 만들어진 객체들을 참조하여
// 새로운 상태를 만드는 함수를 만들어봅시다.
// 주의: 리듀서에서는 불변성을 꼭 지켜줘야 합니다!

function reducer(state = initialState, action) {
  // state 의 초깃값을 initialState 로 지정했습니다.
  switch (action.type) {
    case INCREASE:
      return {
        ...state,
        counter: state.counter + 1
      };
    case DECREASE:
      return {
        ...state,
        counter: state.counter - 1
      };
    case CHANGE_TEXT:
      return {
        ...state,
        text: action.text
      };
    case ADD_TO_LIST:
      return {
        ...state,
        list: state.list.concat(action.item)
      };
    default:
      return state;
  }
}

/* 스토어 만들기 */
const store = createStore(reducer);

console.log(store.getState()); // 현재 store 안에 들어있는 상태를 조회합니다.

// 스토어안에 들어있는 상태가 바뀔 때 마다 호출되는 listener 함수
const listener = () => {
  const state = store.getState();
  console.log(state);
};

const unsubscribe = store.subscribe(listener);
// 구독을 해제하고 싶을 때는 unsubscribe() 를 호출하면 됩니다.

// 액션들을 디스패치 해봅시다.
store.dispatch(increase());
store.dispatch(decrease());
store.dispatch(changeText('안녕하세요'));
store.dispatch(addToList({ id: 1, text: '현호' }));

참고

• https://react.vlpt.us/redux/03-prepare.html

1. 하나의 애플리케이션 안에는 하나의 스토어만 존재

하나의 애플리케이션에서는 단 한개의 스토어를 만들어서 사용 합니다.

• 여러 개의 스토어를 사용하는 것은 가능하기는 하나, 권장하지 않습니다.
• 특정 업데이트가 너무 빈번하게 일어나거나, 애플리케이션의 특정 부분을 완전히 분리 시킬 때 여러 개의 스토어를 만들 수도 있습니다.
• 하지만 그렇게 되면, 개발 도구를 활용 하지 못하게 됩니다.

2. 상태는 읽기전용 입니다.

리액트에서 state 를 업데이트 해야 할 때

• setState 를 사용하고
• 배열을 업데이트 할 때는 배열 자체에 push 를 직접 하지 않고, concat 같은 함수를 사용하여 기존의 배열은 수정하지 않고, 새로운 배열을 만들어서 교체하는 방식으로 업데이트 합니다.
• 객체의 경우 기존의 객체는 건들이지 않고 깊은 복사를 하여, spread 연산자 등을 사용하여 업데이트 합니다.

리덕스 또한 기존의 상태는 건들이지 않고, 새로운 상태를 생성하여 업데이트 해주는 방식으로 해야 나중에 개발자 도구를 사용해서 뒤로 돌릴 수도 있고, 다시 앞으로 돌릴 수도 있습니다.

즉, 기존의 상태를 수정하지 않고 새로운 상태를 생성하여 업데이트 해야 합니다. (교체의 개념)

• 이를 통해 불변성 을 유지 할 수 있습니다.

• 데이터의 변경을 감지 하기 위해서는 내부 데이터까지 전부 찾아야 하는데 시간이 너무 오래 걸립니다.

• 따라서, 기존 상태의 객체를 새로운 객체로 변경하면 객체의 주소가 다르므로 변경을 쉽게 감지하는 것이 가능 합니다.

3. 리듀서는 순수한 함수여야 합니다.

• 리듀서 함수는 이전 상태와 액션 객체를 파라미터로 받습니다.
• 이전의 상태는 절대로 건들이지 않고, 변화를 일으킨 새로운 상태 객체를 만들어서 반환 합니다.
• 똑같은 파라미터로 호출된 리듀서 함수는 언제나 똑같은 결과 값을 반환해야만 합니다.

참고

• https://react.vlpt.us/redux/02-rules.html

액션 (Action)

상태에 어떠한 변화가 필요하게 될 때, 액션이란 것을 발생 시킵니다.

• 이는, 하나의 객체로 표현이되고 type 이라는 필드는 필수로 가지고 있어야 합니다.

  {
  type : "TOGGLE_VALUE"
  }

• type 외의 값들은 개발자 마음대로 넣을 수 있습니다.

  {
  type : "TOGGLE_VALUE",
  data : {
        id : 0,
        text : '리덕스 공부'
  }
  }

액션 생성함수 (Action Creator)

액션을 만드는 함수 입니다. 단순히 파라미터를 받아와서 액션 객체 형태로 만듭니다.

export function addTodo(data){
    return{
      type : "ADD_TODO",
      data
    };
}

// 화살표 함수로 만들 수 있습니다.
export const changeInput = (text) => {
  type : "CHANGE_INPUT",
  text
};

• 액션 함수를 생성하는 이유는, 나중에 컴포넌트에서 쉽게 액션을 발생시키기 위함 입니다.
• 그래서 보통 함수 앞에 export 키워드를 붙여서 다른 파일에서 불러와서 사용 합니다.

리듀서 (Reducer)

변화를 일으키는 함수 입니다. 두 가지의 파라미터를 받아 옵니다.

function reducer(state, action){
    // 상태 업데이트 로직
      return state;
}

• 리듀서는 현재의 상태와, 전달 받은 액션을 참고하여 새로운 상태를 만들어서 반환 합니다.
• useReducer 를 사용 할 때와 똑같은 형태를 가지고 있습니다.
  

카운터를 위한 리듀서를 만든다면

function counter(state, action){
    switch (action.type){
      case 'INCREASE' :
        return state + 1;

      case 'DECREASE' :
        return state - 1;

      default :
        return state;
    }
}

• 리덕스에서는 리듀서의 기존 default 에 기존 state 를 반환하도록 작성 합니다.
• 리덕스를 사용 할 때는 여러 개의 리듀서를 만들고 이를 합쳐러 루트 리듀서 (Root Reducer) 를 만들 수 있습니다. ( 루트 리듀서 안에 리듀서들은 서브 리듀서 라고 부릅니다. )

스토어 ( Store )

리덕스는 하나의 애플리케이션에 하나의 리덕스 스토어를 만들게 됩니다.

• 스토어 안에는 현재의 앱 상태와, 리듀서가 들어있고, 몇 가지의 내장 함수들이 있습니다.

디스패치 ( dispatch )

스토어의 내장 함수 중 하나 입니다. 액션을 발생 시키는 것 이라고 이해 할 수 있습니다.

• dispatch 라는 함수에는 액션을 파라미터로 전달 합니다.
• dispatch(action)
• 위와 같이 호출을 하면, 스토어는 리듀서 함수를 실행 시켜서 해당 액션을 처리하는 로직이 있다면 참고하여 새로운 상태를 만들어 줍니다.

구독 ( subscribe )

스토어의 내장 함수 중 하나 입니다. 함수 형태의 값을 파라미터로 받아 옵니다.

• subscribe 함수에 특정 함수를 전달해주면, 액션이 디스패치 되었을 때 마다 전달해준 함수가 호출 됩니다.
• 리액트에서 리덕스를 사용하게 될 때 보통 이 함수를 직접 사용하는 일은 별로 없습니다.
• 대신, react-redux 라이브러리에서 제공하는 connect 또는 useSelector 를 사용하여 리덕스 스토어의 상태에 구독 합니다.

참고

• https://react.vlpt.us/redux/01-keywords.html

리액트 생태계에서 가장 사용률이 높은 상태관리 라이브러리 입니다.

1. 사용하는 이유

1. 컴포넌트들의 상태 관련 로직들을 다른 파일들로 분리시켜서 더욱 효율적으로 관리 가능
2. 글로벌 상태 관리도 손쉽게 할 수 있다.
3. props 드릴링을 막을 수 있다.

Context API 의 useReducer Hook 을 사용해서 개발하는 흐름은 리덕스를 사용하는 것과 매우 유사 합니다. -> 리덕스에서도 리듀서와 액션이라는 개념을 사용하기 때문!

2. 리덕스를 사용하는 것과 Context API 의 차이

2.1 미들웨어(Middleware)

리덕스에는 미들웨어라는 개념이 존재 합니다.

• 리덕스 미들웨어를 사용하면 액션 객체가 리듀서에서 처리되기 전에 원하는 작업을 수행 가능

1. 특정 조건에 따라 액션이 무시되게 만들 수 있습니다.
2. 액션을 콘솔에 출력하거나, 서버쪽에 로깅 할 수 있습니다.
3. 액션이 디스패치 됐을 때, 이를 수정해서 리듀서에게 전달되도록 할 수 있습니다.
4. 특정 액션이 발생 했을 때, 이에 기반하여 다른 액션이 발생되도록 할 수 있습니다.
5. 특정 액션이 발생 했을 때, 특정 자바스크립트 함수를 실행 시킬 수 있습니다.

미들웨어는 주로 비동기 작업을 처리 할 때 많이 사용 합니다.

2.2 유용한 함수와, Hooks

이전에 Context API 와 useReducer 를 사용 할 때는 Context 도 새로 만들고, Context 의 Provider 설정도 하고 각 Context 를 편하게 사용하기 위해 전용 커스텀 Hook 을 따로 만들어서 사용하기도 합니다. -> 하지만 리덕스에서는 이와 비슷한 작업을 편리하게 해줄 수 있는 기능이 존재 합니다.

• connect 함수를 사용하면 리덕스의 상태 또는 액션 생성 함수를 컴포넌의 props로 받을 수 있다.
• useSelector, useDispatch, useStore 등 여러가지 존재

connect 함수와 useSelector 는 내부적으로 최적화가 잘 이루어져있어서 실제 상태가 바뀔 때만 컴포넌트가 리렌더링 됩니다. 하지만 Context API 는 그러한 최적화가 자동으로 되어있지 않기 때문에 Context가 가지고 있는 상태가 바뀌면 해당 Provider 내부 컴포넌트들이 모두 리렌더링이 됩니다.

3. 하나의 커다란 상태

리덕스는 모든 글로벌 상태를 하나의 커다란 상태 객체에 넣어서 사용하는 것이 필수 입니다.

참고

• https://react.vlpt.us/redux/

Next.js 는 따로 설정을 해주지 않고도 SSR, SEO부터 TypeScript까지 생산에 필요한 많은 기능들을 제공하는 아주 강력한 React 프레임워크 입니다.

2. 어디서 만들었나

Next.js는 Vercel이라는 Frontend Team에서 만들었습니다.

3. 사용해야 하는 이유

3.1 SSR

Next.js 를 사용하는 가장 큰 이유 입니다. 이해하기 좋게 먼저 반대 개념인 SPA 와 CSR에 대해 먼저 정리 하겠습니다.

3.1.1 SPA (Single Page Application)

전통적인 웹 페이지 만드는 방식은

1. client 에서 server 로 최초의 요청을 보내고
2. server 는 요청을 받아 client 에게 응답을 보낸 후, client에서 화면이 보입니다.
3. 이후 client 에서 상호작용이 있을 때 마다, server로 요청을 보내고
4. server 는 이에 응답하며 페이지가 Reload 됩니다.

• 하지만 위와 같은 방법인 경우 사용자가 새로운 요청을 보내고 응답을 받을 때 마다, 사용자의 페이지가 Reload 되기 때문에 사용자 경험이나 서버에 부담이가 비용적인 측면에서 좋지 않습니다.

• 위와 같은 방법을 해결 할 수 있는 것이 SPA 입니다.

• SPA 는 필요한 정적 리소소를 최초에 모두 다운로드 합니다.

• 이후 변경이 있을 때마다 페이지 전체를 Reload 하지 않고 변경된 부분만 갱신 합니다.

  
  

3.1.2 CSR (Client Side Rendering)

CSR 동작 순서는

1. 서버에서 브라우저로 응답을 보냅니다.
2. 브라우저에서 JS 를 다운 받습니다.
3. 브라우저가 React 를 실행 합니다.
4. 페이지가 보이고 상호작용이 가능 합니다.

CSR 의 장점

• 컴포넌트 단위로 UI를 구성하기 때문에 재사용에 용이 합니다.
• 페이지 전환이 부드럽고 빠릅니다.
• 변경된 사항만 server로 전달하기 때문에 서버에 부담이 덜하고 비용적인 측면에서 효율적 입니다.

CSR 의 단점

• 초기 로딩 때 모든 정적 리소스들을 다운 받아서 초기 페이지 로딩이 느립니다.
• SEO가 좋지 않습니다.

3.1.3 SSR (Server Side Rendering)

SSR 의 동작 순서는

1. 서버는 렌더링할 준비가 된 HTML을 응답을 브라우저에게 보냅니다.
2. 브라우저는 페이지를 렌더링하고 이 때 페이지를 볼 수 있고 이 때, 브라우저가 JS를 다운로드 받습니다.
3. 브라우저가 React를 실행합니다.
4. 페이지를 상호작용 할 수 있습니다.

SSR 의 장점

1. CSR에 비해 초기 렌더링 속도가 빠릅니다.
2. SEO 가 좋습니다.

SSR 의 단점

1. CSR에 비해 서버와 요청하는 횟수가 많아 서버에 부담이 갈 수 있습니다.
2. 페이지 전환 시 마다 새로고침이 일어납니다.

3.1.4 CSR 과 SSR 의 차이

1. 사용자에게 더 빨리 보여지는 것 -> SSR

2. view 와 상호작용

CSR : 최종적으로 로딩이 끝난 후 가능 SSR : Page가 먼저 보여지나 JS 와 React 로딩이 끝난 후 가능

3.2 SEO (Search Engine Optimization)

검색엔진 최적화 입니다. 기존 리액트에서 사용하는 CSR 방식은 SEO가 좋지 않습니다. 따라서 검색 엔진 최적화를 위해서는 SSR이 중요한 역할을 합니다.

3.2.1 검색엔진 최적화를 하는 이유

웹 사이트를 만들고 브라우저에 검색을 했을 때, 사이트가 상단에 위치해야 유입이 많아질 것 입니다. 하지만 CSR 방식은 검색엔진에 노출이 잘 되지 않습니다. ( 노출이 안되는 것이 아닙니다!! )

• ex ) 네이버 검색엔진

검색엔진 봇들은 JavaScript를 해석하기 힘들기 때문에 HTML에서 크롤링하게 됩니다. CSR 방식은 Client 측에서 페이지를 구성하기 전에 HTML에 아무것도 없으므로 데이터를 수집하지 못해 검색엔진에 노출이 어려운 것 입니다.

3.3 마지막 Next.js 의 작동 방식

1. 사용자가 초기에 Server에 페이지 접속을 요청한 경우 SSR 방식 으로 렌더링 될 HTML을 보냅니다.
2. 브라우저는 JS를 다운받고 React 를 실행 합니다.
3. 사용자가 페이지와 상호작용을 하여 다른 페이지로 이동할 경우 CSR 방식 server 가 아닌 브라우저에서 처리 합니다.

정리

Next.js 는

Vercel 에서 만든 SSR, SEO 를 하기 위한 React 의 프레임워크

• 초기에 server 에 페이지 접속을 요청 한 경우 SSR 방식 으로 렌더링 될 HTML 을 보내줌으로써 SEO 최적화가 되어 검색 엔진에 노출이 됩니다.
• 페이지와 상호 작용을 할 때는 CSR 방식으로 처리함으로 SPA 장점을 가지고 있습니다.

CSR

CSR(Client Side Rendering)은 뼈대가 되는 빈 HTML 과 JS 파일을 전부 가져와 클라이언트(브라우저) 측에서 HTML 을 구성하는 방식이다. 초기에 빈 HTML 파일을 보여준 후 API 요청을 통해 데이터를 받아와 다시 렌더링 하기 때문에 사용자가 화면을 인식하는데 상대적으로 오래걸린다. 하지만 초기 로딩 후 버튼이나 링크를 클릭해 페이지간 전환이 일어날 때 클라이언트에서 화면을 다시 구성하므로 화면 전환 속도가 빠르다.

SSR

SSR(Server Side Rendering)은 서버에서 HTML을 구성하여 클라이언트로 보내주는 방식이다. (여기서 서버란, 프론트엔드가 발전하지 않았던 시절에는 말그대로 백엔드 서버를 의미 했으나, 프론트엔드단이 발전한 현재에는 프론트엔드 서버를 의미한다.) 서버에서 구성한 화면은 유저가 인식할 수 있으나, JS 를 다운받아 실행하기 전에는 이벤트 등이 작동하지 않는다. 따라서 유저의 interaction을 기록했다가 JS 파일을 다운 받은 후 실행시킨다.

CSR Vs SSR

CSR은 최초 화면을 유저에게 보여주기까지의 시간이 SSR 보다 오래걸린다. 또한 검색엔진이 크롤링을 했을 때 빈 HTML 만을 확인할 수 있기 때문에 SEO(검색엔진 최적화)에 불리하다.

SSR은 매번 서버에서 연산을 수행해야하기 때문에 서버에 부하가 더 크다. 또한 화면 전환시 깜빡임이 있다.

이렇게 각각 장단점이 있지만, 초기 로딩과 SEO 측면에서는 SSR의 장점이 두드러진다.

참고

• https://vercel.com/
• https://nextjs.org/
• https://medium.com/walmartglobaltech/the-benefits-of-server-side-rendering-over-client-side-rendering-5d07ff2cefe8
• https://www.excellentwebworld.com/what-is-a-single-page-application/
• SSR 개념 이해와 Next.js로 실습까지 해보는 SSR 환경 구축하기
• NextJS, 그게 뭔데?