지금까지 배운 hydrate 되는 client(= client에서 interactive하게 만들어질 components)는 코드 최상단에 “use client” 지시어를 가지고 있는 컴포넌트 뿐이다

// "use client";

import Link from "next/link";
import { usePathname } from "next/navigation";
import { useState } from "react";

export default function Navigation() {
  const path = usePathname();
  const [count, setCount] = useState(0);
  const handlePlusClick = () => {
    setCount(count + 1);
  };

  return (
    <nav>
      <ul>
        <li>
          <Link href={"/"}>Home</Link> {path === "/" ? "🔥" : ""}
        </li>
        <li>
          <Link href={"/about-us"}>About us</Link>{" "}
          {path === "/about-us" ? "🔥" : ""}
        </li>
      </ul>
      <div>
        <h3>{count}</h3>
        <button onClick={handlePlusClick}>+1</button>
      </div>
    </nav>
  );
}

• 이렇게 “use client”를 지우면

  

이런식으로 client component에서만 사용할 수 있는 동작을 server component에서 사용했으니 `“use client”`를 마크하라는 에러가 표기된다

Server component

“use client” 를 사용하지 않는 모든 컴포넌트는 서버 컴포넌트이다

Server component와 Client component를 분리해서 뭐가 좋아지지?

프레임워크에게 어떤 컴포넌트가 인터렉티브하고 어떤 컴포넌트가 그렇지 않은지 알려준다면 인터렉티브 하지 않은 컴포넌트는 한번만 렌더하고 이후로 렌더하지 않아도 된다

따라서 사용자가 서버 컴포넌트는 Javascript 코드가 필요하지 않아서 Javascript 코드를 다운받지 않아도 되는데 이 말은 즉 사용자가 받아야 할 Javascript 코드의 양이 줄어드는 것이므로 페이지 로딩 속도가 빨라진다

정리

사용자는 "use client" 를 가진 컴포넌트의 Javascript 코드만 다운받게 된다

client component도 서버에서 먼저 render되고 hydrate 되는 것이다. 서버에서 render를 안하는 게 아니라는 점을 헷갈리지 말자

브라우저의 Sources에서 disable Javascript 실행 후 anchor를 클릭하여 페이지를 이동해보자

• 링크 클릭에 따라 화면이 새로고침된다
• 자바스크립트를 사용한 건 아니고 그저 a 태그의 link를 따라가는 것이다

그럼 다시 enable Javascript 후 이동해보자

• 새로고침 되지 않고 좀 더 빠르다

→ 이것이 React Hydrated 된 것이다 (오 모르겠는데)
처음에는 단순히 a태그였다가 React component로 변환된것이다

그래서 클릭이 발생되면 React가 끼어들어 페이지 전체를 로드하지 않고 빠르게 navigate 할 수 있게 된다. 이는 더 이상 평범한 a 태그가 아니라 Link component로 새로 태어난 것이라고 생각하면 된다

흐름을 이해해보자

어떤 페이지에 도달하면 UI를 가지고 있는 dummy HTML을 받고 → 프레임워크는 바로 load를 시작한다 → React load, components load.. 그리고 모든것이 initialize 됨 → 이러고나면 내 앱은 React App이 됨 → 이러고 나서야 비로소 interactive 해지고 navigation이 빨라지고… 그렇게 되는 것이다

물론 소스코드에 a 태그가 남아있기는 하지만 이 태그는 단순한 a 태그가 아니라 javascript에 의해 제어되는 a 태그인 것이다

만약에 어떤 이유로 javascript 로드하는데 아아아주 오랜 시간이 걸려서 react component가 아직 로드되지 않았다면 hard navigation(지금의 경우는 페이지를 새로고침하면서 이동하는 것)하게 된다

실험해보자

useState를 사용하는 코드를 추가하고 브라우저에서 disable Javascript를 실행했다

"use client";

import Link from "next/link";
import { usePathname } from "next/navigation";
import { useState } from "react";

export default function Navigation() {
  const path = usePathname();
  const [count, setCount] = useState(0); // 여기 
  const handlePlusClick = () => {
    setCount(count + 1);
  };

  return (
    <nav>
      <ul>
        <li>
          <Link href={"/"}>Home</Link> {path === "/" ? "🔥" : ""}
        </li>
        <li>
          <Link href={"/about-us"}>About us</Link>{" "}
          {path === "/about-us" ? "🔥" : ""}
        </li>
      </ul>
      <div>
        <h3>{count}</h3>
        <button onClick={handlePlusClick}>+1</button>
      </div>
    </nav>
  );
}

아무리 버튼을 눌러도 count에 변화가 없다(방황하는 마우스)

• 버튼의 eventlistener가 연결되지 않았기 때문이다
• initial state는 불러와진걸 볼 수 있는데(0), 이는 최초의 렌더 이후 인터렉션이 안되는 것이기 때문에 초깃값은 적용된것이다
  

다시 enable Javscript를 실행하면 setState가 동작해서 값이 변화되는 걸 볼 수 있다(편안한 마우스)

그래서 Hydration이란?

HTML을 React application으로 초기화하는 작업이다 ⇒ 예제를 사용하자면, 0이 쓰인것 외에 아무것도 없는 버튼을 받고, React를 initialize하여 onClick을 부착하여 기능을 수행하게 하는 것이다

React가 application을 렌더하는 방법(CSR)

CRA로 React만을 이용해서 application을 생성하면 client side apllication이 된다 → client가 사용자 브라우저에서 모든 UI를 구축함한다

• 단점
  • 소스코드를 보면 실제 소스코드는 비어있다(UI가 없음)

    - 인스펙트에서는 볼 수 있다
        이는 Javascript에 의해서 UI가 추가되었기 때문이다
    - 화면을 새로고침 하다보면 화면에 아무것도 안그려져있는 때가 있는데 이 때가 Javascript가 UI를 그리고 있는 시점이다
    - Javascript가 disabled 되어 있는 상황이거나, 엘베에서 데이터가 안터지는 상황등이라면 내가 생각한것보다 더 오랫동안 빈 화면을 유저가 봐야한다
- SEO 검색 엔진 최적화 문제
    - google등에서 내 페이지가 검색되길 바란다면 google에서 빈 페이지를 보여주지 않는 것이 좋다
        → google은 페이지의 HTML을 보고 검색해주기 때문(가끔 Javascript를 실행하기도 하지만.. 안전하게 HTML을 그려주는게 좋음)

*👉🏻 client는 Javascript를 로드하고 → 그 후에 Javascript가 UI를 빌드한다 *

Next.js가 application을 렌더하는 방법(SSR)

자동적으로 server side render를 한다

• server, 즉 BE에서 application을 render
• Next.js는 서버에서 나의 모든 컴포넌트(server component건 client component(”use client”)건 상관 없음) 를 렌더 후 그 HTML을 가지고 브라우저의 request에 대한 response로 준다 → 그래서 소스코드가 안비어 있음
• use client를 선언한 client component에서 console.log(path)를 실행시키면

        ![](https://velog.velcdn.com/images/e-sum-e/post/17a659d0-7042-4f14-a909-949211bee86e/image.png)

  이렇게 브라우저에도 찍히고 이렇게 backend server쪽 콘솔에도 찍힌다..!
• 그리고 소스코드에서도 페이지의 내용들이 들어있음을 확인할 수 있다 → 화면에 그려질 HTML을 가지고 있기 때문

결론

모든 컴포넌트와 페이지들은 백엔드에서 먼저 렌더된다

그리고 이것들이 HTML로 변환하고

이 HTML을 브라우저로 보내준다

라이브러리 사용 중에 우선 구현을 먼저 해보려고 타입을 any로 지정했더니 eslint 에러가 발생했다. Unexpected any. Specify a different type

해결 방법

eslint 설정 파일에서 규칙을 수정해주면 된다. 나는 .eslintrc.cjs 를 수정해줬다.

module.exports = {
    // other configs..
  rules: {
    // other rules..
    "@typescript-eslint/no-explicit-any": "off",
  },
}

이제 any 타입에 대한 에러가 발생하지 않는다!

| MDN

Javascript에서 값을 비교하는 방법은 크게 세가지가 있다.

• ==
• ===
• Object.is(value1, value2)

각각의 차이점은,

==

느슨한 동등 비교 대상의 타입이 다르다면 같은 타입으로 변환하여 비교한다 NaN, -0/+0에 대한 특수 처리를 한다

1 == '1'; // true

const obj1 = { a: 1 };
const obj2 = { a: 1 };
obj1 == obj2 // false

NaN == NaN // false

-0 == +0 // true

===

엄격한 동등 비교 대상의 타입이 다르다면 다른 값으로 인식한다 ==와 마찬가지로 NaN, -0/+0에 대한 특수 처리를 한다

1 == '1'; // false

const obj1 = { a: 1 };
const obj2 = { a: 1 };
obj1 == obj2 // false

NaN == NaN // false

-0 == +0 // true

사실 위 두가지는 알고 있던 것이고.. Object.is는 뭐가 다른걸까?

Object.is

==, === 둘 중 무엇과도 같지 않은 동작을 한다 비교 대상의 타입이 다르다면 다른 값으로 인식한다(===과 동일) 하지만 NaN, -0/+0에 대한 처리가 다르다

Object.is(1, '1'); // false

const obj1 = { a: 1 };
const obj2 = { a: 1 };
Object.is(obj1, obj2); // false

Object.is(NaN, NaN) // ⭐️ true

Object.is(-0, +0) // ⭐️ false

결론

Object.is가 동등 등호를 대체하여 사용할 수는 없다

코테에서 주어진 조건의 예외 처리를 위해 Jest로 테스트코드 작성중인데, 기대 결과를 toBe() 로 넣고 테스트를 실행하고 있다.

문제 상황

| 프로그래머스 - 마지막 두 원소

풀이

function solution(num_list) {
  /**
   * 2 ≤ num_list의 길이 ≤ 10
   * 1 ≤ num_list의 원소 ≤ 9
   */

  assert(2 <= num_list.length && num_list.length <= 10, "Invaild array size");
  for (let i = 0; i < num_list.length; i++) {
    assert(1 <= num_list[i] && num_list[i] <= 9);
  }

  // length -1 > length-2 이면
  // (length -1) - (length-2) 추가
  const lastIndex = num_list.length - 1;
  if (num_list[lastIndex] > num_list[lastIndex - 1]) {
    num_list.push(num_list[lastIndex] - num_list[lastIndex - 1]);
  } else {
    // 아니면 (length -1)*2 추가
    num_list.push(num_list[lastIndex] * 2);
  }

  return num_list;
}

테스트 코드

test("[5, 2, 1, 7, 5]", () => {
  const num_list = [5, 2, 1, 7, 5];

  expect(solution(num_list)).toBe([5, 2, 1, 7, 5, 10]);
});

테스트 결과

테스트를 실행해보니 아래와 같이 테스트가 제대로 돌지 않았다.

문제를 잘못 풀었나 싶어서 console에 num_list를 찍어보기도 했다.

function solution(num_list) {
  /**
   * 2 ≤ num_list의 길이 ≤ 10
   * 1 ≤ num_list의 원소 ≤ 9
   */

  assert(2 <= num_list.length && num_list.length <= 10, "Invaild array size");
  for (let i = 0; i < num_list.length; i++) {
    assert(1 <= num_list[i] && num_list[i] <= 9);
  }

  // length -1 > length-2 이면
  // (length -1) - (length-2) 추가
  const lastIndex = num_list.length - 1;
  if (num_list[lastIndex] > num_list[lastIndex - 1]) {
    num_list.push(num_list[lastIndex] - num_list[lastIndex - 1]);
  } else {
    // 아니면 (length -1)*2 추가
    num_list.push(num_list[lastIndex] * 2);
  }

  console.log(num_list); // <- 여기 추가
  return num_list;
}

console에 찍어봤을 땐 값이 제대로 들어간 거 같은데 뭐가 문제일까 싶어 toBe의 주석과 Received된 결과를 살펴보았다. → serializes to the same string

해결 방법

우선 받은 결과에 찍힌 문구가 무슨 의미인지 구글링해보았다. | 참고 블로그 | Stack overflow

• 참고한 블로그에 작성을 잘 해주셔서 하나씩 살펴보니 이해가 됐다.

toEqual의 존재를 깨달음

지금까지 사용한 toBe() 는 객체가 아닌 그 객체의 참조값(메모리 주소)을 비교하지만, toEqual() 은 객체 내부의 값을 비교한다. 그래서 테스트 코드를 수정하고 다시 테스트를 돌려봤다.

test("[5, 2, 1, 7, 5]", () => {
  const num_list = [5, 2, 1, 7, 5];

  expect(solution(num_list)).toEqual([5, 2, 1, 7, 5, 10]); // <- toBe -> toEqual
});

야호 성공이다!

그런데 더 쉬운 방법이 있었다

포스트를 작성하다 보니 친절하게 안내되어 있었다.

• toStrictEqual 로 바꿔보세요.

네.

test("[5, 2, 1, 7, 5]", () => {
  const num_list = [5, 2, 1, 7, 5];

  expect(solution(num_list)).toStrictEqual([5, 2, 1, 7, 5, 10]); // toEqual -> toStrictEqual
});

야호!

그런데 이러면 toEqual과 toStrictEqual은 무슨 차이가 있는 거지?

toStrictEqual

| 공식 문서 toEqual보다 엄격한 equal undefined를 고려한다.

먼저 toEqual을 테스트 해보자

// toEqual
test("toEqual의 undefined 구분 여부", () => {
  const obj = { a: undefined, b: 1 };

  function test(testObj) {
    return testObj;
  }

  expect(test(obj)).toEqual({ b: 1 });
});

// toStrictEqual
test("toStrictEqual의 undefined 구분 여부", () => {
  const obj = { a: undefined, b: 1 };

  function test(testObj) {
    return testObj;
  }

  expect(test(obj)).toStrictEqual({ b: 1 });
});

toEqual은 테스트가 통과됐지만(undefined가 할당된 a는 없는 값으로 친다), toStrictEqual은 undefined라는 값으로 할당된 값이 있는지를 확인하기 때문에 테스트에 걸렸다.

결론

객체 타입의 값을 비교할 때에는 toStrictEqual 을 사용하는 게 내가 의도한 값으로 정확히 비교된다.

조금의 생각

• 정확히 내부가 어떻게 도는지는 모르겠지만.. const로 변수 선언 시 원시 타입은 수정할 수 없지만 객체 타입은 메모리 주소가 할당되기 때문에 이후 수정할 수 있는 메커니즘과 관련있을 거 같다는 생각이 든다.

// index.html

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>HTML 예제 연습장</title>
  </head>
  <body>
    <div id="root">
      <div class="innerHTML">innerHTML</div>
      <div class="innerText" style="display: none">innerText</div>
      <div class="textContent" style="display: none">textContent</div>
      </div>
      </body>
  <script script src="./app.js" ></script>
</html>

각각 사용해보기

innerHTML

| MDN

요소(element) 내에 포함 된 HTML 또는 XML 마크업을 가져오거나 설정한다. 값으로 DOMString을 넣어준다

const innerHTMLDiv = document.querySelector(".innerHTML");
console.log(innerHTMLDiv.innerHTML);
innerHTMLDiv.innerHTML = "바꿈";
console.log(innerHTMLDiv.innerHTML);

innerText

| MDN

요소와 그 자손의 렌더링된 텍스트 콘텐츠를 나타낸다. 사용자가 드래그로 긁어서 복붙할 수 있는 텍스트의 근삿값을 제공한다.

const innerTextDiv = document.querySelector(".innerText");
console.log(innerTextDiv.innerText);
innerTextDiv.innerText = "바꿨지롱";
console.log(innerTextDiv.innerText);

textContent

| MDN

Node와 그 자손의 텍스트 콘텐츠를 표현한다.

• 위의 innerHTML, innerText는 HTMLElement의 메서드이고 textContent는 Node의 메서드이다.

const textContentDiv = document.querySelector(".textContent");
console.log(textContentDiv.textContent);
textContentDiv.textContent = "바꿨어용";
console.log(textContentDiv.textContent);

이렇게 사용해서는 뭐가 다르다는 건지 알기 어렵다. 그래서 HTML 태그를 넣어주기로 했다.

본격적으로 비교해보기

innerHTML

innerHTMLDiv.innerHTML = `<ul><li>하나</li><li>둘</li></ul>`;
console.log(innerHTMLDiv.innerHTML);

console에는 넣어준 텍스트가 찍히지만 브라우저에는 HTML 문법으로 적용된 모습이다.

innerText

innerTextDiv.innerText = `<ul><li>하나</li><li>둘</li></ul>`;
console.log(innerTextDiv.innerText);

console에 찍힌 문자 그대로 브라우저에도 찍힌 모습이다. 인스펙터로 확인해봐도 실제로 태그가 생성되지 않았다.

textContent

textContentDiv.textContent = `<ul><li>하나</li><li>둘</li></ul>`;
console.log(textContentDiv.textContent);

innerText와 마찬가지로 console에 찍힌 문자 그대로 브라우저에 찍혔다 인스펙터로 확인해도 같은 모습이다.

그럼 이제 innerHTML은 알겠는데 innerText와 textContent의 차이는 뭘까?

차이를 확인해보기 위해 HTML 구조를 약간 바꿔줬다.

// index.html

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <title>HTML 예제 연습장</title>
  </head>

  <body>
    <div id="root">
      <div class="innerHTML">innerHTML</div>
      <div class="innerText" id="blue">
        <style>
          #blue {
            color: blue
          }
        </style>
        innerText
        <span style="display: none;" id="blue">hide span</span>
      </div>
      <div class="textContent" id="red">
        <style>
          #red {
            color: red
          }
        </style>
        textContent
        <span style="display: none">hide span</span>
      </div>
      </div>
      </body>
  <script src="app.js"></script>
</html>

// app. js

const innerTextDiv = document.querySelector(".innerText");
console.log(innerTextDiv.innerText);

const textContentDiv = document.querySelector(".textContent");
console.log(textContentDiv.textContent);

결론

innerText

• 브라우저에 실제로 그려진 내용만(사용자가 드래그해서 복붙할 수 있는 내용만) 표기된다.
• style 태그로 작성된 내용, display:none으로 된 자식 등은 표기되지 않는다. (display: block 등 보이는 속성이라면 표기된다.)

textContent

• style 태그로 작성된 내용, display:none으로 된 보이지 않는 자식등 자신의 자식 요소도 표기된다.

프로그래머스 문제를 풀던 중 숫자를 나눈 몫을 구해야 하는 문제가 있었는데, 정수형태여야했다. 평소 이런 문제에서는 크게 Math.round, Math.ceil, Math.floor를 사용했는데 스터디원분이 Math.trunc 라는 메서드를 소개해주셨다.

| 해당 프로그래머스 문제

Math.trunc

| MDN 주어진 값의 소수 부분을 제거하고 숫자의 정수 부분만 반환한다

그럼 Math.floor와의 차이는 뭘까?

지금까지 나는 floor가 내가 지정한 자릿수외의 소수는 버리는 메서드라고 생각하고 있었는데, 그럼 trunc와 floor의 차이가 뭔지 혼란스러워졌다.

Math.floor

| MDN 주어진 숫자와 같거나 작은 정수 중에서 가장 큰 수를 반환한다

예를 들어

console.log(Math.floor(3.14)) // 3
console.log(Math.floor(5.9)) // 5

여기까지는 내가 이해해온것과 크게 다르지 않다. 결국 작은 정수를 반환하기 때문에 소수를 버리는 것과 같은 결과가 나오기 때문이다. 그럼 음수라면 어떨까?

console.log(Math.floor(-3.14)) // -4
console.log(Math.floor(-5.9)) // -6

놀랍게도 각각 -3, -5가 아닌 더 작아질 수 있는 정수인 -4, -6이 반환된다. 그럼 같은 숫자를 trunc를 사용했을 땐 어떻게 될까?

console.log(Math.trunc(-3.14)) // -3
console.log(Math.trunc(-5.9)) // -5

위 코드를 실행한 결과와 같이 trunc로 했을땐 소수는 버리고 정수 부분만 출력되는 것을 알 수 있었다.

그림으로 표현

-1.9에서 더 작게 표현할 수 있는 정수는 내림을 한 -2이다 -1.9의 절대값은 1이고 음수를 적용해주면 -1이다

console.log(Math.floor(-1.9)) // -2
console.log(Math.trunc(-1.9)) // -1

2.3에서 더 작게 표현할 수 있는 정수는 내림을 한 2이다 2.9의 절대값은 2이고 양수를 적용해주면 2이다

console.log(Math.floor(2.3)) // 2
console.log(Math.trunc(2.3)) // 2

Javascript 호이스팅에 대한 설명을 듣던 중 var, const, let으로 선언한 변수에 대한 차이를 배웠다. const, let은 선언전에 사용하면 ReferenceError가 발생하는데 그럼 호이스팅이 되지 않는걸까?

Hoisting | 호이스팅

스코프 내부 어디서든 변수 선언은 최상위에 선언된것처럼 동작한다

TDZ?

Temporal Dead Zone(= 일시적 사각지대)

let age = 20;

function showAge() {
  console.log(age);

  let age = 30;
}

showAge();

호이스팅은 스코프 단위로 일어나며, showAge 함수에서도 호이스팅이 일어났기 때문에 밖에서 선언한 age=20을 읽지 못한 것이다

변수의 생성과정

var

1. 선언 및 초기화

• 초기화 : undefined를 할당해주는 단계

2. 할당

let

1. 선언 단계
2. 초기화 단계
3. 할당 단계

const

1. 선언 + 초기화 + 할당

• 그래서 선언할때 값을 넣어줘야 하고 이후에는 수정이 불가한 것이다.

변수의 스코프

스코프

변수가 정의된 영역

var

함수 스코프

• 함수 내부에서 선언된 변수는 var로 선언되었다 할지라도 다른 스코프에서 접근할 수 없음
• 함수 외부에서 var를 사용하면 전역 변수로 선언됨

  const age = 20;
  

if (age > 19) { var type = "성인"; }

console.log(type); // 성인

```javascript
function add(num1, num2) {
  var result = num1 + num2;
}

add(2, 3);
console.log(result); // ReferenceError

let, const

블록 스코프

var로 선언된 전역 변수와 let으로 선언된 전역변수의 차이

var로 선언된 전역 변수는 전역 객체의 프로퍼티로 존재함

• globalThis로 참조 가능
• var x = 2 === globalThis.x = 2

무엇으로 선언했건 간에 유일하게 벗어날 수 없는 스코프는 함수 스코프이다.

let, const는 호이스팅이 된다. 다만, TDZ에 만들어지고 이는 초기화전에는 사용이 금지되어 있다는 규칙에 의해서 사용할 수 없는 것이다.(ReferenceError)

| 참고 영상

grid

먼저 행(row), 열(column) 알아보기

사실 나는 이게 몇년째 헷갈려서 할 때마다 찾아보고 있다.

우선 사용할 기본 문서를 만들어줬다.

container에 적용하는 속성

우선 container에 display: grid 를 적용하면 달라지는 건 없다

grid-template-columns

columns로 정렬했을 때 템플릿의 비율

.container {
  display: grid;
  grid-template-columns: 40% 60%;
  background-color:whitesmoke
}

// 위 코드와 비슷하지만 더 많이 쓰이는 문법
.container {
  display: grid;
  grid-template-columns: 4fr 6fr;
  background-color: whitesmoke;
}

왜 fr 단위를 많이 사용할까? → gap을 넣어보면 알 수 있다.

• fr : fractional unit의 준말. 사용 가능한 공간에 대한 비율을 뜻한다.

fr일 때

  .container {
    display: grid;
    grid-template-columns: 4fr 6fr;
    grid-gap: 1rem; // <- 요거 추가
    background-color: whitesmoke;
  }

%일 때

  .container {
    display: grid;
    grid-template-columns: 40% 60%; // <- %로 수정
    grid-gap: 1rem; // <- 요거는 동일
    background-color: whitesmoke;
  }

똑같아 보일 수 있으나 가로 스크롤이 생긴것을 알 수 있다 → gap이 width에 추가적으로 들어가서 그렇다. ⇒ 너비 제어가 어려워진다

repeat()

반복할 횟수와 사이즈를 지정할 수 있다.

.container {
  display: grid;
  grid-template-columns: repeat(3, 1fr); // (반복할 횟수, 사이즈)
  // 위 코드와 같은 표현
  // grid-template-columns: 1fr 1fr 1fr;
  grid-gap: 1rem;
  background-color:whitesmoke
}

만약에 어떤 부분은 특정 사이즈로 고정하고 나머지의 크기는 유동적이게 하고 싶다면,

.container {
  display: grid;
  grid-template-columns: 200px 1fr; // 고정하고 싶은 사이즈를 직접 넣으면 된다
  grid-gap: 1rem;
  background-color:whitesmoke
}

• display: grid 가 적용되어 있기 때문에 같은 행에 있는 요소끼리는 높이가 자동으로 맞춰진 모습이다.

하지만! 컨텐츠 내용에 상관없이 높이를 지정해주고 싶어!

grid-auto-rows

.container {
  display: grid;
  grid-template-columns: repeat(3, 1fr);
  grid-gap: 1rem;
  grid-auto-rows: 300px; // <- 이렇게 추가
  background-color:whitesmoke
}

그런데 지정한 높이가 컨텐츠 내용보다 많아서 넘치게 된다면?

.container {
  display: grid;
  grid-template-columns: repeat(3, 1fr);
  grid-gap: 1rem;
  grid-auto-rows: 250px;
  background-color:whitesmoke
}

** grid-auto-rows: minmax() **

.container {
  display: grid;
  grid-template-columns: repeat(3, 1fr);
  grid-gap: 1rem;
  grid-auto-rows: minmax(250px, auto); // minmax 추가
  background-color:whitesmoke
}

(확연한 차이를 알아보기 위해 컨텐츠 내용을 늘렸다)

• minimum으로 250px이 적용되지만 그보다 높이가 높은 요소가 있다면 해당 요소에 맞추어 높이가 auto로 적용됨

justify-items

정렬하기(flex에서의 justify와 동일하다)

justify-items: start

.container {
  display: grid;
  grid-template-columns: repeat(3, 1fr);
  grid-gap: 1rem;
  grid-auto-rows: minmax(250px, auto);
  justify-items: start; // <- 요기 추가
  background-color:whitesmoke
}

justify-items: center

justify-items: end

align-items

flex의 align-items와 동일하게 justify축의 수직축을 기준으로 정렬된다

align-items: start

.container {
  display: grid;
  grid-template-columns: repeat(3, 1fr);
  grid-gap: 1rem;
  grid-auto-rows: minmax(250px, auto);
  align-items: start; // <- 요기 추가
  background-color:whitesmoke
}

align-items: center

align-items: end

justify-self

요소 각각의 정렬을 적용할 수 있다.(flex의 align-self처럼)

.item:nth-child(5) {
  justify-self: start;
}

// container에 적용한 align-items는 지우고 조정하고 싶은 요소에만 값을 지정해주었다

align-self

justify-self처럼 물론 align-self도 가능하다.

.item:nth-child(4) {
  justify-self: start;
  align-self: end;
}

// 5번 높이때문에 애매하게 보여서 확연한 차이를 위해 4번으로 적용해줬다

응용해보기

각 요소들을 내가 원하는 사이즈대로 배치시켜보자. 예를 들어 1번은 가로로 한 행을 꽉 채우고 싶다, 2번은 그 남은 영역의 세로로 꽉 채우고 싶다, 3번은 가로 2개 사이즈 만큼을 가지고 싶다.. 등등

이를 위해서는 우선 grid의 column, row가 어떻게 적용되고 있는지를 알아야 한다.

우선 1번이 column으로 꽉 차게 해보겠다

.item:first-child {
  grid-column: 1/4; // 분수가 아니라 1부터 4까지라는 의미
}

그럼 이번엔 4번이 row로 꽉 차게 해보자 위에 만든 기준 그림을 참고하면 2~4가 된다

.item:nth-child(4) {
  grid-row: 2/4;
}

• 오잉? row가 2부터 4까지는 잘 적용이 됐는데.. 순서가 멋대로 바뀌었다 → column을 설정해주면 된다

.item:nth-child(4) {
  grid-column: 3; // <- 요기 추가
  grid-row: 2/4;
}

이번에는 9번이 4번을 쪼그라트리지 않으면서 침범하게 해보겠다

.item:nth-child(9) {
  grid-column: 3;
  grid-row: 3/5;
}

flex

먼저 행(row), 열(column) 알아보기

사실 나는 이게 몇년째 헷갈려서 할 때마다 찾아보고 있다.

우선 사용할 기본 문서를 만들어줬다.

flex container에 주는 속성

display: flex

.container {
  display: flex;
  height: 100vh;
  background-color: lightcyan;
}

flex-direction의 default값이 row이기 때문에 자동으로 행 기준으로 정렬된다.

flex-direction

flex-direction: column

.container {
  display: flex;
  flex-direction: column; // <- 요기 추가
  height: 100vh;
  background-color: lightcyan;
}

• 열 기준으로 정렬이 된 모양이 된다

flex-direction: row-reverse

• row 기준으로 정렬되되 역순으로 정렬된다

flex-wrap

화면을 줄였을 때 넘치는 요소를 끊어서(나눠서) 보여줄 것인지 여부를 설정할 수 있다

flex-wrap: no-wrap(default. 안끊음)

.container {
  display: flex;
  flex-wrap: no-wrap
  height: 100vh;
  background-color: lightcyan;
}

flex-wrap: wrap 화면 너비가 마지막 요소보다 작아지가 끊어서 아래로 내려간 모습이다

justify-content

요소의 정렬을 설정해줄 수 있는데 요소를 오뎅꼬치를 꽂는다고 생각했을 때 꼬치가 축이되는 정렬이다

.container {
  display: flex;
  justify-content: flex-start; // <- 요기 추가
  height: 100vh;
  background-color: lightcyan;
}

justify-content: flex-start(default)

justify-content: center

justify-content: space-between 각 요소별로 전체 여백을 동일하게 나눠 가진다

justify-content: space-around space-between과 비슷하지만 전체 여백을 나눠 가질때 요소의 좌,우로 같이 가지게 된다

align-items

위의 justify-content가 오뎅꼬치를 축으로 삼는다면 align-items는 그 오뎅꼬치의 수직이 되는 축을 축으로 정렬한다.

.container {
  display: flex;
  align-items: stretch; // <- 요기 추가
  height: 100vh;
  background-color: lightcyan;
}

align-items: stretch(default)

align-itmes: flex-start

align-items: flex-end

align-items: center

응용해보자!

요소가 행열의 정 중앙으로 오게 하려면?

.container {
  display: flex;
  justify-content: center;
  align-items: center;
  height: 100vh;
  background-color: lightcyan;
}

align-content

flex-wrap: wrap 스타일과 함꼐 사용되며, 화면이 좁아져서 요소가 끊어졌을 때 어떻게 보여줄지를 설정할 수 있다.

.container {
  display: flex;
  flex-wrap: wrap; // 필요한 스타일
  align-content: flex-start; // <- 요기 추가
  height: 100vh;
  background-color: lightcyan;
}

align-content: flex-start 위에서 flex-wrap: wrap 만 적용했을떄와 비교해보면 위로 챡 붙어있을을 알 수 있다.

align-content: center

align-content: space-between justify-content와 마찬가지로 남은 여백을 요소별로 나눠 가진 형태이다

align-content: space-around justify-content와 마찬가지로 남은 여백을 요소별로 상,하로 나눠 가진 형태이다(축이 바뀌었기 때문에 반대로 나눠 가진다)

flex item에 주는 속성

flex-grow

요소가 원래보다 넓어졌을 때 요소 각각을 어떤 비율로 늘어나게 할 지 설정할 수 있다 ⚠️ 단, 여백 기준으로 늘리는 것이지 width 기준으로 늘리는 게 아니다

.item:nth-child(1){
  flex-grow: 1;
}

.item:nth-child(2){
  flex-grow: 2;
}

.item:nth-child(3){
  flex-grow: 1;
}

flex-basis

원래 요소가 점유해야 할 공간을 설정할 수 있다. 설정하게 되면 요소의 너비가 여백이 아닌 내가 지정한 비율대로 너비를 가지게 된다.

.item {
  flex-basis: 0;
  background-color:rgba(255, 192, 203, 0.5)
}

.item:nth-child(1){
  flex-grow: 1;
}

.item:nth-child(2){
  flex-grow: 2;
}

.item:nth-child(3){
  flex-grow: 1;
}

• 아까랑 무슨 차이인가 싶을 수 있는데 flex-basis가 없을 때에는 남은 여백을 기준으로 설정한 비율을 나누기 때문에 B가 A, C의 2배가 아니었다

flex-shrink

| 참고 영상 지금까지 보던 영상만으로는 shrink 이해가 잘 되지 않아서 추가적으로 찾아봤다. 근데 기본값을 0라고 알려주시는데 사실은 1이다.

아무튼 flex-shrink는 컨테이너가 작아졌을 때 요소를 어떤 비율로 줄일 것인가를 설정하는 것이다. 확인해보기 위해 스타일을 약간 수정했다.

그리고 각각의 요소에 flex-shrink를 다르게 적용해보겠다

.item:nth-child(1){
  flex-shrink: 3;
}

.item:nth-child(2){
  flex-shrink: 2;
}

.item:nth-child(3){
  flex-shrink: 1;
}

영상으로 보는게 이해가 더 빨라서 찍어봤다. 컨테이너가 줄어들때 flex-shrink가 3 > 2 > 1인 순으로 줄어드는게 보인다. 줄어드는 비율이기 때문에 숫자가 클수록 빠르게(많이) 줄어든다.

flex-grow, flex-shrink 축약형

{ 
    flex-grow: 1
    flex-shrink: 1
}

위 코드는 아래와 같이 축약형으로 쓸 수 있다.

{
    flex: 1
}

축약형으로 사용했을 때 달라지는 점 flex-basis: 0을 적용하지 않아도 요소들이 자동으로 여백이 아닌 너비를 기준으로 나눠 가지게 된다

활용해보기

하나의 요소에만 flex를 지정했을 때

.item:nth-child(2){
  flex: 1;
}

// 나머지 nth-child에는 안넣어줌

이를 응용해서 한가지 요소는 너비를 가지고 그 외의 부분을 전체 너비로 가지는 요소를 가지고 싶을 때

.item:nth-child(1){
  width: 200px; // 첫번째 요소에만 고정 너비를 주었다
}

.item:nth-child(2){
  flex: 1;
}

align-self

요소가 자신의 정렬을 스스로 지정할 수 있다 align-items 는 container가 하위 요소들의 정렬을 지정하는 것이기 때문에 다른 것이다

.item:nth-child(1){
  flex: 1;
  align-self: flex-start;
}

.item:nth-child(2){
  flex: 2;
  align-self: center;
}

.item:nth-child(3){
  flex: 1;
  align-self: flex-end;
}

order

요소가 정렬될 순서를 지정할 수 있다

.item:nth-child(1){
  flex: 1;
  order: 2;
}

.item:nth-child(2){
  flex: 2;
  order: 1;
}

.item:nth-child(3){
  flex: 1;
  order: 3;
}

마법같이 flex 사용해보기

사실 이런 설명 아니었는데 position등 다른 속성으로 하려면 어려운 작업인데 손쉽게 할 수 있어서 이렇게 제목을 붙여봤다 위에서 만든 예제의 방향을 열 기준으로 바꾸고 싶다면 어째야 할까 정말 막막하다. 그렇게 flex를 사용하면 direction만 수정해주면 아주 쉽게 바꿀 수 있다.

.container {
  //...else
  flex-direction: column;
 }

파일 시스템과 상호작용 할 수 있게 도와주는 모듈 node와 함께 번들링되어 있기 때문에 별도 설치 없이 사용 가능

const fs = require("fs")

• 비슷한 예로 http, url, path 등이 있음

알고리즘에서 어떻게 사용할것인가? 파일의 내용을 읽을 수 있다

// 비동기적
fs.readFile(filename, [options], callback)

• filename에 해당하는 파일을 [option]의 방식으로 읽은 후 callback으로 받은 함수를 호출한다

// 동기적
fs.readFileSync(filename, [options])

• filename에 해당하는 파일을 [option]의 방식으로 읽은 후 문자열을 반환한다

이 외에도 알고리즘에서 활용할 수 있을 진 모르겠으나.. 파일을 쓸 수 있는 기능도 있다

// 비동기적
fs.writeFile(filenmae, data, [options], callback)

• filename에 해당하는 파일에 [option]의 방식으로 data 내용을 쓴 후 callback함수를 호출한다

// 동기적
fs.writeFileSync(filename, data, [options])

• filename에 해당하는 파일에 [option]의 방식으로 data 내용을 쓴다

사용 방법

| 백준 - 1000번문제

const fs = require("fs");
const readedData = fs.readFileSync(0, "utf-8");
const splitedData = readedData.split(" ");
const a = splitedData[0];
const b = splitedData[1];

console.log(a / 1 + b / 1);

readline하고는 뭐가 다르지?

프로그래머스에서는 데이터를 한 줄씩 입력받아서 처리하는 문제가 몇가지 있었는데 그 땐 readline을 사용했었다

| 해당 내용 포스팅

그럼 fs 모듈도 뭔가 데이터를 입력 받는 거고 readline도 데이터를 입력 받는 건데 뭐가 다른걸까?

위에서 기술한 것처럼 readline 모듈은 한 번에 한 줄씩 데이터를 읽기 위한 인터페이스를 제공해주는 모듈이고, fs는 파일에 접근해서 데이터를 읽어오는 모듈이라는 점이 다른 거 같다. 코테에서 각각 어떻게 활용할 지는 문제 조건에 따라 다를 듯 하다.

| 참고 블로그

readline?

• Readable stream에서 한번에 한 줄씩 데이터를 읽기 위한 인터페이스를 제공하는 모듈
  • 데이터를 읽기 위해 인터페이스를 제공해주는 모듈
  • Javascript에 내장되어 있는 듯 하다

사용 방법

1. readline 모듈 불러오기

const readline = require("readline");

2. readline 인터페이스 생성하기

const rl = readline.createInterface({
    input: process.stdin,
    output: process.stdout,
})

• process.stdin : standard input에 대한 readable stream
• process.stdout : standard output에 대한 writable stream
  • stream?
    • 일련의 연속성을 갖는 흐름을 뜻함. 데이터, 파일 등 컴퓨터 프로그램과 환경 사이에 미리 연결된 입출력 통로

3. 입출력 처리하기

rl.on("line", (line) => {
    /* 입력값 처리 코드 */
    rl.close()
})

rl.on("close", () => {
    /* 입력 이후 실행 코드 */ 
    process.exit();
})

• rl.on 을 이용하여 이벤트와 콜백함수를 전달하게 됨
  • line : 입력 받은 값을 한 줄씩 읽어 문자열 타입으로 전달하는 이벤트
  • close : 더 이상 입력값이 없을 경우에 해당하는 이벤트
• rl.close() : 인터페이스를 종료하며 무한 입력받기를 방지
• process.exit() : 프로세스 종료

사용 예시

| 프로그래머스 - 문자열 출력하기

const readline = require('readline');
const rl = readline.createInterface({
    input: process.stdin,
    output: process.stdout
});

let input = [];

rl.on('line', function (line) {
    input = [line];
}).on('close',function(){
    str = input[0];
});

jsx로 만든 child component에서 props로 받는데 빨간줄이 생겼다 → 근데 브라우저에서 실행하면 정상 동작이 되긴 한다😡

원인 추측

| 참고 블로그 javascript에서는 props의 타입을 지정해주지 않기 때문에 타입이 정확한지 잡아낼 수 없어서 검사해줘야 하는 거 같다.(typescript 쓸 때는 본 적 없는 상황이긴 하다) 참고한 블로그에 의하면 해결 방법으로 props-type 라이브러리를 설치하고 그러는 방법도 있던데 내가 선택한 해결 방법은,

해결방법

| 참고 스택 오버 플로우 스택 오버 플로우에서 알아낸 방법 두 가지 중 하나를 선택해서 적용하면 된다.

1. .eslintrc 의 "rules" 에 옵션 추가

   "rules": {
    "react/prop-types": "off"
   }

2. 빨간 밑줄이 그어지는 코드 위에 아래 내용 추가(나는 코드의 의미를 위한 내용이 아니라서 싫어하는 방법이다)

   /* eslint-disable react/prop-types */

🤔 이것저것 예제 코드를 치다보니 문득 궁금해졌다. useState의 초깃값으로 값을 넣어주기도 하지만 함수를 넣어서 그 함수의 반환값을 초깃값으로 사용하기도 하는데 무슨 차이가 있는 걸까? 나는 함수 반환값을 넣어본적이 예제 코드 외에 자의적으로 한 적은 없긴 하지만 사용법을 알면 더 잘 사용하게 될지두....

게으른 초기화 | lazy initialization

initialState를 설정해줄때 원시값이 아니라 값을 반환해주는 함수를 넣는 것을 게으른 초기화(lazy initialization)이라고 한다

📘 공식 문서

❝ The initialState argument is the state used during the initial render. In subsequent renders, it is disregarded. If the initial state is the result of an expensive computation, you may provide a function instead, which will be executed only on the initial render:

initialState 인수는 초기 렌더링 중에 사용되는 상태입니다. 후속 렌더링에서는 무시됩니다. 초기 상태가 비용이 많이 드는 계산의 결과인 경우 대신 초기 렌더링 시에만 실행되는 함수를 제공할 수 있습니다. ❞

예제 만들어서 확인해보기

1. useState를 두개 사용해주었다

   • value는 initialState를 값으로, lazy는 함수의 반환값으로 설정해주되 setState로 컴포넌트가 렌더링 됐을 때 어떻게 보이는 지를 알기 위해 콘솔에 메시지를 찍어주도록 해보았다.

2. 렌더 트리거가 일어나서 컴포넌트가 렌더링 될 때마다 콘솔에 메시지를 찍어주도록 해주었다.

결과 확인

실제로 initial state를 설정해주는 callback 함수는 최초 렌더 시에만 동작하고 이후 state의 변화로 인해 리렌더가 일어나도 재실행 되지 않음을 볼 수 있었음

👉 결론

동작 방법에 차이는 없었고 성능을 위해서 정말 무거운 작업을 통해 initial state가 설정될 때 사용하는 거 같다

😅 그리고 잠깐 했던 바보같은 생각.

useMemo로 복잡한 로직을 통해 도출되는 값을 관리하는데 useState의 lazy initialization을 이용해서 두면 되지 않을까?

응 안돼.

useState는 component의 render trigger를 일으키는 state를 관리하는 훅이다. 처음에만 지정해놓고 이후에 state의 변화가 없다면(그로 인해 렌더 트리거를 일으키지 않을거라면) 용도에 맞지 않다. 고로, 각자 훅은 제각기 용도가 있으니 맞게 잘 사용하자.

리덕스의 동작이 어떻게 이루어지는 지 대충 훑어봤다. state를 단순히 등록하고 가져오는 것 뿐만 아니라 해당 state가 어떻게 변하게 할 것인지, state가 변했을 땐 해당 state를 사용하는 컴포넌트에 렌더링을 일으켜 주는 등 global state를 관리해준다는 느낌을 받았다.
그럼 이제 context가 뭔지 알아보자.

context란?

props drilling이 발생했을 때 props 내려주기를 극복하기 위해 등장한 개념.

import { PropsWithChildren, createContext, useContext } from "react";

const MyCotext = createContext<{ hello: string } | undefined>(undefined);

const ContextProvider = ({
  children,
  text,
}: PropsWithChildren<{ text: string }>) => {
  return (
    <MyCotext.Provider value={{ hello: text }}>{children}</MyCotext.Provider>
  );
};

const useMyContext = () => {
  const context = useContext(MyCotext);
  if (context === undefined) {
    throw new Error(
      "useMyContext는 ContextProvider 내부에서만 사용할 수 있습니다"
    );
  }

  return context;
};

const ChildComponent = () => {
  const { hello } = useMyContext();

  return <h3>{hello}</h3>;
};

export const ParentComponent = () => {
  return (
    <ContextProvider text="react">
      <ChildComponent />
    </ContextProvider>
  );
};

• 이런식으로 어떤 값을 원하는 곳에서 쓸 수 있게 해주는 일종의 통로 역할임
• 값이 꼭 state가 아니어도 됨(예제에서도 그냥 react라는 string일뿐 state가 아님)

useContext를 사용할 때 주의할 점

useContext를 함수형 컴포넌트 내부에서 사용할 때는 항상 컴포넌트 재활용이 어려워진다는 점을 염두에 둬야 함. useContext가 선언되어 있으면 Provider에 의존성을 가지고 있는 셈이 되므로 아무데서나 재활용하기에는 어려워질 수 있음.

• context를 사용하고자 하는 컴포넌트가 Provider의 하위 컴포넌트로 존재해야만 사용할 수 있음 → 재활용 했을 때 컴포넌트의 위치가 자유로울 수 없음

책에서 발췌한 나를 관통하는 내용이 있어 옮겨적어보겠다.

일부 리액트 개발자들이 콘텍스트와 useContext를 상태 관리를 위한 리액트의 API로 오해하고 있다는 것이다. 엄밀히 따지면 *콘텍스트는 상태를 주입해주는 API**다. 상태 관리 라이브러리가 되기 위해서는 최소한 다음 두 가지 조건을 만족해야 한다.

1. 어떠한 상태를 기반으로 다른 상태를 만들어낼 수 있어야 한다.
2. 필요에 따라 이러한 상태 변화를 최적화 할 수 있어야 한다.*

하지만 context는 둘 중 어느것도 하지 못한다. 단순히 props값을 하위로 전달해 줄 뿐, useContext를 사용한다고 해서 렌저링이 최적화되지도 않는다.

확실히 redux는 state를 등록, 관리해주는 느낌이었지만 context는 위에서 기술한것처럼 일단 반드시 state를 내보내지 않아도 될 뿐더러 단순히 어떤 값이 필요해서 꺼내쓰기만 하는 느낌이었다. 이를 global state로 응용하기 위해 useState, useReducer등을 함께 사용하는 것 뿐인 거 같다

📘 참고 : 모던 리액트 Deep dive - Chapter3

🤔 리덕스로 전역 상태를 관리하다보니 이전 회사에서는 주로 ContextAPI를 사용했던 기억이 났다. 그러면서 둘의 차이점이 뭘까에 대한 고민이 생겼다.
서치해보니 주로 사용법에 대한 차이점이 기술되어 있었고 나는 그거 말고 개념적으로 무엇이 다른가에 대해 궁금해졌다. 그럼 Context는 뭐지?

일단 redux의 동작을 더 이해해보자

useState로 redux 구현해보기

useState로 리덕스를 구현해보면 리덕스의 동작 원리를 이해하는 데 도움이 될 거 같아서 시도해보기로 했다.

예제 Counter1, Counter2라는 각각의 컴포넌트에서 동일한 state를 이용하는 경우 이를 global state로 관리하는 예제

store 타입 생성

• get : store에서 관리중인 state의 최신 상태를 반환해줌
• set : store에서 관리중인 state의 상태 변화를 일으키는 함수로써 상태를 반환함 ≒ setState
• subscribe : store의 변경을 감지하고 싶은 컴포넌트들이 자신의 callback 함수를 등록하는 곳
• unsubscribe : subscribe 함수가 받아온 callback함수를 등록된 callbacks에서 제거

createStore, useStore 생성

• 사용할 store를 받아서 get으로 최신 상태를 받은 후 useState의 초기값으로 설정
• useStore의 useEffect 에서 선언한 callbackFn 함수는 setState로 state를 변화시키기 때문에 리렌더링을 일으킴(렌더 트리거)
• clean up이 일어날 때 unsubscribe (callbacks에서 callbackFn 삭제) 실행
  • 여기에서 약간 헷갈렸는데 clean up 함수는 함수가 일단 등록되고 clean up이 되는 시점에 실행된다. 그런데 useEffect return 함수에 함수가 아니라 함수를 실행시켜버리면(return unsubscribe()), clean up 시점이 오기도 전인 컴포넌트가 렌더링 되자마자 실행되어 버리기 때문에 useStore 함수가 제대로 동작하지 않게 된다 → subscribe 하자마자 unsubscribe 되기 때문에 비정상 동작

컴포넌트에서 store 사용하기

• Counter1, Counter2 라는 각각의 컴포넌트에서 동일한 store의 state 사용

이대로 진행하면 각 counter의 버튼을 누를때마다 store를 공유하며 업데이트 되는 것을 알 수 있다. 하지만 store가 원시값이 아니라 객체일 경우, 일부만 바뀌어도 useState가 실행되므로 store의 어떤 값이 바뀌든지 간에 리렌더링이 일어나게 된다. ⇒ 원하는 값이 바뀌었을때만 리렌더링 되도록 수정해보자

store에서 원하는 값이 바뀌었을때만 리렌더링하도록 하기

useStoreSelector 생성

• store에 등록된 상태 중 사용할 상태만 selector라는 콜백 함수로 반환받아서 value로 등록하여 사용

컴포넌트에서 사용해보기

• store에 등록된 상태는 이제 count, text 이렇게 두가지이다

• count를 사용할 컴포넌트에서는 selector 함수로 count만 뽑아서 사용하고, text를 사용할 컴포넌트에서는 selector 함수로 text만 뽑아서 사용한다

• 근데 이때 selector 함수를 useCallback으로 감싸준다

  • dependencies를 빈 배열로 줘서 최초 렌더시에만 등록할 수 있도록 해줬는데 이렇게 하지 않으면 상태의 변화에 따라 컴포넌트가 리렌더 됐을 때 selector 함수는 동일한데 계속해서 unsubscribe → subscribe가 계속 반복되기 때문이다

  • useCallback을 사용하고 싶지 않다면 컴포넌트 리렌더 시 해당 컴포넌트내에 등록된 함수가 재실행되는게 문제이기 때문에 컴포넌트 바깥에 함수를 생성하고 컴포넌트 안에서 해당 함수를 가져다 쓰는 것도 해결방법이 될 수 있다

⚠️ 문제 발생!

• 그런데 어째서인지

  $ vi ~/Library/KeyBindings/DefaultKeyBinding.dict

  를 실행하면, 이런 에러 메시지가 뜨는 것이 아니겠는가?
  • 읽을수만 있는 옵션이라 덮어쓸 수 없다고?

• 그래서 혹시나 하는 마음에 vi 대신 touch로 실행해봤다

  • 그러면 아까와는 조금 다른 에러 메시지가 보인다
  • 흠? 권한이 없다는 데?

• 찾아보니 유닉스 코드를 관리자 권한으로 실행하기 위해선 앞에 sudo 를 붙여줘야 한다고 한다

  • Password를 입력하라는 말에 너무 설렜지만 이내 No such file or directory라는 문구를 만나게 되고....

  

  • vi로 다시 재도전하니까 정상적으로 설정할 수 있었다!!

🤔 궁금해진 점

touch, vi의 차이는 뭘까?

• touch

• vi

• 초기 세팅을 해보자

1. homebrew 설치

• 공식문서 참조하여 설치

• 설치되고 나서 커맨드 입력하라는 메시지를 무시했더니 brew 명령어 실행이 안됐음

  • 자세히 보니 친절하게 뭐뭐 커맨드에 입력하라고 되어 있다😅

2. brew로 node 설치

    brew install node

3. nvm(node version manager) 설치

• nvm 리포지토리에 있는 문서 참조하여 설치

  curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh

  

  • 설치가 끝나면 안내 문구에

    => Appending nvm source string to /Users/air/.zprofile 

    • 이 나오고 이에 따라 해당 경로의 파일을 열어보면 안내 문구 아래에 있는 명령어가 들어 있었음

• 그리고 호기롭게 nvm 명령어를 입력했는데 실행이 안됨😫

• 그래서 공식문서를 뒤져봄 → Troubleshooting on macOS 항목 찾음 • If you use bash, it may be that your .bash_profile (or ~/.profile) does not source your ~/.bashrc properly. You could fix this by adding source ~/<your_profile_file> to it or following the next step below.

  • 그래서

    source .zprofile

    • 이렇게 하니 잘 작동함!

4. vscode를 code 로 여는 방법

• https://code.visualstudio.com/docs/setup/mac#_launching-from-the-command-line

5. pnpm 설치

• https://pnpm.io/installation#using-npm
  • 3번에서 Node를 설치해줬기 때문에 npm을 사용할 수 있음

• redux의 action.type 들을 enum으로 만듬
  • action.type 은 string이고 이를 enum으로 관리하는 게 좋아 보였기 때문
• action.type 에 따라 action.payload 가 바뀌어야 함
• reducer에서 payload 타입을 제대로 읽어내지 못함
• 에러

시도 방법

• 리듀서에서 받고 있는 action.payload 의 타입이 어떻게 됐는 지 확인

  • 어라? 어째서 action creator에서 반환된 값이 지정되지 않지? → case의action.type 은 TODO_ACTIONS 중에 하나를 사용하는 것이기 때문에 고정되는 것이 아님 → 그래서 payload 타입도 고정이 되지 않는 것임

    💡 아 그럼 ReturnType을 고정시키면 되겠구나

해결 방안

action.payload 타입을 action.type 에 매칭시켜서 고정하자!

• action creator의 반환값에 as const 사용
  • 이 함수가 반환하는 거는 이런 모양이야🔨 라고 못박기
  • creator 함수 모두의 반환값에 as const를 해주지 않으면 여전히 리듀서에서 헷갈려하기 때문에 모두 바꾼 후에 타입을 확인해야 함
• 결과
  • 각 action.type별로 payload 타입이 고정되었음을 확인했다(나머지 케이스는 너무 길어서 스샷 생략)

🤔 궁금해진 점

• 왜 action creator의 반환 값을 정해줬는데도 고정이 안된걸까?

  

  • action.type 을 구별해내는 enum이 TODO_ACTIONS 에 할당된 것들중 하나(string)이기 때문에 리듀서의 switch문에서 action.type의 case별로 정확히 구별해낼 수 없음 -> 따라서 TodoAction에 할당된 payload 값들 중에 하나가 될 것이라고 두루뭉술하게 알고 있음
  • 각 action creator별로 정확하게 이런 모양의 값이 반환될거야(= as const)라고 지정해줘서 리듀서에서 정확하게 체크할 수 있게 됨

• 왜 이게 궁금했지? → as const 를 한번에 이해하지 못해서 생긴 궁금점인거 같다

  • 공부해보려고 참고한 블로그