그럼에도 불구하고

[Bundler] 그래서 Webpack 있는데 Vite 왜 쓴다고? ( 번들러부터 익히기 )

zenghyun — Sat, 21 Oct 2023 00:08:00 +0900

요즘 추세를 보면 Webpack기반의 CRA보다 Vite를 많이 쓴다고 해요

2021 JavaScript Rising Stars

"남들도 Vite 쓰니까~ 나도 Webpack 말고 Vite 써보자" 하고 썼던 나를 반성하는 글입니다.

( 최소한 이유는 알고 쓰자..ㅎㅎ )

ㅜㅜ

‍ 번들러 ( Bundler)

번들러는 여러개의 파일들을 하나의 파일로 묶어주는 도구입니다.

번들러는 웹 개발에서 사용되는 도구 중 하나로, 웹 애플리케이션을 개발하거나 배포할 때 사용됩니다. 번들러의 주요 역할은 여러 개의 웹 리소스 파일, 예를 들면 JavaScript 파일이나 CSS 파일 그리고 이미지 파일 등을 하나의 번들(묶음)로 결합하고 최적화하는 것입니다.

이러한 작업을 통해 웹 애플리케이션의 성능을 향상하고 로딩 시간을 줄일 수 있습니다.

번들링을 하지 않는다면 매우 많은 네트워크 요청이 필요하게 됩니다.

그중에서 가장 각광받고 있는 번들러는 Webpack입니다.

Webpack

웹팩(Webpack)은 JS 애플리케이션을 위한 가장 인기 있는 번들러 중 하나입니다.

설정이 간편하고 직관적임

하나의 설정 파일에서 원하는 번들이 생성되도록 컨트롤할 수 있습니다.

entry와 output을 명시하고 어떤 plugin과 loader로 파일을 다룰 건지 명시하면 됩니다.

다양한 plugins과 loaders

webpack은 강력한 개발 커뮤니티로 인해 쉽게 plugin과 loader를 추가할 수 있습니다. loader를 통해 파일들을 변환, 번들링, 빌드를 진행하고 plugin을 통해 output 파일을 튜닝해 줄 수 있습니다.

강력한 개발 서버

webpack은 Hot Module Replacement(HMR)를 사용하는데 HMR은 소스코드의 변화를 감지하여 브라우저를 직접 새로고침할 필요가 없이 변화를 바로 반영해 줍니다. 그 외에도 작업 중인 상태나 데이터를 유지해 주거나, 모듈 간의 일관성을 유지해주기도 합니다.

( 그저 빛.. )

Code Splitting

코드 스플리팅을 통해 번들 로드를 최적화할 수 있습니다. 파일들을 여러 번들 파일로 분리하여 병렬로 스크립트를 로드하여 페이지 로딩속도를 개선할 수 있습니다. 추가로 초기에 구동될 필요가 없는 코드를 분리하여 lazy loading을 통해 페이지 초기 로딩속도를 개선할 수 있습니다.

우리가 CRA를 써왔던 이유

Create React App( CRA )을 써서 리액트 프로젝트를 생성한 경험, 다들 있으시죠?

CRA는 facebook React Team에서 추천하는 공식 React boilerplate이며, HMR과 같은 유용한 기능을 제공합니다. 기본적으로 번들링이 필요한데 Webpack의 여러 가지 장점을 다 사용할 수 있으니 CRA는 많이 쓰였습니다.

하지만, 장점만 있는 건 아닙니다.

CRA는 Webpack을 사용합니다. Webpack은 자바스크립트 코드로 구성된 툴인데 JS는 interpreted 언어이기 때문에 느립니다. 또한, 프로젝트가 커질수록 처리해야 할 코드의 양이 많아지기 때문에 성능 병목 현상이 발생되었고, 개발 서버를 가동하는데 비합리적으로 오랜 시간을 기다려야 하는 단점이 생겼습니다.

느린 피드백이 반복되면 개발자의 생산성과 만족도는 매우 낮아지기 때문이죠.

그래서 개발자들은 Go와 같은 low-level language를 활용하여 자바스크립트 툴을 만들게 되는데

그렇게 만들어진 게 ESBuild입니다.

엄청나게 빠른 esbuild

ESBuild

ESBuild는 기존의 번들러가 내부적으로 JavaScript을 기반으로 번들링 하기 때문에 성능상의 한계를 극복하고자 만들어졌습니다.

ESBuild는 내부적으로 GO로 작성되었고 JS 기반의 번들러보다 10배에서 100배까지 빠른 엄청난 퍼포먼스를 보여줬습니다.

( 번들러로서의 필수적인 기능도 갖춤 )

⭐️ 장점

네이티브 코드 방식을 사용
병렬 처리의 최적화
메모리 사용 최적화
자체적인 JavaScript Parser 채택

⭐️ 단점

code splitting 및 CSS와 관련된 처리가 미비함
esbuild는 ES5 이하의 문법을 완벽하게 지원하지 못함
webpack만큼 유연하지 못하고 안전성 관련한 이슈가 존재

Vite는 ESBuild를 단점을 보완하여 만들어진 프론트엔드 빌드툴입니다.

Vite

공식 홈페이지에 따르면, Vite는 "빠른"이라는 의미의 프랑스어로 오늘날 웹 프로젝트에 더 빠르고 가벼운 개발 경험을 제공하는 것을 목적으로 하는 빌드 도구입니다.

Vite는 크게 두 가지 키 포인트로 나눌 수 있습니다.

1. Native ES modules 기반의 강력한 개발 서버

2. ESBuild로 파일을 통합하고 Rollup 통해 번들링

전반적으로 ESBuild로 성능을 끌어오고 Rollup을 통해서 번들링의 유연성을 챙깁니다.

그래서 왜 Vite가 빠른 건데?

Webpack 기반의 프로젝트와 비교했을 때 Vite 기반의 프로젝트가 dev server를 시작하는데 훨씬 더 빠릅니다.

dev server 시작 시간이 빠른 이유는 예상할 수 있듯이 ESBuild를 이용하여 종속성을 미리 묶어버리기 때문입니다.

Vite는 번들을 두 가지 부분으로 분류합니다.

외부 의존성: 외부 의존성은 개발하는 동안 바뀌지 않는 일반적인 자바스크립트를 말합니다. ( node_modules와 같은 import 되는 JS module ) Webpack은 브라우저의 요청 이전에 모든 자바스크립트 모듈을 처리하는 반면, Vite은 ESBuild를 이용하여 외부 의존성만 미리 번들링 해놓습니다. 여기서 ESBuild는 자바스크립트 기반의 번들러보다 10~100배 빠르게 의존성을 미리 번들링 합니다.
내부 프로젝트 코드 (ES Module): Vite는 네이티브 ESM을 통해 소스 코드를 제공합니다. (.jsx, .vue. .scss 등) 이는 번들러 작업의 일부를 브라우저에 인계하는 것으로, 브라우저 요청 시마다 소스 코드를 변환하고 제공하기만 하면 됩니다. 조건부 동적 가져오기 뒤에 있는 코드들은 현재 화면에서 실제로 사용되는 경우에만 처리됩니다.

이는 서버가 시작되기 전에 코드를 번들링 하여 시간을 소비하지 않는다는 것을 의미합니다.

기존의 Bundler

Vite

Vite가 번들링을 미리 하는 이유

대부분의 브라우저가 기본적으로 ES Module Loading을 지원하지만, 모든 유저가 최신 브라우저를 사용하는 게 아니라면 여전히 번들링은 필요합니다. 번들링을 하지 않는다면, 여러 모듈을 가져오기 위해서 매우 많은 네트워크 요청이 필요하게 됩니다.

최적화된 Loading Performance를 얻기 위해서는 트리 쉐이킹(tree-shaking), 지연 로딩(lazy loading), 그리고 더 나은 캐싱을 위한 청크 스플리팅(chunk splitting)을 이용하여 코드를 번들링 하는 것이 좋습니다.

Vite는 HMR도 남달라

HMR은 다른 페이지에 영향을 끼치지 않고, 특정 모듈만 즉시 반영이 될 수 있게 해 줍니다.

그러나 프로젝트의 크기가 커질수록, HMR의 시간 또한 길어지게 되어 생산성 저하로 이어집니다.

Vite는 번들러가 아니라 네이티브 ESM을 기반으로 HMR을 구현하기 때문에 다른 번들링 툴보다 우위에 있습니다. 모듈이 수정됐을 때, Vite는 수정된 모듈과 관련된 부분만 교체할 뿐이고, 브라우저에서 해당 모듈을 요청하면 교체된 모듈을 전달할 뿐입니다. 모든 과정에서 완벽하게 ESM을 이용하기 때문에, 앱 사이즈가 커져도 HMR을 포함한 갱신 시간에는 영향을 끼치지 않습니다.

Vite과 SSR ( Server Side Rendering )

Vite는 SSR에서도 사용할 수 있지만, 아직 experimetal 단계라고 합니다.

자세한 내용은 아래 링크를 참조해 주세요 :)

https://ko.vitejs.dev/guide/ssr.html

Vite

Vite, 차세대 프런트엔드 개발 툴

ko.vitejs.dev

그럼 CRA 안 쓰고 Vite를 쓰는 게 좋을까?

위에서 언급한 것처럼 CRA 대신에 Vite를 많이 사용하는 추세라고 합니다. 번들링 속도 향상이 주는 메리트가 크기 때문이겠죠?

Vite가 지금보다 더 안정되거나 앞으로 SSR을 폭넓게 지원한다면, 더 많이 사용될 수 있지 않을까 조심스레 예상해 봅니다. :)

기존 CRA 기반의 프로젝트를 Vite로 변경하는 데는 Webpack에서 디테일한 설정들을 사용하고 있을 수 있기 때문에, 고려해야 할 상황이 많지만 Webpack에서 기본적인 설정만 사용한다면 더 나은 개발 경험을 위해 Vite를 쓰는 게 좋지 않을까 생각도 듭니다.

‍ 결론

Vite는 외부 번들링을 미리 해놓아서 개발 서버의 시작 속도를 높인다.
Vite는 핫 모듈 리플레이스먼트를 위해 네이티브 ES모듈을 활용한다. 따라서 더 빠르게 코드의 변경 사항이 반영될 수 있다.
Vite는 합리적인 기본 설정값을 가지고 있어서 최소한의 설정으로도 개발을 진행할 수 있다.

출처

https://velog.io/@sehyunny/is-it-time-to-say-goodbye-to-webpack

https://ko.vitejs.dev/guide/why.html

https://bepyan.github.io/blog/2023/bundlers

https://velog.io/@eamon3481/Vite-%EB%8A%94-Webpack%EC%9D%84-%EB%8C%80%EC%B2%B4-%EA%B0%80%EB%8A%A5%ED%95%A0%EA%B9%8C

https://velog.io/@jaewoneee/%EB%A6%AC%EC%95%A1%ED%8A%B8-%EB%B3%B4%EC%9D%BC%EB%9F%AC%ED%94%8C%EB%A0%88%EC%9D%B4%ED%8A%B8-Create-React-App-vs-Vite

[React Query] isLoading과 isFetching은 헷갈려

zenghyun — Thu, 19 Oct 2023 11:17:16 +0900

React Query를 공부하다 보면 isLoading과 isFetching에 대해 그냥 지나칠 수 없는데

너무 헷갈려서 정리해보기로 했습니다.

‍ isLoading이 끝나지 않는 경우

button을 눌렀을 때 react query를 사용하여 비동기 방식으로 data를 가져올 건데, enabled:false 이면 isLoading이 계속 true인 문제가 발생했습니다. ( button을 누르기 전부터 isLoading 상태임 )

즉, button을 눌렀다면 enabled: true 가 되어 해당 query의 isLoading이 true에서 false로 변경되고 UI가 보여야 하는 상황인데 보이지가 않았습니다.

하염없이 기다려도 무한 Loading..

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
import { useCallback } from "react";
import { useQuery } from "@tanstack/react-query";
import axios from "axios";
 
const fetchSuperHeroes = async () => {
  return await axios.get("http://localhost:4000/superheroes");
};
export const RQSuperHeroesPage = () => {
  const {
    isLoading,
    data,
    isError,
    error,
    refetch,
  } = useQuery({
    queryKey: ["super-heroes"],
    queryFn: fetchSuperHeroes,
    enabled: false,
  });
 
  const handleClickRefetch = useCallback(() => {
    refetch();
  }, [refetch]);
 
  if (isLoading) {
    return <h2>Loading...</h2>;
  }
 
  if (isError) {
    return <h2>{error.message}</h2>;
  }
 
  return (
    <>
      <h2>RQ Super Heroes Page</h2>
      <button onClick={handleClickRefetch}>Fetch Heroes</button>
      <ul>
        {data?.data.map((hero) => {
          return <li key={hero.name}>{hero.name}</li>;
        })}
      </ul>
    </>
  );
};
 
Colored by Color Scripter
cs

왜 계속 Loading 상태가 지속되는걸까...

우선 useQuery의 status와 fetchStatus에 대해 알아보자.

useQuery는 무엇을 리턴하는가?

1
2
3
4
5
6
7
8
const { status, isLoading, isError, error, data, isFetching, ... } = useQuery({
queryKey: ["colors", pageNum],
queryFn: () => fetchColors(pageNum)
}
);
 
 
 
Colored by Color Scripter
cs

status: 쿼리 요청 함수의 상태를 표현하는 status는 4가지의 값이 존재합니다.
- idle : 쿼리 데이터가 없고 비어있을 때, { enabled: false } 상태로 쿼리가 호출되면 이 상태로 시작합니다.
- loading : 아직 캐시된 데이터가 없고 로딩중일 때의 상태입니다.
- error : 요청 에러가 발생했을 때의 상태입니다.
- success : 요청 성공했을 때의 상태입니다.
data: 쿼리 함수가 리턴한 Promise에서 resolved 된 데이터를 말합니다.
isLoading : 캐싱된 데이터가 없을 때 즉, 처음 실행된 쿼리일 때 로딩 여부에 따라 true/false를 반환합니다.
- 이는 캐싱된 데이터가 있다면 로딩 여부에 상관없이 false를 반환합니다.
isFetching : 캐싱된 데이터가 있더라도 쿼리가 실행되면 로딩 여부에 따라 true/false를 반환합니다.
- 이는 캐싱된 데이터가 있더라도 쿼리 로딩 여부에 따라 true/false를 반환합니다.
error : 쿼리 함수에 오류가 발생한 경우, 쿼리에 대한 오류 객체를 반환합니다.
isError : 에러가 발생한 경우 true 상태입니다.
그 외의 여러가지의 반환 데이터들이 존재합니다.

useQuery 공식 사이트 문서

https://tanstack.com/query/v4/docs/react/reference/useQuery

useQuery | TanStack Query Docs

const { data,

tanstack.com

Tanstack Query (React Query v4)

Tanstack Query(v4) 부터는 status의 idle이 제거되고, 새로운 상태값인 fetchStatus가 추가되었습니다.

⭐️ fetchStatus

fetching : 쿼리가 현재 실행중입니다.
paused : 쿼리를 요청했지만, 잠시 중단된 상태입니다.
idle : 쿼리가 현재 아무 작업도 수행하지 않는 상태입니다.

v4부터 status와 fetchStatus를 나누는 이유

fetchStatus는 HTTP 네트워크 연결 상태와 좀 더 관련된 상태 데이터입니다.
- 예를 들어, status가 success 상태라면 주로 fetchStatus는 idle 상태지만, 백그라운드에서 re-fetch가 발생할 때 fetching 상태일 수 있습니다.
- status가 보통 loading 상태일 때 fetchStatus는 주로 fetching를 갖지만, 네트워크 연결이 되어 있지 않은 경우 paused 상태를 가질 수 있습니다.
정리하자면 아래와 같습니다.
- status는 data가 있는지 없는지에 대한 상태를 의미합니다.
- fetchStatus는 쿼리 즉, queryFn 요청이 진행 중인지 아닌지에 대한 상태를 의미합니다.

자세한 얘기는 아래를 참고하자 :)

https://tanstack.com/query/v4/docs/react/guides/queries#why-two-different-states

Queries | TanStack Query Docs

Query Basics A query is a declarative dependency on an asynchronous source of data that is tied to a unique key. A query can be used with any Promise based method (including GET and POST methods) to fetch data from a server. If your method modifies data on

tanstack.com

Why two different states?

"isLoading or status === 'loading' - The query has no data yet"

공식문서를 읽어보면, isLoading은 쿼리가 아무 데이터도 캐싱하고 있지 않은 경우를 나타낸다고 생각할 수 있습니다.

enabled: false 인 경우 쿼리를 보내지 않았으므로 데이터가 비어있게 되고, isLoading이 true로 남아있는 것이 의도된 작동으로 보입니다.

즉, 처음 의도한 것처럼 button을 눌렀을 때 데이터를 요청하고, 이를 기다리는 중인지를 알려면 isFetching을 사용해야 합니다.

The status gives information about the data : Do we have any or not? 
The fetchStatus gives information about the queryFn : Is it running or not?

쿼리가 괜찮은? (요청에 성공해서 받아온) 데이터를 들고 있는지는 status로, 쿼리의 요청 상태는 fetchStatus로 알 수 있는 것입니다.

Stale While Revalidate

background refetch와 stale-while-revalidate는 별개의 두 가지 feature 가 아닙니다.

React Query는 데이터를 캐싱하고, 해당 데이터가 필요할 때 더 이상 최신 상태가 아니더라도(stale) 데이터를 제공합니다.

"오래된 데이터가 없는 것보다는 낫다는 것"

데이터가 없다는 것은 대개 Loading Spinner의 표시를 의미하며, 이는 사용자 경험 (User Experience)에서 안 좋은 영향을 미치기 때문입니다.

따라서 오래된 데이터를 보여줌과 동시에 background refetch를 수행하여 해당 데이터를 다시 검증(stale-while-revalidate) 합니다.

예를 들어, 현재 fetching에 성공한 올바른 데이터가 캐싱되어 있는 경우는 오직 status === success 일 때뿐입니다. 즉, isLoading 이 true 인 경우( status === loading ) 에는 쿼리에 아무 데이터도 없는 상황으로 해석됩니다.
이는 데이터가 stale 한 것과는 다릅니다. 가장 최근의 query가 성공해서 데이터를 들고 있다면, status는 success 상태여야 하기 때문입니다. ( status는 데이터의 상태이기 때문 )
그런데 데이터를 보여주고 있는 와중에 해당 데이터가 stale 한 지 revalidate를 수행하고 싶다면 어떻게 해야 할까요? (background refetch)
status 하나만으로 관리하는 경우, 이 refetch에 대해서도 status === loading으로 변경되어야 할 것입니다.
그러면 기껏 캐싱된 데이터를 들고 있는 의미가 사라진다. 어차피 loading 인 동안에는 일반적으로 데이터가 없는 것으로 간주하고 로딩 UI를 보여주기 때문입니다.
즉 데이터가 아예 없는 경우와, 데이터가 있지만 오래되어 유효한지 검증 중인 경우를 구분할 수 없게 됩니다.
따라서 background refetch를 포함해 쿼리의 요청 상태를 나타내기 위한 fetchStatus가 필요합니다. status(loading)로 사용자에게 보여줄 수 있는 멀쩡한 데이터를 들고 있는지 판단하고, fetchStatus(fetching)로 데이터 업데이트를 시도 중인지 판단할 수 있게 됩니다.

결론

status는 데이터의 상태를 나타내고, fetchStatus는 쿼리의 요청 상태로 이해하여 loading과 fetching은 각각 위 상태의 일부라고 생각하는 게 좋을 것 같습니다.

stale 한 데이터를 갱신하는 요청은 isFetching을 사용하고 아직 호출된 적이 없거나, cacheTime이 종료되었거나 등 캐시가 없는 쿼리의 요청은 isLoading && isFetching을 사용해야 할 것 같습니다.

  if (isLoading && isFetching) {
    return <h2>Loading...</h2>;
  }

제대로 작동한다~

[React Query] 페이지네이션(Pagination)과 데이터 프리페칭(Prefetching)

zenghyun — Wed, 18 Oct 2023 22:11:14 +0900

React Query에서 페이지네이션(Pagination)과 데이터 프리페칭(Prefetching)에 대해 알아보겠습니다.

‍ Pagination

예를 들어, 블로그의 게시글을 나열하는데 페이지 번호를 매겨서 나타낼 때가 있습니다. 이때 React Query의 Pagination을 사용하면 현재 페이지(current page) 상태를 통해, 현재 페이지를 파악할 수 있습니다.

사용 예시

최대 페이지의 수는 10 const MAX_POST_PAGE = 10;
사용자가 다음, 또는 이전 페이지로 가는 버튼을 누르면 해당 페이지로 이동하며 currentPage의 상태를 업데이트합니다.
React Query는 바뀐 쿼리 키를 감지하고 새로운 쿼리를 실행해서 새 페이지가 표시됩니다.

전체 코드

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
import { useEffect, useState } from "react";
import { useQuery, useQueryClient } from "@tanstack/react-query";
 
import { PostDetail } from "./PostDetail";
const MAX_POST_PAGE = 10;
 
async function fetchPosts(currentPage) {
  const response = await fetch(
    `https://jsonplaceholder.typicode.com/posts?_limit=10&_page=${currentPage}`
  );
  return response.json();
}
 
export function Posts() {
  const [currentPage, setCurrentPage] = useState(1);
  const [selectedPost, setSelectedPost] = useState(null);
 
  const quertClient = useQueryClient();
 
  useEffect(() => {
    if (currentPage < MAX_POST_PAGE) {
      const nextPage = currentPage + 1;
      quertClient.prefetchQuery(["posts", nextPage], () =>
        fetchPosts(nextPage)
      );
    }
  }, [currentPage, quertClient]);
 
  const { data, isError, error, isLoading } = useQuery({
    queryKey: ["posts", currentPage],
    queryFn: () => fetchPosts(currentPage),
    staleTime: 2000,
    keepPreviousData: true,
    /**
     * 쿼리 키가 바뀌어도 지난 데이터를 유지해서 혹여나 이전 페이지로 돌아갔을 때
     * 캐시에 해당 데이터가 있도록 만들기 위해 keepPreviousData를 true로 설정
     */
  });
 
  if (isLoading) return <h3>Loading...</h3>;
  if (isError)
    return (
      <>
        <h3>Oops, something went wrong!</h3>
        <p>{error.toString()}</p>
      </>
    );
 
  return (
    <>
      <ul>
        {data.map((post) => (
          <li
            key={post.id}
            className="post-title"
            onClick={() => setSelectedPost(post)}
          >
            {post.title}
          </li>
        ))}
      </ul>
      <div className="pages">
        <button
          disabled={currentPage <= 1}
          onClick={() => {
            setCurrentPage((previousPage) => previousPage - 1);
          }}
        >
          Previous page
        </button>
        <span>Page {currentPage}</span>
        <button
          disabled={currentPage >= MAX_POST_PAGE}
          onClick={() => {
            setCurrentPage((previousPage) => previousPage + 1);
          }}
        >
          Next page
        </button>
      </div>
      <hr />
      {selectedPost && <PostDetail post={selectedPost} />}
    </>
  );
}
 
Colored by Color Scripter
cs

1
2
3
4
 const { data, isError, error, isLoading } = useQuery({
    queryKey: ["posts", currentPage],
    queryFn: () => fetchPosts(currentPage),
  });
Colored by Color Scripter
cs

페이지마다 다른 쿼리 키가 필요하기 때문에 쿼리 키를 배열로 업데이트하여 가져오는 페이지 번호를 다음과 같이 포함합니다.

queryKey: ["posts", currentPage]

1
2
3
4
5
6
const { data, isError, error, isLoading } = useQuery({
    queryKey: ["posts", currentPage],
    queryFn: () => fetchPosts(currentPage),
  });
 
 
Colored by Color Scripter
cs

위와 같이 쿼리 키에 currentPage를 포함하게 되면 React Query가 바뀐 쿼리 키를 감지하여 새 쿼리 키에 대한 데이터를 업데이트합니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
     <button
          disabled={currentPage <= 1}
          onClick={() => {
            setCurrentPage((previousPage) => previousPage - 1);
          }}
        >
          Previous page
        </button>
        <span>Page {currentPage}</span>
        <button
          disabled={currentPage >= MAX_POST_PAGE}
          onClick={() => {
            setCurrentPage((previousPage) => previousPage + 1);
          }}
        >
          Next page
      </button>
 
async function fetchPosts(currentPage) {
  const response = await fetch(
    `https://jsonplaceholder.typicode.com/posts?_limit=10&_page=${currentPage}`
  );
  return response.json();
}
 
const [currentPage, setCurrentPage] = useState(1);
 
 
Colored by Color Scripter
cs

양쪽 페이지 버튼을 눌러 페이지를 이동하게 되는데, queryKey의 currentPage의 변경되면 queryFn도 바뀌게 됩니다.

즉, fetchPost에 currentPage를 인자로 받아 해당 페이지를 가져오게 됩니다

‍ Prefetching ( 데이터 미리 가져오기 )

위의 영상처럼 페이지전환은 잘 되지만 페이지를 가져올 때마다 바뀐 queryKey로 인해 새롭게 데이터를 받아오는 과정에서

Loading... 이 나타나는 것을 볼 수 있습니다.

이는 UX (User Experience) 측면에서 좋지 않습니다. ( 의도한 경우가 아니라면 )

Loading... 텍스트가 나오는 이유는 다음 페이지에 대한 캐시가 없기 때문입니다.

여기서 Prefetching을 사용하게 되면 이 문제를 해결할 수 있습니다.

Prefetching이란?

프리패칭은 데이터를 캐시에 추가하여, 구성할 수 있으며 기본값은 stale 상태입니다.

즉, 데이터를 사용하고자 할 때 stale state에서 데이터를 다시 가져오며, 데이터를 가져오는 중에는 캐시에 있는 데이터를 이용해 화면에 나타내게 됩니다. ( cacheTime이 만료되지 않았다는 가정하에 )

prefetching 기능을 사용하기 위해서 queryClient를 선언하겠습니다. ( prefetch는 queryClient의 메서드입니다. :) )

️ Ref

https://tanstack.com/query/latest/docs/react/reference/QueryClient#queryclientprefetchquery

QueryClient | TanStack Query Docs

QueryClient The QueryClient can be used to interact with a cache:

tanstack.com

import { useQuery, useQueryClient } from "@tanstack/react-query";

... 

const quertClient = useQueryClient();

여기서 useEffect를 사용하여 현제 페이지에 생기는 변경 사항을 활용하는 방식을 사용하겠습니다.

⭐️ 버튼을 눌렀을 때 onClick을 이용하여 prefetching 하면 안 될까?

onClick 버튼을 눌렀을 때 prefetchQuery를 사용하지 않는 이유는 상태 업데이트가 비동기식으로 일어나기 때문에 이미 업데이트가 진행됐는지 알 방법이 없고, 현재 페이지가 어디인지 알 수 있는 확실한 방법이 없기 때문입니다.

그에 반해, useEffect를 사용하면 []를 사용하여 currentPage가 변경되거나 mount 될 때마다 prefetchQuery를 사용하여 원활하게 데이터를 캐시에 추가할 수 있습니다.

1
2
3
4
5
6
7
8
useEffect(() => {
    if (currentPage < MAX_POST_PAGE) {
      const nextPage = currentPage + 1;
      quertClient.prefetchQuery(["posts", nextPage], () =>
        fetchPosts(nextPage)
      );
    }
  }, [currentPage, quertClient]);
cs

keepPreviousData

useQuery에서 keepPreviousData를 사용하여 쿼리 키가 바뀔 때도 지난 데이터를 유지할 수 있습니다.

혹여나 이전 페이지로 돌아갔을 때 캐시에 해당 데이터가 있도록 만들기 위하여 사용합니다.

1
2
3
4
5
6
 const { data, isError, error, isLoading } = useQuery({
    queryKey: ["posts", currentPage],
    queryFn: () => fetchPosts(currentPage),
    staleTime: 2000,
    keepPreviousData: true,
  });
Colored by Color Scripter
cs

위와 같이 다음 페이지를 prefetch하여 cache에 존재하는 데이터를 이용해 다음 페이지를 가져오는 것을 확인할 수 있습니다. :)

Ref

https://tanstack.com/query/latest/docs/react/reference/QueryClient#queryclientprefetchquery

SaaS(Sortware as a Service)가 뭐죠?

zenghyun — Tue, 17 Oct 2023 22:52:49 +0900

면접 중에 면접관님께서 하셨던 말씀이 있는데

저희는 SaaS 기반의 클라우드 컴퓨팅 서비스를 통해 소프트웨어를 제공하는데..

(초점잃은 나)

얼핏 알고 있던 SaaS가 정확히 어떤 의미인지 정의 내려지지 않아서 정리하기로 마음먹었습니다~~

https://www.huffingtonpost.kr/news/articleView.html?idxno=105898

그 SARS 바이러스 아니고요

위키피디아

CSS를 보완하고 더 효과적으로 작성하기 위한 전처리기 Sass 아니고요 (그저 빛..)

SaaS는 Sortware as a Service로! 우선 클라우드부터 보고 넘어가겠습니다.

‍ 클라우드?

클라우드는 다양한 데이터 센터에 있는 원격 웹 서버로서 데이터베이스를 호스팅 하고 애플리케이션 코드를 실행합니다. 클라우드 제공 업체는 인터넷을 통해 고객이나 최종 사용자에게 서비스를 전달할 수 있습니다.

클라우드에는 아래와 같이 3대 클라우드 서비스 모델이 존재합니다.

https://www.cloudflare.com/ko-kr/learning/cloud/what-is-saas/

SaaS는 3대 클라우드 서비스 모델 중 하나입니다. 클라우드 서비스 모델은 클라우드 제공 업체, 즉 다양한 데이터 센터에서 서버를 소유하고 운영하는 기업이 사용자와 기업에 제공하는 서비스의 범주입니다.

IaaS (Infrastructure as a Service) : 서비스형 인프라

IaaS는 쉽게 말해서 가상의 네트워크 공간을 사용하여 서버를 제공하는 서비스입니다. 서버와 저장하는 공간, 방화벽, 그리고 실제 데이터 센터 등을 통해서 인프라가 없어도 되는 서비스입니다. IaaS는 사용자가 애플리케이션, 데이터, 런타임, 미들웨어, 운영체제를 다룹니다. 그리고 서비스 공급자는 가상화, 서버, 스토리지, 네트워크를 제공합니다.

PaaS (Platform as a Service) : 서비스형 플랫폼

PaaS에서 사용자는 애플리케이션과 데이터를 다루고 이 외에 나머지는 서비스 공급자가 제공합니다. 즉, 개발할 수 있는 환경이 이미 구축되어 있기 때문에 인프라에 대한 걱정 없이 개발을 할 수 있다는 특징이 있습니다.

SaaS (Software as a Service) : 서비스형 소프트웨어

SaaS에서는 서비스 공급자가 애플리케이션, 데이터, 런타임, 미들웨어, 운영체제, 가상화, 서버, 스토리지, 네트워크까지 모두 제공한다는 특징이 있습니다.

https://www.cloudflare.com/ko-kr/learning/cloud/what-is-saas/

Sortware as a Service (소프트웨어 기반 서비스)의 약자로 클라우드 컴퓨팅 서비스의 한 종류입니다.

SasS는 소프트웨어 서비스 제공 모델을 말합니다. SaaS 모델에서는 고객이 소프트웨어를 자신의 컴퓨터나 서버에 설치하거나 유지 보수하지 않고 인터넷을 통해 소프트웨어 애플리케이션에 접근할 수 있습니다. 서버 구성, 보안 및 업그레이드와 같은 기술적인 부분은 SaaS 제공업체가 책임을 지고, 고객은 소프트웨어 라이선스 비용을 지불하고 필요한 만큼의 서비스를 이용할 수 있습니다.

즉, 사용자는 인터넷을 통해 호환 장치에서 SaaS 애플리케이션에 로그인하고 사용할 수 있습니다. 실제 애플리케이션은 사용자의 위치에서 멀리 떨어져 있을 수 있는 클라우드 서버에서 실행됩니다.

SaaS 애플리케이션은 브라우저나 앱을 통해 액세스 할 수 있으며, Gmail, Office 365 등 사용자가 브라우저를 통해 액세스 하는 온라인 이메일 애플리케이션입니다.

SaaS를 통해 고객들은 어떤 전자기기로도 쉽게 접근할 수 있다!

SaaS의 장점

1. 편리함, 쉬운 접근성

SaaS는 클라우드 기반으로 제공되므로 언제 어디서나 인터넷만 연결되어 있다면 애플리케이션에 접근할 수 있습니다.

2. 효율적인 비용

보통 초기 투자 비용이 적으며, 사용자 수나 기능에 따라 유연하게 요금을 책정하므로 기업의 필요한 만큼만 비용을 지불하여 운영 비용을 절감할 수 있습니다. 또한, 소프트웨어 유지보수나 업그레이드 등에 따른 추가 비용이 없어서 효율적입니다.

3. 소프트웨어의 설치 및 유지보수가 간단합니다.

SaaS 솔루션은 대부분 웹 인터페이스를 사용하기 때문에, 소프트웨어의 설치 및 유지보수가 쉽습니다. 또한, SaaS 제공업체가 서비스의 일부 또는 전체를 관리하기 때문에 사용자는 기술적인 문제를 처리하는데 시간을 소비하지 않고 핵심 업무에 더 집중할 수 있습니다.

4. 필요에 따라 확장이 용이합니다.

고객이 필요에 따라 추가 기능을 구매하거나, 사용자 수를 늘리거나, 서버 용량을 늘리거나, 지역적으로 확장할 수 있습니다.

5. 보안에 대한 우려를 줄여줍니다.

SaaS 제공 업체는 데이터 보안과 백업 및 복원과 같은 보안 문제를 처리하기 때문에 고객은 보안 문제를 신경 쓰지 않아도 됩니다. 또한, SaaS 소프트웨어에는 일반적으로 백업 기능이 내장되어 있기 때문에, 데이터가 손실되거나 손상될 위험을 줄일 수 있습니다.

SaaS의 단점

1. 네트워크에 영향을 많이 받습니다.

SaaS는 클라우드 서비스를 기반으로 하기 때문에, 인터넷 연결이 끊어지면 소프트웨어를 사용할 수 없습니다. 따라서, 인터넷 연결에 의존적이며 연결이 끊어질 경우 작업이 중단됩니다. 또한 클라우드 기반의 소프트웨어는 로컬 컴퓨터에서 실행되는 소프트웨어보다 일반적으로 느립니다.

2. 데이터 보안에 유의해야 합니다.

SaaS 제공업체가 데이터를 호스팅 하기 때문에, 보안 문제가 발생할 수 있습니다. 또한, 데이터가 클라우드 서버에 저장되므로 개인정보 유출 등의 문제가 발생할 수 있습니다.

3. 서비스 제공업체에 대한 의존성이 높습니다.

SaaS 솔루션은 일반적인 요구사항에 맞춰져 있기 때문에, 특정 기업의 요구에 맞게 맞춤화하기 어렵습니다. 특정 플랫폼 또는 브라우저에서만 실행되는 경우에는 해당 플랫폼 또는 브라우저에 대한 종속성이 있을 수 있습니다. 이는 기업의 요구사항에 맞춘 소프트웨어를 직접 개발하는 것보다는 비용이 적지만, 일부 사용자에게는 제한적인 기능을 제공할 수 있습니다.

️ Ref

https://www.cloudflare.com/ko-kr/learning/cloud/what-is-saas/

https://www.cloudflare.com/ko-kr/learning/cloud/what-is-the-cloud/

https://ko.wix.com/blog/post/software-as-a-service-saas

https://www.oracle.com/kr/applications/what-is-saas/

[Next.js] Next.js에 대해 알아보자

zenghyun — Tue, 17 Oct 2023 21:00:31 +0900

Next.js에 대해 알아보겠습니다. :)

‍ Next.js란?

Next.js는 React로 만드는 서버사이드 렌더링 프레임워크입니다. React는 클라이언트 사이드 렌더링을 수행하지만, Next.js는 서버 사이드 렌더링을 하게 됩니다.

기존의 클라이언트 사이드 렌더링에서는 아래와 같은 문제점이 있습니다.

1. 클라이언트 렌더링의 경우 사용자는 모든 js 파일이 로드된 후에 웹을 볼 수 있습니다. 만약, js 파일의 용량이 클 경우 사용자는 많은 시간을 대기해야 합니다.

2. SEO (검색 엔진 최적화) 문제가 있습니다. 클라이언트 사이드의 경우 js가 로드되지 않은 경우 아무런 정보를 볼 수 없습니다. 구글의 검색엔진의 경우 js가 로드되지 않은 페이지를 검색 엔진으로 스캔하기 때문에 검색에 아무 페이지도 나오지 않게 됩니다.

이 두 가지 문제를 해결할 수 있는 게 서버 사이드 렌더링입니다.

첫 번째 문제는 서버에서 js를 로딩하여 클라이언트 측에서는 js를 로딩하는 시간이 줄어들게 되고,

두 번째 문제는 검색 엔진이 js를 읽는 것이 아닌 서버 측에서 js, html, css를 만들어 콘텐츠를 직접 업로드하기 때문에 검색 엔진에 해당 웹 사이트가 노출될 수 있습니다.

또한 meta 태그를 자유롭게 추가하여 SEO를 용이하게 할 수 있습니다.

‍ Next.js의 주요 기능

Hot reloading

개발 중 저장되는 코드는 자동으로 갱신(새로고침)됩니다.

Automatic routing

pages 폴더에 있는 파일은 해당 파일 이름으로 라우팅 됩니다.

public 폴더도 pages의 폴더와 동일하게 라우팅 할 수 있습니다. 그러나 모든 사람이 페이지에 접근할 수 있기 때문에 지양해야 합니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
 |- /pages 
 |
 |-- index.js       => zenghyun.com/
 |-- about.js       => zenghyun.com/about
 |
 |
 |-- /products
 |  |
 |  |-- index.js      => zenghyun.com/products
 |  |-- [id].js       => zenghyun.com/products/1
 |
 |-- /clients 
    |
    |-- index.js      => zenghyun.com/clients
    |-- [id]          
        |
        |-- index.js                => zenghyun.com/client/zenghyun
        |-- [clientprojectid].js    => zenghyun.com/clients/zenghyun/project1
cs

Server side rendering

Server side rendering을 합니다. Client side rendering과 다르게 SSR을 한 페이지의 페이지 소스보기를 클릭하면 내부에서 소스를 볼 수 있습니다.

Code Splitting

dynamic import를 이용하면 손쉽게 코드 스플리팅이 가능합니다.

코드 스플리팅이란 내가 원하는 페이지에서 원하는 자바스크립트와 라이브러리를 렌더링 하는 것을 말합니다. 모든 번들 (chunk.js)이 하나로 묶이지 않고, 각각 나뉘어 좀 더 효율적으로 자바스크립트 로딩 시간을 개선할 수 있습니다.

React 18이후 React.lazy와 Suspense를 사용하면 CSR에서도 코드 스플리팅이 가능합니다.

손쉽게 사용 가능한 Typescript

타입스크립트 활용을 위해 웹팩을 다루거나 바벨을 만질 필요가 없습니다. 타입스크립트를 설치하고

$ typescript @types/node @types/react 
$ yarn run dev or npm run dev

만 터미널에 입력하면 tsconfig, next-end.d.ts가 생성되어 타입스크립트를 사용할 수 있습니다. :)

_document.tsx

meta 태그를 정의하거나, 전체 페이지에 관여하는 컴포넌트입니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
// pages/_document.tsx
import Document, { Html, Head, Main, NextScript } from "next/document";
export default class CustomDocument extends Document {
  render() {
    return (
      <Html>
        <Head>
         // 모든페이지에 아래 메타테크가 head에 들어갑니다.
          <meta property="custom" content="zenghyun" />
        </Head>
        <body>
          <Main />
        </body>
        <NextScript />
      </Html>
    );
  }
}
Colored by Color Scripter
cs

이곳에서 console을 사용하면 서버에서만 보이고 클라이언트에서는 볼 수 없습니다.
render 요소는 반영하지만 페이지 구성 요소만 반영되고 js는 반영하지 않기 때문에 console은 따로 보이지 않습니다. 즉, componentDidMount 같은 훅도 실행되지 않습니다.

_app.tsx

1
2
3
4
5
function MyApp({ Component, pageProps }) {
  return <Component {...pageProps} />;
}
 
export default MyApp;
cs

이곳에서 렌더링 하는 값은 모든 페이지에 영향을 주게 됩니다.
최초로 실행되는 파일이 _app.tsx이며, 클라이언트 보여줄 전체 컴포넌트를 나타낼 공통적인 레이아웃으로 최초 실행되며, 내부 컴포넌트들을 실행합니다.
내부에 컴포넌트가 있따면 전부 실행하고 html의 body로 구성됩니다.
Component와 pageProps를 인자로 받습니다.
- 여기서 props로 받은 Component는 요청한 페이지를 나타냅니다. GET / 요청을 보냈다면, Component에서는 /pages/index.js 파일이 props로 내려오게 됩니다.
- pageProps는 페이지 getInitialProps를 통해 내려받은 props들을 말합니다.
그 후에 _document.tsx가 실행됩니다.
페이지를 업데이트 하기 전에 원하는 방식으로 페이지를 업데이트하는 통로입니다.
_app.tsx에서 console.log 실행시 client, server 둘 다 콘솔에서 결과를 볼 수 있습니다.

Link 사용하기

페이지를 이동할 때 a 태그를 자주 사용하지만, React와 Next.js에서는 사용하지 않습니다.

a태그를 사용하게 되면 처음 페이지 진입 시 번들 파일을 받고, a 태그에 의해 라우팅 되면 다시 번들 파일을 받기 때문입니다. 또한 redux를 사용할 경우 store의 state 값이 사라지는 현상도 발생하게 됩니다. 그렇기 때문에 a 태그는 전혀 다른 사이트로 페이지를 이동시켜 다시 돌아오지 않을 경우에만 사용하고, 그 이외에는 모두 Link 태그를 사용합니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
import Link from "next/link";
 
const ClientsPage = () => {
  const clients = [
    { id: "zenghyun", name: "Zenghyun" },
    { id: "manuel", name: "Manuel" },
  ];
  return (
    <div>
      <h1>The Clients Page</h1>
      <ul>
        {clients.map((client) => (
          <li key={client.id}>
            {/*  아래처럼 작성하는 것은 하드코딩 */}
            {/* <Link href={`/clients/${client.id}`}>{client.name}</Link> */}
            {/* 아래와 같이 작성할 수도 있다. */}
            <Link
              href={{
                pathname: "/clients/[id]",
                query: { id: client.id },
              }}
            >
              {client.name}
            </Link>
          </li>
        ))}
      </ul>
    </div>
  );
};
 
export default ClientsPage;
 
Colored by Color Scripter
cs

Dynamic Route (url)

가변적으로 변하는 url에 대해 동적 url을 지원합니다. [] 문법을 통해 동적 페이지를 생성하는 동적 url을 만들 수 있습니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
// pages/[id].tsx
 
import { useRouter } from "next/router";
 
export default () => {
  const router = useRouter();
 
  return (
    <>
      <h1>post</h1>
      <p>postid: {router.query.id}</p>
    </>
  );
};
 
Colored by Color Scripter
cs

위의 코드처럼 작성하게 되면 localhost:3000/zenghyun 으로 접속 시 postId가 zenghyun이 됩니다.

pages/[값].tsx 왼쪽 페이지의 구조 값은 router.query.값 과 동일합니다.

Optional catch all routes

dynamic route를 사용하고 싶지 않을 때는 dynamic page를 optional 하게 주는 문법을 사용하면 됩니다.
[...page].tsx와 같은 형식으로 파일을 만들면 됩니다. [page].tsx 와 다른 점은 router.query.page 의 값이 배열로 담긴다는 것입니다.
예를 들어 page/test/[...page].tsx 가 경로일 때, url을 /test/1/2/3으로 들어왔다면 router.query.page의 값은 ['1', '2', '3']입니다.
router.query.page의 타입은 undefined, string, string []으로 페이지 변경에 따라 보여줄 컴포넌트가 다르다면 이 세 타입에 대한 조건을 모두 지정해야 합니다.

Prefetching

백그라운드에서 페이지를 미리 가져옵니다. 기본값은 true이며 <Link /> 뷰포트에 있는 모든 항목 (초기 또는 스크롤)이 미리 로드됩니다. 정적 생성을 사용하는 JSON 페이지는 더 빠른 페이지 전환을 위해 데이터가 포함된 파일을 미리 로드합니다.

예를 들어 Link 컴포넌트에서 <Link prefetch href="..."> 형식으로 prefetch 값을 전달해 주면 데이터를 먼저 불러온 후에 라우팅을 시작합니다.

next/router 사용하기

react의 react-router-dom과 사용 방법은 유사합니다.

link에 있는 prefetch 기능도 사용 가능합니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
import { useEffect } from "react";
import { useRouter } from "next/router";
import posts from "../posts.json";
 
const PostPage = () => {
  const router = useRouter();
 
  const post = posts[router.query.id as string];
  if (!post) return <p>noting</p>;
 
  useEffect(() => {
    router.prefetch("/test");
  }, []);
 
  return (
    <>
      <h1>{post.title}</h1>
      <h1>{post.content}</h1>
      <button onClick={() => router.push("test")}>go to Test</button>
    </>
  );
};
 
export default PostPage;
Colored by Color Scripter
cs

[React Query] React Query를 TypeScript로 사용할 때 Type 지정

zenghyun — Sat, 14 Oct 2023 14:29:06 +0900

React Query를 TS에서 사용할 때 Type은 어떻게 지정해야 할지 알아보겠습니다.

Start!

‍ React Query TypeScript

React Query는 TypeScript의 제네릭(Generics)을 많이 사용합니다. 이는 라이브러리가 실제로 데이터를 가져오지 않고 API가 반환하는 데이터 유형을 알 수 없기 때문입니다.

공식 문서에서는 타입스크립트를 그다지 광범위하게 다루지 않고, useQuery를 호출할 때 기대하는 제네릭을 명시적으로 지정할 수 있게 알려줍니다.

useQuery

현재 useQuery가 갖고 있는 제네릭은 4개이며, 다음과 같습니다.

TQueryFnData: useQuery로 실행하는 query function의 실행 결과의 타입을 지정하는 제네릭 타입입니다.
TError: query function의 error 형식을 정하는 제네릭 타입입니다.
TData: useQuery의 data에 담기는 실질적인 데이터의 타입을 말합니다. 첫 번째 제네릭과의 차이점은 select와 같이 query function의 반환 데이터를 추가 핸들링을 통해 반환하는 경우에 대응할 수 있는 타입이라고 생각하면 좋습니다.
TQueryKey: useQuery의 첫 번째 인자 queryKey의 타입을 명시적으로 지정해 주는 제네릭 타입입니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
// useQuery의 타입
export function useQuery<
TQueryFnData = unknown, 
TError = unknown,
TData = TQueryFnData,
TQueryKey extends QueryKey = QueryKey
>
 
// useQuery 타입 적용 예시 
const { data } = useQuery<
SuperHeros,
AxiosError,
SuperHeroName[],
[string, number]
>({
    queryKey: ["super-heros", id], 
    queryFn: getSuperHero,
    select: (data) => {
        const superHeroNames = data.data.map((hero) => hero.name);
        return superHeroNames;
    },
});
 
/**
 주요 타입
 * data: `SuperHeroName[]`
 * error: `AxiosError<any, any>`
 * select: `(data: SuperHeros): SuperHeroName[]`
 */
Colored by Color Scripter
cs

useMutation

useMutation도 useQuery와 동일하게 현재 4개이며, 다음과 같습니다.

TData: useMutation에 넘겨준 mutation function의 실행 결과의 타입을 지정하는 제네릭 타입입니다.
TError: useMutation에 넘겨준 mutation function의 error 형식을 정하는 제네릭 타입입니다.
TVariables: mutate 함수에 전달할 인자를 지정하는 제네릭 타입입니다.
1. onSuccess(2번째 인자), onError(2번째 인자), onMutation(1번째 인자), onSettled(3번째 인자) 인자의 타입으로 활용됩니다.
TContext: mutation function을 실행하기 전에 수행하는 onMutate 함수의 return값을 지정하는 제네릭 타입입니다.
1. onMutate의 결과 값의 타입을 onSuccess(3번째 인자), onError(3번째 인자), onSettled(4번째 인자)에서 활용하려면 해당 타입을 지정해야 합니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
// useMutation의 타입
export function useMutation<
    TData = unknown,
    TError = unknown,
    TVariables = void,
    TContext = unknown
> 
 
// useMutation의 타입 적용 예시 
const { mutate } = useMutation<Todo, AxiosError, number, number>(postTodo, {
    onSuccess: (res, id, nextId) => {},
    onError: (err, id, nextId) => {},
    onMutate: (id) => id + 1;
    onSettled: (res, err, id, nextId) => {}, 
}); 
 
const onClick = () => {
    mutate(5);
}; 
 
/*
    주요 타입
    data: 'Todo',
    error: 'AxiosError<any, any>'
    onSuccess: '(res: Todo, id: number, nextId: number)'
    onError: '(err: AxiosError, id: number, nextId: number)' 
    onMutate: '(id: number)'
    onSettled: '(res: Todo, err: AxiosError, id: number, nextId: number)',
*/
Colored by Color Scripter
cs

useInfiniteQuery

현재 useInfiniteQuery가 갖고 있는 제네릭은 4개이며, useQuery와 유사합니다.

TQueryFnData: useInfiniteQuery로 실행하는 query function의 실행 결과의 타입을 지정하는 제네릭 타입입니다.
TError: query function의 error 형식을 정하는 제네릭 타입입니다.
TData: useInfiniteQuery의 data에 담기는 실질적인 데이터의 타입을 말합니다. 첫 번째 제네릭과의 차이점은 select와 같이 query function의 반환 데이터를 추가 핸들링을 통해 반환하는 경우에 대응할 수 있는 타입이라고 생각하면 좋습니다.
TQueryKey: useInfiniteQuery의 첫 번째 인자 queryKey의 타입을 명시적으로 지정해 주는 제네릭 타입입니다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
// useInfiniteQuery의 타입
export function useInfiniteQuery<
    TQueryFnData = unknown,
    TError = unknown,
    TData = TQueryFnData,
    TQueryKey extends QueryKey = QueryKey 
>
 
// useInfiniteQuery 활용 
const fetchColors = async ({ pageParam }) => {
    const { page = 1, etc } = pageParam; 
 
    return await axios.get(`http://localhost:4000/colors?_limit=2&_page=${page}`);
};
 
const { mutate } = useInfiniteQuery<Colors, AxiosError, Colors, ["colors"]>(
    ["colors"],
    ({ pageParam = 0 }) => {
        fetchColors({ page: pageParam });
    },
    {
        getNextPageParam: (lastPage) => {
            return allPages.length < 4 && allPages.length + 1; 
        },
        ...options,
    }
);
 
/*
     주요 타입
    data: InfiniteData<ModeListResponse>
    error: AxiosError<any, any>
    select: InfiniteData<ModeListResponse>
    getNextPageParam: GetNextPageParamFunction<Colors> 
*/
Colored by Color Scripter
cs

️ REF

https://tanstack.com/query/v4/docs/react/typescript

https://www.youtube.com/watch?v=VtWkSCZX0Ec&list=PLC3y8-rFHvwjTELCrPrcZlo6blLBUspd2&index=3

[Vite] Vite에서 Proxy 설정하기 with Cross origin & CORS Error

zenghyun — Sat, 30 Sep 2023 16:19:50 +0900

Start!

‍ Cross origin이란?

크로스 오리진 (cross origin) 문제란 "브라우저는 자신의 오리진과 다른 오리진의 API 서버와 통신할 때 문제가 발생한다"는 개념입니다. 크로스 오리진 문제를 발생시킴으로써 잠재적인 위험을 가진 문서의 로딩을 제한해 브라우저 공격의 가능성을 줄일 수 있습니다.

크로스 오리진 문제는 웹 브라우저에 내장된 SOP(Same Origin Policy: 동일 근원 정책)라는 보안 정책 때문에 발생합니다. 크로스 오리진과 SOP를 이해하려면 브라우저의 오리진이라는 개념부터 이해해야 합니다.

브라우저가 웹 서버에 요청(request)을 전송하면 이에 대해 웹 서버는 응답(response)을 합니다. 일반적인 경우라면 웹 서버는 HTML 문서 형태를 응답할 것입니다.

오리진 (Origin)

URI 경로 중 "앞에서 포트 번호까지의 문자열"이 바로 오리진입니다.

https://velog.io/@jellyjw/Same-Origin-Policy-%EC%99%80-CORS

웹 브라우저는 HTML 문서를 제공한 웹 서버의 정보 (가장 앞에서부터 포트 번호까지의 문자열 정보)를 오리진으로 저장합니다. 즉, 오리진은 "HTML 문서를 내려받은 원천지는 이곳입니다"라는 뜻입니다.

동일 근원 정책 (Sam Origin Policy, SOP)

SOP는 "브라우저의 오리진과 동일한 오리진을 가진 서버일 때만 통신을 가능하게 한다"라는 의미를 가진 브라우저 내부의 보안 정책입니다. 반대로 말하면 동일 오리진이 아닌 다른 오리진, 즉 크로스 오리진일 때는 통신에 뭔가 문제가 발생한다는 것입니다.

‍ 크로스 오리진 발생 예시

이제 크로스 오리진이 발생하는 예시를 같이 보겠습니다.

1. 웹 브라우저는 프론트엔드 앱을 호스팅 하는 웹 서버 (http://localhost:3000)으로 index.html을 요청합니다.

2. 웹 서버로 응답받은 브라우저의 오리진은 "http://localhost:3000"의 문자열로 지정됩니다.

3. 이 오리진을 가진 브라우저가 자바스크립트 코드로 http://localhost:8000 오리진을 가진 백엔드 API 서버로 요청합니다.

4. 백엔드 API는 요청을 수신합니다.

5. 백엔드 API에서는 웹 브라우저로 보낼 데이터를 생성합니다.

6. 백엔드 API는 응답을 전송합니다.

7. 웹 서버가 백엔드 API 서버가 보낸 응답을 수신하고 로딩해야 하는데 에러가 발생합니다.

크로스 오리진 문제 해결 방법

크로스 오리진 문제는 크게 두 가지 해결 방법이 있습니다. 하나는 백엔드 API 서버 측에서 CORS(Cross Origin Resource Sharing)라는 기능을 제공해주는 방법이고, 또 한 가지는 프론트엔드 애플리케이션을 호스팅하는 웹 서버에 프록시(proxy)를 설정하는 방법입니다.

CORS

CORS는 백엔드 API 측에서 제공해주어야 하는 기능입니다. 간단하게 알아보면, CORS는 "크로스 오리진의 브라우저가 백엔드 API 서버로 요청했을 때 서버에서 Access-Control-Allow-Origin HTTP 헤더로 브라우저의 오리진을 응답하여 브라우저가 통신 및 데이터 로딩을 할 수 있도록 허용하는 방법"입니다.

아래 예시는 프론트엔드 애플리케이션을 호스팅 하는 서버 (이하 프론트 서버)에서 로딩한 HTML 문서의 자바스크립트 코드로 백엔드 API 서버와 직접 통신하는 것을 볼 수 있습니다. 요청 흐름을 간략하게 단계적으로 살펴보면 다음과 같습니다.

1. 브라우저는 프론트 서버에서 HTML 문서를 받아와 자신의 오리진을 설정합니다.

2. 자바스크립트 코드로 백엔드 API 서버에 요청합니다. 이때 자신의 오리진을 Origin HTTP 헤더에 추가합니다.

3. 백엔드 API 서버는 전송된 Origin 헤더를 읽어내어 등록된 리스트에 일치하는 것이 있는지 확인합니다.

4. 백엔드 API 서버는 Access-Control-Allow-Origin 응답 헤더를 추가하고, * 또는 브라우저의 오리진을 값으로 지정하여 응답합니다.

5. 브라우저는 자신의 오리진과 백엔드 API 서버로부터 전송받은 Access-Control-Allow-Origin 헤더가 일치하거나 *라면 응답이 허가된 것으로 간주하고 데이터를 로딩합니다.

만약 백엔드 API 서버에 대한 변경 권한을 가지고 있다면 이 방법을 사용하는 것이 좋습니다. :)

CORS에 대한 자세한 내용은 다음 모질라의 공식 문서를 확인하길 바랍니다.

https://developer.mozilla.org/ko/docs/Web/HTTP/Access_control_CORS

교차 출처 리소스 공유 (CORS) - HTTP | MDN

교차 출처 리소스 공유(Cross-Origin Resource Sharing, CORS)는 추가 HTTP 헤더를 사용하여, 한 출처에서 실행 중인 웹 애플리케이션이 다른 출처의 선택한 자원에 접근할 수 있는 권한을 부여하도록 브라

developer.mozilla.org

프록시를 이용한 우회

크로스 오리진 문제를 해결하는 방법 중 가장 쉬운 방법은 프록시를 이용한 방법입니다. 브라우저가 백엔드 API 서버와 직접 통신하는 것이 아니라 프론트엔드 애플리케이션을 호스팅하는 서버 (이하 프론트 서버)에 프록시를 설치하여 프론트 서버의 프록시를 거쳐서 백엔드 API와 통신하도록 하여 브라우저 측에서는 동일한 오리진과 통신하도록 하는 방법입니다.

프론트엔드 애플리케이션을 백엔드 API 서버에 호스팅하면 크로스 오리진 문제는 발생하지 않을 거야"라고 생각할 수도 있겠지만,

실제 운영 환경에서는 백엔드 API 서버와 프론트엔드 서버가 분리된 경우가 많다고 합니다. :)

적어도 개발 중에 npm run dev로 실행한 개발 서버는 백엔드 API 서버와 분리될 수밖에 없습니다.

따라서 프록시를 개발 서버와 다양한 운영 환경의 프론트엔드 호스팅 서버에 설정하는 방법을 알고 있어야 합니다.

‍ Vite에서 Proxy 설정하는 법 (vite.config.ts)

npm run dev 또는 npm run start로 실행되는 개발 서버에 프록시를 추가하도록 설정해보겠습니다.

Vite로 프로젝트를 생성한 경우에는 vite.config.ts에서 설정하면 됩니다.

(webpack 사용하면 webpack.config.ts에서 하면 됩니다!)

vite.config.ts

import { defineConfig } from 'vite'
import react from '@vitejs/plugin-react'

// https://vitejs.dev/config/
export default defineConfig({
	plugins: [react()],
    server: {
    	proxy: {
         "/api": {
         target: "http://localhost:8000",
         changeOrigin: true,
         rewrite: (path) => path.replace(/^\/api/, ""),
       },
     },  
   },
});

"/api"는 요청 경로가 /api로 시작하는 경우 target 경로로 전달하겠다는 것을 의미합니다.

/api/todolist/zenghyun과 같이 요청하면 http://localhost:8000 뒤에 요청 경로를 붙여서

http://localhost:8000/api/todolist/zenghyun으로 요청을 전달하는 것입니다.

만일 요청 경로를 바꾸고 싶으면 rewrite 속성을 추가해서 정규식을 이용해 경로를 변경하는 패턴을 등록하면 됩니다.

위에서는 최초 요청 경로에서 "/api" 부분을 찾아 빈 문자열로 변경, 즉 /api 문자열을 제거하고 나머지 부분만 경로로 덧붙여 요청을 전달한다는 뜻입니다.

최초 요청 경로: /api/todolist/zenghyun

타깃: http://localhost:8000

최종 전달 경로: http//localhost:8000/todolist/zenghyun

️ Ref

https://developer.mozilla.org/ko/docs/Web/HTTP/Access_control_CORS

https://velog.io/@jellyjw/Same-Origin-Policy-%EC%99%80-CORS

[면접 준비] React

zenghyun — Wed, 27 Sep 2023 22:17:20 +0900

Start!

‍ 라이브러리와 프레임워크의 차이를 알고 있나요?

라이브러리는 특정 기능 개발을 도와주는 도구들을 모아놓은 개념이고, 프레임워크는 프로그램을 개발하기 위한 구조를 제공하는 개념입니다.
프레임워크를 사용하면 개발에 대한 전체적인 기능을 제공하고, 프로그램 제어 흐름을 프레임워크에서 관리하는 차이점이 있습니다. 이런 특징을 제어의 역전이라고 합니다.

‍ React에 대해 설명해 주세요.

React는 UI를 만들기 위한 JavaScript 라이브러리입니다.

React는 스스로 상태를 관리하는 캡슐화된 컴포넌트를 조합해 복잡한 UI를 만들 수 있도록 지원하며, 데이터가 변경됨에 따라 적절한 컴포넌트만 효율적으로 갱신하고 렌더링 합니다.

‍ React의 원리, 특징이 무엇인가요?

React의 큰 특징으로는 Virtual DOM 개념과, 단방향 데이터 바인딩이 있습니다.

리액트는 단방향 데이터 플로우를 가지고 있습니다. 부모에서 자식 컴포넌트로 props를 전달하는 방식으로 작동합니다.
리액트는 가장 많은 사용자가 사용하는 라이브러리로, 생태계가 넓어서 많은 문서와 라이브러리가 존재합니다.
리액트는 컴포넌트라는 단위로 개발을 진행합니다. 독립적인 컴포넌트 단위로 나눠서 개발하고 관리하기 때문에 유지보수가 용이합니다. 그리고 반복되는 기능을 컴포넌트를 재사용하여 해결할 수 있습니다.
가상 돔(Virtual DOM)을 사용합니다. 리액트를 사용하면 메모리 상에 가상의 돔 오브젝트를 생성하고 관리합니다.

‍ 리액트는 어떻게 화면을 변경하나요?

리액트는 Virtual DOM이라는 개념을 통해 UI를 관리하고, 실제 DOM과 동기화해서 화면을 변경합니다.
조금 더 자세하게 설명드리면, 변경사항들을 메모리 상의 Virtual DOM에 먼저 적용하고, 바뀐 부분만 실제 DOM에 적용합니다.

가상 돔을 사용하는 이유가 있을까요?

자바스크립트 코드를 통해 화면을 나타내는 DOM을 수정하면 렌더링 과정 중 레이아웃이나 페인트 과정이 다시 발생하게 됩니다. 이 과정을 리플로우와 리페인트라고 합니다.
반응형 웹에서 이런 수정이 많이 발생해서 리플로우와 리페인트, 특히 리플로우 과정이 많이 발생하면 브라우저 성능이 떨어지게 됩니다.
그래서 리액트는 Virtual DOM에 변경 사항을 적용하고, 실제로 변경된 부분을 계산해서 DOM에 일괄로 적용하는 Batch Update를 적용해서 성능을 최적화했습니다.
그리고 개발자는 선언적으로 코드를 작성할 수 있습니다. 어떤 부분을 어떻게 실제 DOM에 적용하는지와 같은 과정을 Virtual DOM에게 위임할 수 있습니다.

리액트에서 가상 돔 작동 방식을 설명해 주세요.

리액트는 재조정이라는 과정을 통해 Virtual DOM을 이용해서 실제 DOM 을 조작합니다.

리액트는 항상 두 개의 Virtual DOM을 가지고 있습니다. 하나는 업데이트를 위한 Virtual DOM, 다른 하나는 업데이트가 되지 않은 Virtual DOM입니다.
일정 시간 동안 컴포넌트의 상태가 변경되면 변경사항을 업데이트를 위한 Virtual DOM 트리에 적용합니다.
- (참고) Virtual DOM에 변경사항을 적용하는 부분은 오래 걸리지 않습니다.
그리고 시간이 지나면 업데이트된 Virtual DOM과 업데이트 전의 Virtual DOM을 diffing 알고리즘을 사용해서 비교합니다.
diffing 알고리즘의 결과로 실제로 변경된 부분을 알 수 있고, 그 부분을 일괄적으로 실제 DOM에 적용합니다.
이렇게 Virtual DOM을 사용해 여러 개의 상태 변경을 일괄적으로 실제 DOM에 적용하는 것을 Batch Update라고 합니다.

리액트에서는 가상 돔의 변경점을 어떻게 알아내나요? (diffing 알고리즘)

리액트는 두 개의 가상돔을 가지고 있고, 업데이트된 가상돔과 업데이트 전 가상돔을 비교해서 변경사항을 찾고 있습니다.
모든 DOM 트리를 비교하는 알고리즘은 O(n^3) 시간이 들어서, 리액트에서는 특정 조건에서 휴리스틱한 O(n) 알고리즘을 사용합니다.
- 첫 번째 조건은 타입이 다른 Element는 다른 트리를 만든다는 가정이고, 두 번째 조건은 개발자가 key라는 Props를 통해 트리의 변경 사항을 알려준다는 가정입니다.
그래서 비교 과정에서 각 Virtual DOM 트리의 루트부터 비교를 시작하는데, 다른 Element로 변경됐을 경우 해당 서브트리를 제거하고 새로운 서브트리를 적용합니다.
만약 같은 Element 라면 className이나 다른 props 들을 비교하여 변경사항만 적용합니다.
그리고 이 과정을 재귀적으로 하위 Element에 대해 반복합니다.

fiber (파이버) 란 무엇인가요?

fiber는 리액트 가상 돔 변경 과정에서 발생하는 동시성, 애니메이션과 같은 문제점들을 해결하기 위해 적용한 알고리즘입니다.

‍ 컴포넌트의 key에 대해 설명해 주세요.

key 은 리액트에서 Element의 고유성을 부여하기 위한 값으로, 리액트에서 Element를 식별하고, 변경하거나 제거할 때 사용합니다.
그래서 Element 리스트를 표현할 때에는 각 Element 마다 항목을 고유하게 식별할 수 있는 id를 key로 전달하게 됩니다.
이렇게 전달된 key는 리액트에서 변경을 감지할 때 사용합니다. key가 없다면 자식 Element를 비교할 때, 하나라도 다르면 트리를 다시 구성해서 나쁜 성능을 보입니다.
하지만 key을 통해, key 값을 기준으로 추가되거나 삭제된 Element를 식별하고, 이를 기반으로 갱신합니다.
- (그래서 변경될 수 있는 index와 같은 값을 key로 사용하는 것보다는 고유한 id를 사용해야 합니다.)

‍ JSX에 대해 설명해 주세요.

JSX는 JavaScript를 확장한 문법으로, 공식문서에서 React와 함께 사용할 것을 권장하고 있는 문법입니다.

JSX는 JavaScript의 모든 기능이 포함되어 있으며, React Element를 생성하기 위해 사용됩니다.

리액트에서 JSX를 사용하면 어떤 장점이 있나요?

HTML 문법을 알고 있다면 UI 작업 시 더 직관적으로 코드를 이해할 수 있습니다.

그리고 리액트는 마크업 파일과 여러 가지 로직을 담고 있는 파일을 분리하지 않고 컴포넌트라는 개념으로 하나의 파일에 코드를 작성합니다. 그래서 높은 응집도의 코드를 작성할 수 있습니다.

리액트에서 JSX가 어떻게 작동하나요?

리액트에서 JSX는 리액트 라이브러리의 createElement를 Syntax Sugar 한 개념입니다.

JSX 문법이 적용된 코드는 babel을 통해 React.createElement라는 함수 호출로 변경됩니다.

React 가 직접 호출되지 않는데 import React를 해야 하는 이유를 알고 있나요?

리액트는 JSX라는 문법을 사용하는데, 리액트 17 이전에는 JSX 문법으로 작성된 코드를 babel을 통해 React.createElement라는 함수 호출로 변경했습니다.
그래서 JSX로 작성된 코드에서는 보이지 않지만, 실제로 실행할 때에는 React 가 import 되어야 합니다.
하지만 리액트 17 버전 이후부터는 babel에서 빌드 시점에 따로 처리해 주기 때문에 import 할 필요가 없게 되었습니다.

리액트에서 JSX 사용 시 주의해야 할 점이 있을까요?

컴포넌트를 JSX 문법으로 호출할 때, 컴포넌트 이름은 반드시 대문자로 시작해야 합니다.
- (이유) 왜냐하면 소문자로 시작하는 Element는 내장 컴포넌트로 인식합니다. 내장 컴포넌트는 createElement에서 ‘div’나 ‘span’ 같은 문자열 형태로 전달하고 처리하기 때문에 문제가 발생합니다.
그리고 HTML에서 Element의 속성으로 class 속성을 많이 사용하는데, JSX도 자바스크립트 문법을 확장한 문법이기 때문에 class라는 키워드를 사용할 수 없습니다. 대신에 className이라는 속성을 사용합니다. (추가적으로 몇몇 속성들도 camelCase를 사용해야 합니다.)

‍ 엘리먼트와 컴포넌트의 차이에 대해 설명해 주세요.

엘리먼트는 자바스크립트 객체고, 리액트로 화면을 그려내는 데에 가장 기본적인 요소입니다. 엘리먼트는 한 번 생성되면 다시는 변형되지 않습니다.

반면 컴포넌트는 엘리먼트를 반환하는 함수 혹은 클래스를 의미합니다.

재사용성을 강조하여, 엘리먼트를 좀 더 자유롭게 다룰 수 있으며, 컴포넌트의 이름을 사용하여 하나의 태그처럼 사용할 수 있습니다.

‍ 리액트에서 컴포넌트를 어떻게 생성하나요?

컴포넌트를 생성하는 방법으로는 함수형 컴포넌트와 클래스형 컴포넌트가 있습니다.

함수형 컴포넌트는 JavaScript 함수와 같은 방법으로 정의하며, 인자를 받아, React element를 반환하도록 만들 수 있습니다.

클래스형 컴포넌트는 ES6의 class를 사용하여 정의합니다. class안에서 render() 함수를 정의하고, 여기에서 React element를 반환하도록 만들 수 있습니다.

주의해야 할 점으로, 컴포넌트의 이름은 항상 대문자로 시작해야 합니다. React는 소문자로 시작하는 컴포넌트를 DOM 태그로 처리합니다. 이는 babel 컴파일을 진행할 때, 원시태그와 컴포넌트를 구분하기 위한 규칙으로, 지키지 않으면 에러가 발생합니다.

‍ 랜더링(SPA, SSR 등)

⭐️ ‍ SPA에 대해 설명해 주세요.

SPA는 싱글 페이지 애플리케이션의 약자로, 하나의 페이지로 이루어진 애플리케이션이라는 의미입니다.
전통적인 멀티 페이지 어플리케이션 방식은 페이지가 변경될 때마다 서버에서 새로운 HTML 파일을 응답받아서 표시하는 방식을 사용했습니다.
하지만 최근 클라이언트 환경의 성능이 높아져서 리액트와 같은 라이브러리를 통해 클라이언트가 뷰 구성을 담당할 수 있게 되었습니다. 그리고 AJAX 통신을 통해서 전체 페이지가 아닌 필요한 데이터에 대해서만 서버 API 호출을 통해서 받아오고, 그걸 적용해서 페이지 새로고침 없이 뷰를 수정할 수 있게 되었습니다.

Client Side Routing에 대해 설명해 주세요.

CSR은 렌더링이 클라이언트 단에서 일어나는 방식으로, 서버가 클라이언트에 HTML과 JS를 보내고, 클라이언트는 이를 받아 렌더링을 시작합니다.

일반적으로 다음과 같은 순서로 진행됩니다.

User가 웹사이트 요청을 보냅니다.
CDN이 HTML파일과 JS로 접근할 수 있는 링크를 클라이언트로 보냅니다.
클라이언트는 HTML과 JS를 다운로드합니다.
다운로드된 JS를 실행하고, 데이터를 위한 API가 호출됩니다.
서버가 API로부터의 요청에 응답합니다.
API로부터 받아온 데이터를 넣어줍니다. 이제 페이지가 상호작용해집니다.

SPA 특징과 장점을 설명해 주세요.

주로 싱글 페이지 애플리케이션은 클라이언트 사이드 렌더링 방식을 사용합니다.
처음 요청에 따라서 서버에서 HTML 파일과 함께 렌더링에 필요한 자바스크립트, CSS 파일을 받아옵니다. HTML 파일을 받아오고 나서 자바스크립트를 통해 돔을 수정하는 방식으로 작동합니다.
그래서 첫 페이지 로딩 이후에는 전체 페이지가 아닌 변경이 필요한 부분의 데이터만 서버와 통신하여 업데이트합니다. 그래서 로딩 이후 전체적인 트래픽을 줄일 수 있고, 인터렉티브 한 사용자 경험을 제공할 수 있습니다.
그리고 부분적으로 업데이트하는 방식이기 때문에 컴포넌트별 개발 방식과 잘 맞습니다.

SPA 단점을 설명해 주세요.

싱글 페이지 애플리케이션은 처음 요청 시에 서버에서 렌더링 로직을 포함한 HTML, 자바스크립트, CSS 파일을 모두 가져옵니다. 많은 리소스를 한 번에 받아와야 하기 때문에 처음 로딩 속도가 상대적으로 느립니다.
그리고 검색엔진 최적화 이슈가 발생할 수 있습니다. 일반적으로 싱글 페이지 애플리케이션은 클라이언트 사이드 렌더링 방식을 사용하는 경우가 많습니다. 그래서 구글 크롤러 봇처럼 자바스크립트를 실행할 수 있는 봇이 아니면, 아직 렌더링 되지 않은 비어있는 HTML을 크롤링하는 문제가 발생할 수 있습니다.

SEO(검색엔진최적화)가 뭔가요?

구글과 같은 사이트의 검색 엔진들이 서버에 등록된 사이트를 돌아다니면서 문서를 분석합니다. 분석한 데이터로 검색 결과를 표시하게 되는데, 이때 콘텐츠에 포함된 정보를 검색엔진이 잘 수집할 수 있도록 하는 게 검색엔진 최적화입니다.

클라이언트 사이드 렌더링에서 검색엔진 최적화 이슈가 발생하는 이유가 있나요?

클라이언트 사이드 렌더링으로 작성된 사이트들은 일반적으로 처음 접속하면 body가 비어있는 HTML 파일을 받아오고, 자바스크립트를 통해 동적으로 콘텐츠를 렌더링 합니다.
검색엔진의 봇은 사이트를 돌아다니면서 HTML 문서 정보를 수집하는데, 싱글 페이지 애플리케이션에서는 body가 비어있는 HTML 문서를 수집하게 됩니다.
구글의 봇은 자바스크립트를 실행하여 수집할 수 있지만, 대부분의 봇들은 싱글 페이지 애플리케이션의 비어있는 문서를 수집하기 때문에 검색엔진 최적화가 잘 되지 않습니다.

검색엔진 최적화를 할 수 있는 방법을 설명해 주세요.

서버 사이드 렌더링을 적용하는 방법이 있습니다. 서버 사이드 렌더링은 서버에서 HTML문서를 만들어서 응답하기 때문에 사용자도, 검색엔진도 완성된 HTML 파일을 응답받기 때문입니다.
클라이언트 사이드 렌더링을 사용한다면, 사전 렌더링 방식을 적용할 수 있습니다. 검색 엔진이 빈 HTML 파일 대신 내용이 포함된 HTML을 가져갈 수 있도록 빌드타임에 데이터가 포함된 HTML 파일을 생성하는 방식을 사용할 수 있습니다.
그리고 제목이나 헤드 태그 등 HTML 파일에 문서 정보를 잘 나타낼 수 있도록 설정해야 합니다.

‍ TTV, TTI를 알고 있나요? (time-to-view, time-to-interect)

TTV는 타임 투 뷰의 약자로, 콘텐츠가 화면에 보이는 시점이고, TTI는 타임 투 인터렉트로 사용자와 상호작용이 가능한 시점을 의미합니다.
클라이언트 사이드 렌더링을 사용하면 TTV와 TTI가 동일합니다. 왜냐하면 서버에서 빈 HTML 파일을 받아오고, 자바스크립트 파일도 모두 가져온 이후에 렌더링 하기 때문에 보이는 시점과 상호작용 하는 시점이 동일합니다.
하지만 서버 사이드 렌더링을 사용하면 TTV가 TTI보다 더 빠릅니다. 왜냐하면 서버에서 완성된 HTML 파일을 받아오면 콘텐츠가 화면에 먼저 보이게 됩니다. 그리고 나서 서버에 인터렉션을 위한 자바스크립트를 요청하게 되고, 응답받게 되면 그때부터 실제로 상호작용이 가능합니다.

⭐️ ‍ State에 대해 설명해 주세요.

State는 컴포넌트 내부적으로 관리하는 동적인 데이터입니다. 그리고 리액트에서 state가 변경되면 해당 컴포넌트가 다시 렌더링 됩니다.

React에서 State를 어떻게 관리하나요?

배열을 사용하여 관리하고, 해당 배열의 인덱스와 state 값을 클로저 내에 관리하여 useState() 함수가 반환되고 나서도, 별도의 메모리 공간에 값들을 저장합니다.

왜 state를 직접 바꾸지 않고 setState를 사용해야 하나요?

state는 일반적인 변수와 다르게 값이 변하면 리렌더링이 발생합니다. 즉, 값이 변하게 되면, 연관되어 있는 컴포넌트들이 다시 렌더링이 되어 화면이 바뀌게 됩니다.

그런데, React는 setState 호출에 의한 state의 주소 변경에만 반응하여 리렌더링이 발생하게 됩니다. 즉, 이런 방식으로 변경하지 않으면 React가 감지하지 못합니다.

리액트 state의 불변성에 대해 설명해 주세요.

불변성은 값이나 상태를 변경할 수 없는 특성을 의미합니다. 이때 변경은 값이 아닌 메모리 영역에서의 변경을 의미합니다.
리액트에서는 상태가 변경되면 다시 렌더링 되는데, 이 변경을 얕은 비교를 통해 수행합니다.
즉 값 하나하나를 비교하는 것이 아니라, 이전 참조값과 현재 참조값을 비교하는 방식으로 변화를 감지합니다.
그래서 상태를 업데이트할 때, 객체 그대로 업데이트하는 대신 의도적으로 스프레드 연산자 등을 통해 값은 같아도 새로운 참조 값을 가진 객체를 전달하는 방식으로 불변성을 유지할 수 있습니다.

React에서 State의 불변성은 어떻게 유지할 수 있나요?

기본적으로 useState를 사용합니다. 만약, state값이 객체인 경우, useState를 통해 상태값을 업데이트할 때, spread 연산자인... 을 이용하여, 깊은 복사를 진행해주어야 합니다.

만약 객체나 배열의 내부가 중첩되어 있다면, immer 라이브러리를 사용하여, 불변성을 유지할 수 있습니다.

⭐️ ‍ Props에 대해 설명해 주세요.

props는 단방향 바인딩을 지원하는 리액트에서 부모 컴포넌트에서 자식 컴포넌트로 내려주는 데이터입니다.

⭐️ ‍ Props Drilling에 대해 설명해 주세요.

리액트는 데이터를 전달할 때 부모 컴포넌트에서 자식 컴포넌트로 Props를 통해 단방향으로 전달합니다.

이런 특성으로 인해 컴포넌트의 계층이 깊어지면, 상위 컴포넌트에서 하위 컴포넌트로 어떤 props를 전달하기 위해서 중간에 props를 전달하기 위한 컴포넌트가 생길 수 있습니다.

이러한 전달 방식을 Props Drilling이라고 합니다.

Props Drilling을 어떻게 해결할 수 있나요?

리액트 자체적으로 제공하는 Context API를 사용할 수 있고, 아니면 Redux 같은 서드파티 상태관리 라이브러리를 사용할 수도 있습니다.

‍ 컴포넌트는 언제 다시 렌더링 되나요?

다시 호출되면서 props가 변경될 때
컴포넌트 내부의 state가 변경될 때
부모 컴포넌트가 다시 렌더링 될 때

‍ 데이터를 자식에서 부모로도 전달할 수 있나요?

props로 부모 컴포넌트의 상태를 변경하는 함수를 전달하고, 자식 컴포넌트에서 props로 넘겨받은 함수를 호출해서 부모 컴포넌트의 상태를 변경할 수 있습니다.

‍ Props와 State의 차이에 대해 설명해 주세요.

React legacy 공식문서에 의하면, props는 함수 매개변수처럼 컴포넌트에 전달되는 반면 state는 함수 내에 선언된 변수처럼 컴포넌트 안에서 관리됩니다.

‍ React에서 상태 변화가 생겼을 때, 변화를 어떻게 알아채는지에 대해 설명해 주세요.

React는 state를 immutable 하게 관리합니다. 그렇기 때문에 state가 변경되면, state의 주소값이 변경되게 되고, 이 변화를 알아채게 됩니다.

이것이, state가 배열의 형태로 존재할 때, 배열에 원소를 .push()를 이용해 추가하더라도, state 변화를 알아채지 못하는 이유입니다.

‍ HTML과 React의 이벤트 처리 차이점에 대해 설명해 주세요.

먼저 문법의 차이가 있습니다.

HTML은 전달할 함수를 문자열의 형태로 전달하지만, React는 함수 그 자체로 핸들러를 전달합니다.

또한 HTML은 이벤트를 소문자로 갖지만, React는 camelCase를 사용합니다. (ex. onClick)

다른 차이점으로는, HTML에서 false를 반환하는 식으로 이벤트의 기본동작을 방지하지만, React에서는 preventDefault를 명시적으로 호출하여 이벤트의 기본동작을 막아야 합니다.

‍ Hook

‍ 훅이란 무엇인가요? (훅 종류에는 어떤 게 있나요?)

리액트 16.8 버전에서 추가된 기능으로, 함수 컴포넌트에서 상태 관리를 포함한 클래스 컴포넌트의 여러 기능을 처리할 수 있도록 하는 기능입니다.
훅 등장 이전에는 함수 컴포넌트에서 상태를 관리할 수 없어서 상태 관련된 로직을 재사용하기 어려웠습니다. 그리고 라이프사이클 메서드를 사용할 수 없어서 복잡한 로직을 처리할 수 없었습니다.
리액트 훅을 통해 함수 컴포넌트에서 상태와 라이프사이클을 후킹할 수 있게 되었습니다.
훅의 종류에는 사용자가 직접 정의하는 커스텀 훅과, 리액트에서 제공하는 훅이 있습니다.
대표적인 리액트의 훅에는 useState, useEffect, useReducer, useContext, useRef, useMemo, useCallback 등이 있습니다.

‍ useState 훅을 설명해 주세요.

useState는 리액트 훅 중에서 가장 기본적인 훅으로, 상태를 관리하기 위한 훅입니다.
useState의 파라미터로 상태의 초기값을 전달할 수 있고, 첫 번째 반환값으로 상태, 두 번째 반환값으로 상태를 업데이트하는 함수를 반환합니다.
useState로 생성한 상태값을 함수로 변경하면 상태 값이 변경되고, 해당 상태를 가지고 있는 컴포넌트가 다시 렌더링 됩니다.

useState는 동기적인가요? 비동기적인가요? 그 이유를 설명해 주세요.

useState는 비동기적으로 작동합니다.

리액트에서 state는 변경될 때마다 다시 렌더링이 발생합니다. 만약 상태 변경이 동기적으로 작동한다면 하나의 상태가 변경될 때마다 다시 렌더링이 발생할 수 있습니다.
useState는 비동기적으로 작동합니다. 리액트에서는 state batch update라는 이름으로, 일정 기간 동안 변경된 상태를 실제 DOM에 일괄적으로 업데이트합니다. 리액트는 이를 통해 렌더링 횟수를 줄여서 성능을 최적화해 줍니다.

왜 비동기적으로 동작하나요?

그 이유는 리액트의 리렌더링 원리가 비동기적으로 작동하기 때문입니다.

그리고 그 이유는 리액트가 가상돔을 사용하도록 설계되어 있기 때문입니다.

이는 리액트의 Fiber와 밀접한 관련이 있습니다.

fiber architecture는 재조정 알고리즘을 구현할 때, 변경된 부분을 찾고, 실제 돔에 변경사항하는 작업을 나누어 진행합니다.

그런데, 이 과정을 동기적으로 진행한다면, 메인스레드가 차단되고, 이는 프레임 드롭이나 응답지연으로 이어지기 때문에 UX를 저해하게 됩니다.

‍ useEffect 훅을 설명해 주세요.

useEffect는 특정한 상황에서 사이드 이펙트를 실행시킬 수 있는 훅입니다.
useEffect의 첫 번째 파라미터에는 사이드 이펙트를 실행할 콜백함수, 두 번째 파라미터에는 배열을 입력합니다.
이펙트 함수는 렌더링 이후 실행되는 함수면서, 만약 이펙트 함수의 반환값으로 콜백 함수가 있다면 컴포넌트가 원마운트 될 때 실행됩니다. 이때 실행되는 콜백 함수를 클린업 함수라고 합니다.
두 번째 파라미터로 전달된 배열은 의존성 배열이라고 부르면서 렌더링 될 때뿐만 아니라 배열 내의 값 중 하나라도 업데이트가 되면 이펙트 함수가 실행됩니다.
useEffect 훅을 적절히 사용하면 클래스 컴포넌트에서 사용하는 생명주기 메서드와 비슷한 기능을 구현할 수 있습니다.

‍ useLayoutEffect 훅을 설명해 주세요.

useEffect 훅은 브라우저가 화면을 페인트 한 후 실행됩니다. 그래서 useEffect 훅을 통해 화면에 표시할 값을 변경할 경우 처음 그려진 화면이 먼저 표시되고, 그 이후에 한번 더 화면이 바뀌게 됩니다.
useLayoutEffect는 useEffect 훅과 다르게 리액트 돔이 업데이트된 직후 실행돼서 브라우저가 페인팅되기 전에 실행됩니다. useEffect 훅을 사용했을 때 발생하는 약간의 문제점을 해결할 수 있습니다.

‍ useEffect와 useLayoutEffect의 차이점에 대해 설명해 주세요.

제일 큰 차이점은 useEffect는 비동기적으로 동작하고, useLayoutEffect는 동기적으로 동작한다는 것입니다.

리액트에서 useEffect는 렌더링이 끝나고 특정 행동을 수행하고, useLayoutEffect는 렌더링 전에 특정 행동을 수행합니다.

따라서 성능 모니터링이나 애니메이션 구현 등 즉시 반응이 필요한 경우에 useLayoutEffect를 사용하고, 네트워크 요청, DOM 접근, 비동기 작업을 하는 경우에는 useEffect를 사용하는 것이 좋습니다.

‍ useReducer 훅을 설명해 주세요.

먼저 reducer는 현재 상태와 액션 객체를 파라미터로 받아와서 다음 상태를 반환하는 순수 함수입니다.
useReducer 함수는 파라미터로 그런 리듀서함수와 초기 상태값을 입력합니다.
그리고 첫 번째 반환값으로 상태 객체, 두 번째 반환값으로 디스패쳐 함수를 반환합니다.
반환된 디스패쳐 함수에 정의한 액션 타입에 맞는 객체를 전달해서 상태를 변경시킬 수 있습니다.
useReducer 훅을 이용하면 상태를 정의하고, 상태를 업데이트하는 복잡한 로직을 조금 더 효율적으로 관리할 수 있습니다.

‍ useContext 훅을 설명해 주세요.

Context API는 리액트에서 일반적인 props를 통한 전달 대신에 전역적으로 값을 공유할 수 있도록 제공하는 기능입니다.
React.createContext 함수를 통해 공유할 콘텍스트 객체를 생성하고, 콘텍스트 객체의 Provider 컴포넌트를 이용해 하위 컴포넌트에 콘텍스트의 변화를 알릴 수 있습니다.
useContext는 이렇게 생성된 콘텍스트를 함수형 컴포넌트에서 사용하는 훅입니다.

Context API는 어디에 사용되나요?

데이터를 공유할 때 사용합니다. 대표적으로 프로그램 전체에서 사용하는 테마 정보를 공유할 수 있습니다.

Context API를 상태관리 라이브러리처럼 사용할 수 있나요?

결과적으로 사용은 가능합니다.

하지만 상태관리를 위해 사용했을 때 렌더링 이슈가 발생할 수 있습니다.
Context API는 상태관리를 위한 도구가 아니라 단순히 공유를 위한 도구입니다. 그래서 useState 훅 등으로 따로 공유할 상태를 설정하게 됩니다.
이렇게 상태를 관리하면, 다른 상태관리 라이브러리와는 다르게 상태가 변경되면 Provider로 감싸진 컴포넌트의 재렌더링이 발생하게 됩니다.
그래서 상태를 사용하지 않더라도 다시 렌더링이 발생하는 이슈가 있습니다.

‍ useRef 훅을 설명해 주세요.

리액트에서 돔을 조작하는 방식과 다르게, ref는 돔 요소에 직접 접근하는 객체입니다.
useRef 훅을 사용하면 querySelector와 같은 방식으로 접근할 수 있는 ref 오브젝트를 반환합니다.
ref 오브젝트는 일종의 참조값이고, ref.current라는 속성에 실제로 값을 저장할 수 있습니다.
ref 에는 특정 값을 저장할 수도 있고, 필요에 따라 돔 요소의 ref 속성으로 전달하여 해당 돔 요소를 직접 접근할 수 있습니다.

‍ 제어 컴포넌트와 비제어 컴포넌트에 대해 설명해 주세요.

제어 컴포넌트는 리액트 안에서 state 등으로 렌더링과 같은 부분을 관리하는 컴포넌트를 의미합니다.
비제어 컴포넌트는 리액트가 아닌 자바스크립트를 이용하여 관리하는 컴포넌트로, ref를 이용해서 값을 참조하여 관리합니다.

‍ ref에 대해 알고 있나요?

ref는 컴포넌트 라이프사이클과 별개로 유지되는 오브젝트입니다. 일반적으로 DOM Element에 직접 접근해서 조작할 때 사용합니다.
생성된 ref는 힙 메모리에 자바스크립트 객체로 저장되고, 매번 렌더링 때마다 생성된 동일한 객체를 반환합니다. 그리고 객체 내부의 current 값이 변경되더라도 컴포넌트를 재렌더링 시키지 않는다는 특징이 있습니다.

ref는 언제, 어떻게 사용하나요?

ref 오브젝트는 createRef 나 useRef를 호출해서 생성할 수 있습니다.
이렇게 생성한 ref 오브젝트를 JSX로 표현한 Element의 ref 속성에 할당해서 그 Element를 참조할 수 있습니다.
대표적으로 컴포넌트가 렌더링 될 때 input 태그에 focus가 되도록 하거나, 미디어 재생을 조작하거나 하는 부분에서 사용할 수 있습니다.

callback ref에 대해 알고 있나요?

Element의 ref 속성에는 두 가지 타입을 입력할 수 있습니다. 하나는 RefObject 타입이고, 다른 하나가 RefCallback 타입입니다.
callback ref는 RefCallback 타입으로, ref 객체가 아닌 함수를 전달하는 방식입니다.
node라고 하는 Element를 파라미터로 받아서 실행되는 함수로, 컴포넌트가 렌더링 된 후에 실행됩니다.
- node 파라미터에는 callback ref를 등록한 그 Element 가 전달됩니다.
- (DOM Element가 렌더링 후에 상호작용 해야 하는 경우 사용합니다.)

forwardRef에 대해 알고 있나요?

forwardRef는 ref를 컴포넌트 간 전달하기 위해 사용합니다.
이때 리액트에서 ref는 key와 마찬가지로 props 가 아닌 다른 용도로 전달되도록 설정되어 있습니다.
그래서 하위 컴포넌트의 props에서 전달받은 ref를 참조할 수 없습니다.
이때 하위 컴포넌트를 forwardRef 함수로 감싸게 되면, 부모 컴포넌트에서 전달한 ref를 하위 컴포넌트에서 참조할 수 있습니다.

‍ 메모이제이션에 대해 설명해 주세요.

메모이제이션이란 계산된 값을 자료구조에 저장하고 이후 같은 계산을 반복하지 않고 자료구조에서 꺼내 재사용하는 것을 말합니다.

‍ useMemo 훅을 설명해 주세요.

useMemo 훅은 말 그대로 이전에 저장된 값을 메모이제이션 하는 훅입니다.
useMemo 훅의 첫 번째 파라미터로 콜백 함수, 두 번째 파라미터로 배열을 저장합니다.
콜백 함수에서는 실제로 저장할 값을 계산하는 로직을 포함합니다.
useEffect의 의존성 배열과 마찬가지로 useMemo의 두 번째 파라미터인 의존성 배열에 포함된 값이 업데이트될 때마다 해당 콜백 함수를 다시 실행해서 값을 업데이트합니다.
useMemo를 적절히 활용하면 오래 걸리는 복잡한 연산의 결괏값을 저장해 놓고 사용해서 최적화를 할 수 있습니다.

React.memo와 useMemo의 차이에 대해 설명해 주세요.

React.memo는 HOC이고, useMemo는 훅입니다.

React.memo는 컴포넌트 자체를 메모이제이션한 용도로 사용하고, useMemo는 복잡한 계산의 결과 값을 메모이제이션하는 용도로 사용합니다. 물론 컴포넌트도 넣을 수는 있습니다.

HOC (Higher-Order Components)

고차 컴포넌트는 컴포넌트를 인자로 받아 새로운 컴포넌트를 다시 return해주는 함수입니다.

‍ useCallback 훅을 설명해 주세요.

useCallback 훅은 useMemo 훅과 비슷한 기능으로, 함수를 메모이제이션 하는 훅입니다.
useCallback 훅도 첫 번째 파라미터로 저장할 콜백 함수, 두 번째 파라미터로 배열을 저장합니다.
두 번째 파라미터로 제공된 의존성 배열에 포함된 값이 변경될 때마다 콜백 함수를 다시 생성합니다.

‍ 리액트에서 성능 개선을 하는 방법을 설명해 주세요.

첫 번째는 useMemo, useCallback으로 시간이 오래 걸리는 계산 결과를 메모이제이션하는 방법이 있습니다.
두 번째로는 코드 스플리팅 방식이 있습니다. 리액트를 사용한 자바스크립트 코드를 하나로 묶어서 빌드하면 굉장히 크기가 크기 때문에 페이지를 로딩하는 속도가 느려지게 됩니다. 이를 해결하기 위해서 다이나믹 import를 사용하거나, React.Lazy를 사용해 컴포넌트를 비동기적으로 로딩할 수 있습니다. 또는 Next.js 프레임워크를 사용하면 프레임워크에서 코드 스플리팅을 지원합니다.

useMemo와 useCallback 훅의 공통점과 차이점을 설명해 주세요.

가장 큰 차이는 useMemo는 값을, useCallback은 함수를 저장한다는 점입니다.
하지만 둘 다 기존에 저장하던 값을 계속 저장하면서 렌더링마다 다시 계산해야 하는 불필요한 과정을 최적화할 수 있습니다.
그리고 useCallback은 단순히 useMemo 콜백 함수에 콜백 함수를 저장하는 것과 동일한 기능을 합니다.

React.lazy와 Suspense 컴포넌트가 뭔가요?

React.lazy

SPA는 index.html 파일 하나와 다수의 자바스크립트 코드, 그리고 CSS 파일로 구성됩니다. 이러한 구성 때문에 SPA는 약간의 문제점이 있습니다. 리액트 라우터를 적용한 수백에서 수천 개의 화면과 컴포넌트로 구성된 애플리케이션에서 파일들은 모두 빌드 과정을 거쳐서 하나 또는 몇 개의 .js 파일로 빌드됩니다. 빌드된 파일은 모든 컴포넌트를 묶은 것이므로 파일의 크기도 클 것입니다.

첫 화면을 로딩하는 과정을 간단하게 설명드리겠습니다.

사용자는 / 경로로 웹 서버에 요청 정보를 전송합니다.
웹 서버는 index.html과 필요한 모든 산출물(.js 포함)을 브라우저로 응답합니다.
브라우저에서는 / 경로의 첫 화면만 렌더링합니다.
만약, 다른 경로로 내비게이션하더라도 웹 서버에 요청하지 않습니다. 이미 다운로드한 .js 파일의 컴포넌트를 이용해 브라우저에서 렌더링합니다.

브라우저는 첫 화면을 로딩하기 위해 첫 화면뿐만 아니라 모든 화면을 위한 .js 파일을 로딩합니다. 이때 지연 시간이 발생해서 사용자는 첫 화면을 보기까지 기다리는 시간이 길어질 수 있습니다. 이때 사용하는 기법이 레이지 로딩 기법입니다.

레이지 로딩은 리액트 애플리케이션의 수많은 화면과 컴포넌트를 적절히 구분하여 화면, 컴포넌트 그룹 단위로 여러 개의 청크(chunk)라 부르는 .js 파일로 빌드하고 특정 컴포넌트가 필요한 시점에 서버에 요청해서 청크 파일을 응답받아 렌더링하는 방법입니다.

즉, 레이지 로딩 기법의 핵심은 특정 화면이 필요할 때 관련된 컴포넌트를 포함하고 있는 .js 파일을 웹 서버에 요청하여 받아오는 것입니다.

이 방법을 사용하면 애플리케이션이 수많은 컴포넌트를 포함하더라도 첫 화면을 요청할 때는 작은 크기의 청크 파일을 요청하고 응답받으므로 사용자에게 첫 화면을 더 신속하게 보여 줄 수 있습니다.

Suspense 컴포넌트

청크 파일을 필요할 때 로딩하다 보면 실행 중에 약간의 지연 시간이 발생할 수 있습니다. 지연 시간이 길어진다면 사용자에게 로딩 중임을 나타내는 화면을 보여주는 것이 좋습니다. 이런 화면을 fallback UI라고 부르며 이 기능을 손쉽게 구현할 수 있도록 도와주는 컴포넌트가 Suspense 컴포넌트입니다.

‍ Hook 라이프사이클

‍ 클래스형 컴포넌트를 사용해 보셨나요?

아니요 ㅎ

‍ 클래스형 컴포넌트와 함수형 컴포넌트의 차이에 대해 설명해 주세요.

클래스형 컴포넌트는 LifeCycle API를 제공하나, 함수형 컴포넌트는 기본적으로는 제공되지 않습니다. (Hook을 사용하면 사용할 수 있습니다.)

반면, 함수형 컴포넌트는 메모리 자원을 클래스형 컴포넌트보다 덜 사용하며, 빌드한 결과물의 크기 역시 클래스형 컴포넌트보다 적습니다.

React 공식문서에서 클래스형 컴포넌트로 선언하는 방법을 아예 Legacy API로 분류해 놓을 정도로 함수형 컴포넌트는 강력합니다.

⭐️ ‍ 라이프사이클에 대해 설명해 주세요.

모든 리액트 컴포넌트에는 라이프 사이클이 있으며, 컴포넌트는 마운트 -> 업데이트 -> 언마운트의 라이프사이클을 갖습니다.

마운트는 컴포넌트가 생성되는 시점을 의미하며, constructor -> getDerivedStateFromProps -> render -> componentDidMount의 순서로 호출됩니다.

업데이트는 컴포넌트가 업데이트되는 시점을 의미하며, getDerivedStateFromProps -> shouldComponentUpdate -> render -> getSnapshotBeforeUpdate -> componentDidUpdate 순서로 호출됩니다.

언마운트는 컴포넌트가 화면에서 사라지는 시점을 의미하며, 컴포넌트가 화면에서 사라지기 직전에 componentWillUnmount 가 호출됩니다.

라이프 사이클 메서드에 대해 설명해 주세요.

getDerivedStateFromProps: props로 받아온 것을 state로 넣어주고 싶을 때 사용합니다.

componentDidMount: 컴포넌트의 첫 번째 렌더링이 마치고 나면 호출되는 메서드로, 이 메서드가 호출되는 시점에는 우리가 만든 컴포넌트가 화면에 나타난 상태입니다.

shouldComponentUpdate: 컴포넌트가 리렌더링 할지 말지를 결정하는 메서드로 주로 최적화를 할 때 사용하는 메서드입니다.

getSnapshotBeforeUpdate: 컴포넌트에 변화가 일어나기 직전의 DOM 상태를 가져와서 특정 값을 반환하면, 그다음 발생하게 되는 componentDidUpdate에서 받아와 사용할 수 있습니다.

componentDidUpdate: 리렌더링을 마치고, 화면에 우리가 원하는 변화가 모두 반영되고 난 뒤 호출되는 메서드입니다. 3번째 파라미터로 getSnapshotBeforeUpdate에서 반환한 값을 조회할 수 있습니다.

componentWillUnmount: 컴포넌트가 화면에서 사라지기 직전에 호출되는 메서드입니다.

클래스 컴포넌트와 함수 컴포넌트를 비교하면서 설명해 주세요.

클래스 컴포넌트

컴포넌트는 크게 마운트, 업데이트, 언마운트 주기를 가집니다.
마운트 단계는 컴포넌트가 처음 실행될 때를 의미합니다. 컴포넌트의 상태를 초기화하고, 컴포넌트가 돔에 설정되어 브라우저에 보이는 구간입니다.
다음으로 업데이트는 props나 state가 변경되었을 때, 부모 컴포넌트가 다시 렌더링 될 때, forceUpdate 메서드를 통해 강제로 렌더링을 트리거할 때나, componentDidUpdate 메서드를 통해 업데이트 이후 컴포넌트가 추가로 업데이트됩니다.
마지막으로 언마운트 과정을 통해 컴포넌트를 DOM에서 제거합니다.

함수 컴포넌트

함수 컴포넌트는 호출되었을 때 함수 내부가 먼저 실행됩니다.
이후 함수의 반환값으로 반환하는 HTML과 컴포넌트들을 화면에 렌더링 합니다.
이후 생명주기는 useEffect 훅을 통해 관리할 수 있습니다.
렌더링 되면 useEffect가 마운팅 되면서 실행되고, 조건에 따라 useEffect를 통해 업데이트합니다.
컴포넌트가 언마운트 될 때에는, 컴포넌트가 제거되기 전에 useEffect의 clean up 함수를 호출하게 됩니다.
이후 DOM에서 컴포넌트를 제거합니다.

componentDidMount, componentDidUpdate 등 클래스 컴포넌트에서 사용되던 생명주기 메서드를 함수 컴포넌트에서는 어떻게 구현하나요?

useEffect 훅을 통해 구현할 수 있습니다.
useEffect는 사용에 따라 컴포넌트가 마운트 되었을 때, 컴포넌트의 특정 상태가 업데이트될 때, 컴포넌트가 제거될 때 모두 처리할 수 있습니다.
왜냐하면 useEffect 훅은 의존성이 변경될 때마다 등록된 effect 함수를 실행하는 훅입니다.
의존성에 변경을 감지할 상태나 props를 등록하면 componentDidUpdate, getDerivedStateFromProps처럼 사용할 수 있습니다.
그리고 의존성에 빈 배열을 등록하면 처음 마운트 되었을 때 실행되는 componentDidMount처럼 사용할 수 있습니다.
마지막으로 effect 함수의 반환값으로 콜백 함수를 등록할 수 있습니다. 이 콜백 함수는 컴포넌트가 제거될 때 실행되는 함수로, clean up 함수라고 합니다. 이 clean up 함수를 통해 componentWillUnmount처럼 사용할 수 있습니다.

클래스형 컴포넌트의 forceUpdate를 알고 있나요?

forceUpdate는 리액트에서 공식적으로 제공하는 API로, 해당 컴포넌트를 상태의 변화가 없더라도 재렌더링 시키는 메서드입니다.

함수 컴포넌트에서는 사용할 수 없나요?

함수 컴포넌트에서는 공식적으로 지원하고 있지는 않지만, 약간의 트릭을 이용할 수 있습니다.
상태가 변경되면 해당 컴포넌트가 다시 렌더링 되므로, useState를 통해 상태를 선언하고, forceUpdate라는 함수를 선언해서 상태를 변경하면, 호출 시 다시 렌더링 되게 됩니다.
저는 필요하다면 커스텀 훅으로 정의해서 사용하고 있습니다.

‍ React.Fragment에 대해 설명해 주세요.

리액트 컴포넌트는 1개의 엘리먼트를 리턴해야 하며, 여러 개의 엘리먼트를 리턴할 경우, 에러가 발생합니다.

이러한 상황처럼, 여러 개의 엘리먼트를 단일 엘리먼트가 들어갈 수 있는 위치에 배치하고자 할 때, 사용할 수 있는 문법으로, Fragment는 엘리먼트들을 다른 컨테이너로 감싸지 않기 때문에 레이아웃이나 스타일에 영향을 주지 않습니다.

‍ Portal에 대해 설명해 주세요.

Portal을 사용하면, 컴포넌트가 일부 자식 컴포넌트를 DOM의 다른 위치로 렌더링 할 수 있습니다.

Portal은 오로지 DOM 노드의 물리적 배치만 변경하며, 다른 모든 면에서는 이를 렌더링 하는 React 컴포넌트의 자식 노드 역할을 합니다.

예를 들어, 자식은 부모 컴포넌트의 콘텍스트에 접근할 수 있으며, 이벤트는 자식에서 부모로 버블링 됩니다.

‍ 에러 바운더리에 대해 설명해 주세요.

에러 바운더리는 하위 컴포넌트에서 발생하는 에러를 잡아서 선언적으로 처리할 수 있는 컴포넌트입니다.

이는 try-catch와 비슷한 형식으로, getDerivedStateFromError를 사용하면 폴백 UI를 렌더링 할 수 있고, componentDidCatch를 사용하면 에러 정보를 기록할 수 있습니다.

‍ 리액트의 렌더링 성능 향상을 위해 어떻게 해야 하나요?

state와 props의 변경을 최소화합니다.

React.Memo, useMemo, useCallback 등을 사용합니다.

‍ React 18 버전 업데이트 내용에 대해 말씀해 주세요.

Automatic batching
React 18부터 상태 업데이트를 하나로 통합해서 배치처리한 뒤, 리렌더링을 진행합니다.
hydration error리액트는 서버 마크업을 일치시키기 위해 클라이언트 노드에 삽입이나 삭제를 함으로써 개별 노드를 수정해주지 않고, 트리에서 가장 가까운 <Suspense> 바운더리까지 클라이언트 렌더링으로 돌아갑니다.
텍스트 내용 누락, 불일치 등을 이제 경고가 아닌 오류로 처리합니다.
Suspense
트리에 완전히 추가되기 전에 컴포넌트가 suspend 된 경우 리액트는 새 트리를 완전히 버리고, 비동기 작업이 완료될 때까지 기다린 다음, 다시 처음부터 렌더링을 시도합니다.
새로운 js 환경
이제 모던 브라우저 기능인 Promise, Symbol, Object.assign에 의존합니다. 따라서 인터넷 익스플로러 등 오래된 브라우저를 지원해야 하는 경우 글로벌 폴리필을 추가하는 것을 고려해야 합니다.

‍ Redux

‍ Redux에 대해 설명해 주세요.

Redux는 자바스크립트 상태관리 라이브러리입니다.

Redux를 사용하는 이유에 대해 설명해 주세요.

Redux는 모든 상태의 업데이트를 액션으로 정의하고, 액션 정보에 기반하여 리듀서에서 상태를 업데이트하기 때문에, 상태를 더욱 쉽게 예측가능하게 하여 유지보수 측면에 긍정적인 효과가 있습니다.

또한 Redux-saga, Redux-thunk와 같은 미들웨어를 통해 비동기작업에 대해 더 디테일하고 편한 컨트롤을 할 수 있게 됩니다.

Redux의 장단점에 대해 설명해 주세요.

장점

리덕스를 잘 쓸 수 있게 되는 것의 가장 큰 장점은 상태관리가 쉽다는 것입니다.

프로젝트의 크기가 커지면, 상태가 굉장히 많고 다양해집니다.

그러나 Redux를 사용하면, 웹사이트의 상태를 어디서 관리해야 할지 고민하지 않아도 됩니다.

그리고, 어떤 액션을 통해 어떤 데이터가 변경되었는지 쉽게 알 수 있기 때문에, 상태를 좀 더 예측하기 쉽습니다.

단점

가장 큰 단점은 어렵습니다. 리덕스의 기본 개념 자체를 이해하기 어렵습니다.

그리고, 리덕스를 유용하게 사용하려면 많은 패키지를 추가해야 합니다. 또한 리덕스 스토어 환경설정도 복잡하며, 보일러플레이트 코드를 너무 많이 요구합니다.

이는 Redux-toolkit을 사용하면, 어느 정도 해결되는 문제입니다.

‍ Flux 패턴에 대해 설명해 주세요.

Flux 패턴은 사용자 입력을 기반으로 Action을 만들고, Action을 Dispatcher에 전달하여, Store의 데이터를 변경한 뒤, View에 반영하는 단방향의 흐름으로 애플리케이션을 만드는 아키텍처입니다.

‍ Context API와 Redux를 비교해 주세요.

Context API는 상태관리 도구가 아닙니다.

Context API는 props drilling을 해결하기 위해 나온 도구이고, Redux는 상태를 좀 더 쉽게 관리하고자 나온 도구입니다.

즉, Context API와 Redux를 비교하는 것보다는 Context API와 useState, useReducer를 이용한 상태관리와 Redux를 비교하는 것이 옳습니다.

이 둘의 차이점은 다음과 같습니다.

Redux는 컴포넌트에 상태값을 종속시키지 않고 바깥에서 관리할 수 있습니다.

또한 Redux는 리렌더링을 최적화합니다. useReducer와 달리, Redux를 사용하면 특정 값이 변경될 때에만 re-render 할 수 있습니다. 이를 통해 성능 향상을 꾀할 수 있습니다.

그리고, useReducer는 미들웨어가 없습니다.

‍ Redux의 3대 원칙에 대해 설명해 주세요.

single source of truth: 앱 전체에서 상태 관리 저장소는 단일 저장소로 존재한다.
state is read-only: 상태를 변경하는 방법은 action을 reducer에 전파하는 것이 유일하다.
changes are made with pure functions: 상태 변경 로직을 정의하는 리듀서들은 순수함수로 작성되어야 한다.

‍ Redux-saga와 createAsyncThunk의 공통점과 차이점에 대해 설명해 주세요.

redux-saga와 createAsyncThunk은 둘 다 Redux를 사용하여 비동기 작업을 처리하는 데 도움을 주는 라이브러리 또는 기능입니다. 그러나 각각의 라이브러리가 동작하는 방식과 목적에는 차이가 있습니다.

redux-saga

목적: redux-saga는 Redux 애플리케이션에서 사이드 이펙트 및 비동기 작업을 관리하기 위한 미들웨어입니다. 주로 네트워크 요청, 타이머, 브라우저 이벤트 및 기타 비동기 작업을 처리하는 데 사용됩니다.
작동 방식: redux-saga는 제너레이터 함수(generator function)를 사용하여 비동기 작업을 수행합니다. Redux 액션을 모니터링하고 특정 액션을 감지하면 해당 액션과 관련된 비동기 작업을 시작합니다. 예를 들어, Redux 액션을 디스패치하여 네트워크 요청을 시작하고, 요청이 완료되면 다시 Redux 스토어에 액션을 디스패치하여 상태를 업데이트합니다.
구성: redux-saga는 Redux 스토어에 미들웨어로 추가됩니다. redux-saga 미들웨어는 액션을 모니터링하고 처리할 제너레이터 함수를 실행합니다.

createAsyncThunk

목적: createAsyncThunk는 Redux Toolkit의 일부로 포함된 유틸리티 함수로, Redux를 사용하여 비동기 작업을 처리하는 데 특히 최적화되어 있습니다. 주로 네트워크 요청과 관련된 작업을 간소화하고, 비동기 작업의 상태를 관리하기 위해 사용됩니다.
작동 방식: createAsyncThunk는 주로 비동기 작업의 세 가지 상태(진행 중, 성공, 실패)를 처리하고 관리하는 데 사용됩니다. 사용자는 비동기 작업을 시작하는 함수와 해당 작업이 완료되면 상태를 업데이트하는 리듀서를 정의합니다. 이렇게 정의한 createAsyncThunk 액션 생성자는 비동기 작업의 결과 및 상태를 자동으로 처리하며, 이로써 코드를 간소화하고 일관성을 유지할 수 있습니다.
구성: createAsyncThunk는 Redux Toolkit의 createSlice 또는 createAsyncThunk와 함께 사용됩니다. 액션 생성자로 사용되며, 비동기 작업을 시작하는 함수를 받아서 세 가지 상태(진행 중, 성공, 실패)에 따른 액션을 자동으로 생성합니다.

공통점

둘 다 Redux를 사용하여 비동기 작업을 처리하고, Redux 액션을 통해 상태를 업데이트하는 데 사용됩니다.
비동기 작업의 성공 및 실패를 처리하며, 비동기 작업의 진행 상태를 추적하는 데 유용합니다.
Redux Toolkit과 함께 사용될 때 코드를 더 간소화하고, 일관성을 유지하는 데 도움이 됩니다.

차이점

redux-saga는 미들웨어로 추가되며, 제너레이터 함수를 사용하여 복잡한 비동기 로직을 처리합니다. 반면에 createAsyncThunk은 Redux Toolkit의 유틸리티 함수로, 간단한 사용 사례에 적합하며 코드를 더 간소화합니다.
redux-saga는 더 많은 컨트롤과 유연성을 제공하지만, 구현과 관리가 더 복잡할 수 있습니다. createAsyncThunk은 간단한 사용 사례에서 간소화된 해결책을 제공합니다

[면접 준비] 프론트엔드 전반적인 질문 및 CS

zenghyun — Wed, 27 Sep 2023 21:57:11 +0900

Start!

‍ 프론트엔드

⭐️ ‍ 사용자가 URL을 입력한 후 화면이 출력되기까지의 과정을 설명해 주세요.

사용자가 URL을 입력하면 웹 브라우저에서 URL의 유효성을 판단합니다.
URL이 유효하지 않으면 웹 브라우저는 입력한 내용을 검색하게 되고, URL이 유효하면 DNS 서버에 연결할 IP를 요청합니다.
DNS 서버에서 IP 주소를 받으면 3-way 핸드셰이킹으로 TCP 통신을 위한 가상 회선을 연결합니다.
HTTP 연결 요청을 서버에 보내면, 이에 대한 응답을 받고 웹 페이지 화면을 출력합니다.

⭐️ ‍ 브라우저 렌더링 과정에 대해 설명해 주세요.

HTML 파일과 CSS 파일을 파싱 해서 각각 Tree를 만듭니다. (DOM Tree, CSSOM Tree 생성)
두 Tree를 결합하여 Rendering Tree를 만듭니다. (Style)
Rendering Tree에서 각 노드의 위치와 크기를 계산합니다. (Layout Reflow)
계산된 값을 이용해 각 노드를 화면상의 실제 픽셀로 변환하고, 레이어를 만듭니다. (RePaint)
자바스크립트 실행 및 이벤트 처리를 합니다.
리플로우와 리페인트 최적화 합니다.
레이어를 합성하여 실제 화면에 나타냅니다. (Composite)

Parsing (파싱)이란 무엇인가요?

브라우저가 코드를 이해하고 사용할 수 있는 구조로 변환하는 것을 의미하며, 파싱 결과는 보통 노드 트리, 파싱 트리, 문법 트리라고 부릅니다.

‍ Webpack, Babel, Polyfill에 대해 설명해 주세요.

Webpack, Babel, Polyfill 모두 웹 개발에서 자주 사용되는 도구 및 기술로, JavaScript 코드의 번들링, 변환 및 호환성을 향상 시키는 데 사용됩니다.

Webpack?

Webpack은 모듈 번듈러로, 여러 개의 JS 파일 및 다른 종속성 파일을 하나의 번들 파일로 결합할 때 사용합니다.

Webpack의 기능으로는 코드 스플리팅, 모듈 로딩, 번들 최적화, CSS 번들링, 이미지 및 리소스 관리 등이 있습니다.

Babel?

Babel은 JavaScript 코드 변환 도구로, 최신 버전의 JavaScript 문법을 이전 버전으로 변환하여 여러 브라우저 및 환경에서 호환성을 확보합니다. 주로 ES6(ES2015) 이상의 문법을 ES5로 변환하는 데 사용합니다.

Polyfill?

Polyfill은 브라우저 호환성을 향상시키기 위해 사용되는 코드 조각이나 라이브러리입니다. Polyfill은 오래된 브라우저에서 지원하지 않는 기능을 구현하거나 대체하여 웹 애플리케이션이 다양한 환경에서 동작할 수 있도록 합니다.

⭐️ ‍ 리플로우, 리페인트에 대해 설명해 주세요.

리플로우(Reflow)와 리페인트 (Repaint)는 웹 페이지의 레이아웃과 시각적 표현을 업데이트하는데 관련된 프로세스입니다.

이 두 프로세스는 웹 브라우저가 웹 페이지를 렌더링 할 때 발생하는 중요한 작업입니다.

리플로우(Reflow)

리플로우는 웹 페이지의 레이아웃을 계산하고 업데이트하는 프로세스입니다. 레이아웃은 요소의 크기, 위치, 여백 등과 관련이 있습니다.
리플로우는 웹 페이지의 초기 렌더링, 윈도우 크기 변경, 요소의 크기 또는 위치 변경, 폰트 크기 변경 등과 같이 레이아웃에 영향을 미치는 변경 사항이 발생할 때 발생합니다.
리플로우가 발생하면 브라우저는 해당 요소 및 해당 부모와 자식 요소의 크기와 위치를 다시 계산하고, 이에 따라 레이아웃을 조정합니다. 이 프로세스는 비용이 많이 들며, 성능에 영향을 줄 수 있습니다.

리페인트 (Repaint)

리페인트는 웹 페이지의 시각적 표현을 업데이트하는 프로세스입니다. 리페인트는 레이아웃 변경 없이 요소의 스타일 변경(색상, 배경, 텍스트 스타일 등)과 같은 시각적 속성 변경에 의해 발생할 수 있습니다.
리페인트는 리플로우보다 비교적 가벼운 작업이며, 웹 페이지의 시각적 업데이트를 담당합니다.
리페인트가 발생하면 브라우저는 화면에 나타내는 요소의 시각적 모습을 다시 그립니다.

이러한 리플로우와 리페인트 작업은 웹 페이지의 성능에 영향을 미칩니다.

⭐️ ‍ REST가 무엇인지 설명해 주고, 장단점에 대해 알려주세요.

REST (Representational State Transfer)는 웹에서 데이터를 주고받기 위한 아키텍처입니다. URI로 자원을 명시하고, HTTP 메서드로 CRUD 연산을 합니다. 그리고 HTTP를 따르는 모든 플랫폼에서 별도의 인프라 구축 없이 REST를 사용할 수 있습니다. 그래서 웹 외에도 iOS, 안드로이드 등 다양한 플랫폼과 디바이스가 등장하면서 범용으로 사용할 수 있다는 장점이 부각되고 있습니다. 하지만 HTTP 메서드를 사용해야 해서 사용 가능한 연산이 한정적이라는 단점이 있습니다.

REST : 자원을 명시해 연산을 수행하고 상태를 주고받는 것

CRUD

Create - POST
Read - GET
Update - UPDATE
Delete - DELETE

REST API가 무엇인가요?

REST API는 REST를 기반으로 한 API를 뜻합니다. REST API는 자원, 행위, 표현으로 구성됩니다.

REST API에서 자원의 식별은 URI로 하고, 자원에 대한 행위(처리)는 HTTP 메서드로 나타냅니다. 그리고 전달되는 데이터는 JSON 또는 XML 등으로 표현합니다.

REST API 작동 방식

클라이언트가 URI로 식별한 자원에 대해 HTTP 메서드를 사용해 REST API로 요청합니다.
REST API가 HTTP 요청 메시지에 실려 서버에 전달됩니다.
서버에서는 수신한 HTTP 요청 메시지를 바탕으로 요청 사항을 확인해 처리하고 HTTP 응답을 반환합니다. 응답에는 요청에 대한 처리 성공 여부와 정보를 포함합니다.
응답 메시지는 자원에 대한 정보를 JSON 또는 XML 등의 형태로 포함하고 있습니다. 클라이언트는 형태의 정보를 수신합니다.

⭐️ ‍ CORS에 대해 설명해 주세요.

CORS는 Cross Origin Resource Sharing의 약자입니다. CORS에 대해 설명하기 전에 SOP (Same Origin Policy)에 대해 알아야 합니다.

origin은 protocol과 host를 합친 것입니다.

즉, SOP는 같은 origin 끼리만 데이터를 송수신하고자 하는 동일 출처 정책입니다.

클라이언트에서 도메인이 다른 서버에서 제공하는 API를 사용하는 일이 많아졌는데, 이 동일 출처 정책을 지키기 위해 나온 것이 CORS입니다.

CORS는 한 도메인 또는 origin의 웹 페이지가 다른 도메인 (도메인 간 요청)을 가진 리소스에 액세스 할 수 있게 하는 보안 메커니즘입니다.

예를 들어, 리액트로 개발 중인 클라이언트 서버와 서버 간의 origin이 다르게 되면 CORS 에러가 발생하게 됩니다.

대표적인 해결 방법으로는 CRA (Create React APP)에서는 package.json에서 Proxy 설정을 하여 해결합니다.

⭐️ ‍ 쿠키와 세션에 대해 설명해 주세요.

쿠키와 세션 모두 HTTP 통신의 특징인 비연결성과 무상태의 단점을 보완하기 위해 사용합니다. 쿠키는 브라우저에 저장되는 키와 값이 들어 있는 데이터 파일입니다. 이는 서버에서 클라이언트에 대한 정보를 저장하지 않아도 쿠키를 이용해 정보를 재사용할 수 있게 합니다. 예를 들어, 웹 사이트의 로그인 인증 정보, 온라인 쇼핑몰의 장바구니 정보 등이 있습니다.

세션은 쿠키와 비슷하게 데이터를 저장하는 방식이지만 키와 값은 클라이언트에, 데이터는 서버에 저장해서 쿠키보다 보안에 강하다는 특징이 있지만, 사용자가 많아질수록 서버 메모리를 많이 차지합니다.

‍ JWT는 뭔가요?

JWT는 JSON 웹 토큰으로 인증 및 권한 부여의 목적으로 사용됩니다.

JWT는 헤더, 페이로드 및 서명의 세 부분으로 구성됩니다.

헤더 (Header) : 서명을 생성하는 데 사용되는 토큰 유형 및 해싱 알고리즘에 대한 정보가 포함되어 있습니다.
페이로드(Payload) : 토큰이 전달하는 클레임 또는 데이터가 포함됩니다.
서명(Signature) : 전송 중에 토큰이 변조되지 않았는지 확인하는 데 사용됩니다.

JWT는 일반적으로 웹 애플리케이션 및 API에서 클라이언트와 서버 간에 사용자 데이터를 안전하게 전송하는 수단으로 사용됩니다. 토큰은 서버에서 생성되어 저장되는 클라이언트로 전송됩니다. 그런 다음 클라이언트는 각 후속 요청과 함께 토큰을 전송하여 서버가 사용자 이름과 암호를 계속 확인하지 않고도 사용자를 인증하고 권한을 부여할 수 있도록 합니다.

JWT는 독립형으로 설계되었으며 세션 데이터의 서버 측 스토리지가 필요하지 않으므로 분산 시스템에서 보다 확장 가능하고 사용하기 쉽습니다.

https://velog.io/@leemember/%ED%94%84%EB%A1%A0%ED%8A%B8%EC%97%94%EB%93%9C-%EA%B8%B0%EC%88%A0-%EB%A9%B4%EC%A0%91-%EB%8B%A8%EA%B3%A8-%EA%B0%9C%EB%85%90%EB%93%A4-%EC%A0%95%EB%A6%AC-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC-CS-%ED%8E%B8-%EA%B7%B8-%EC%99%B8-%EC%A7%88%EB%AC%B8

왼쪽이 토큰 정보이고, 오른쪽이 토큰 암호를 복호화시켜 나온 정보입니다.

JWT 토큰을 쿠키에 저장했을 때 초래할 수 있는 취약점에 대해 설명해 주세요.

XSS(Cross-Site Scripting) 취약점이 있어, 해커가 악의적인 스크립트를 삽입하여 쿠키에 저장된 JWT를 탈취하고 다른 사용자처럼 웹 애플리케이션에 로그인할 수 있습니다.

또한, JWT 토큰을 쿠키에 저장하면, 브라우저는 해당 도메인에 대한 모든 요청에 자동으로 쿠키를 첨부합니다. 이는 원치 않는 동작을 유발할 수 있으며, CSRF 공격에 취약할 수 있습니다.

XSS와 CSRF는 무엇인가요? 그리고 차이점에 대해 설명해 주세요

XSS ( 사이트 간 스크립팅 : Cross-Site-Scripting )

웹사이트 관리자가 아닌 이가 웹 페이지에 악성 스크립트를 삽입할 수 있는 취약점으로 발생되는 공격입니다.

https://dar0m.tistory.com/246

CSRF ( Cross- Site-Request-Forgery )

사용자가 자신의 의지와는 무관하게 공갹자가 의도한행위(수정, 삭제, 등록 등)를 특정 웹사이트에 요청하게 하는 공격을 말합니다.

https://dar0m.tistory.com/246

차이점

XSS는 공격 대상이 Client이고, CSRF는 Server 입니다.

XSS는 사용자가 특정 웹사이트를 신용하는 점을 노린 것이라면,

CSRF는 특정 웹사이트가 사용자의 웹 브라우저를 신용하는 상태를 노린 것입니다.

XSS는 사이트변조나 백도어를 통해 클라이언트에 대한 악성 공격을 시도합니다.

CSRF는 요청을 위조하여 사용자의 권한을 이용해 서버에 대한 악성 공격을 시도합니다.

⭐️ ‍ 크로스 브라우징에 대해 설명해 주시고, 해결해 본 경험이 있다면 말해주세요.

크로스 브라우징(Cross-Browsing)은 웹 개발에서 중요한 개념으로, 다양한 웹 브라우저와 버전에서 웹 사이트 또는 웹 애플리케이션이 일관된 방식으로 작동하도록 보장하는 작업을 의미합니다. 웹 브라우저는 다양한 엔진과 렌더링 엔진을 사용하며, 이로 인해 웹 페이지가 다르게 렌더링되거나 동작하는 문제가 발생할 수 있습니다.

크로스 브라우징을 고려하는 주요 작업 및 고려 사항은 다음과 같습니다.

HTML,CSS 및 JavaScript 표준 준수
브라우저 특정 CSS 및 JavaScript 대응 ( CSS webkit )
폴리필 사용
미디어 퀴리 및 반응형 디자인
접근성 고려 ( 장애인을 고려한 태그 사용 )

⭐️ ‍ 객체 지향 프로그래밍이 무엇인가요?

객체 지향 프로그래밍(OOP, Object-Oriented Programming)은 소프트웨어 개발 패러다임 중 하나로, 현실 세계의 객체(Object)와 그 객체들 간의 상호 작용을 모델링하고 프로그래밍하는 방법론입니다. OOP는 소프트웨어의 구조화와 재사용성을 증가시키며 코드의 가독성과 유지 보수성을 향상시키는 데 도움을 줍니다.

객체 지향 프로그래밍의 주요 특징

객체(Object): 현실 세계의 개념 또는 사물을 프로그래밍에 적용한 것으로, 데이터와 그 데이터를 조작하는 메서드(함수)로 구성됩니다. 객체는 클래스(Class)를 기반으로 생성됩니다.

클래스(Class): 객체의 설계도 또는 템플릿으로, 객체를 생성하기 위한 구조와 행위(데이터와 메서드)를 정의합니다. 클래스는 객체를 생성하기 위한 틀로서 다수의 객체를 생성할 수 있습니다.

캡슐화(Encapsulation): 객체의 상태(데이터)와 행위(메서드)를 하나로 묶고, 외부에서 직접 접근하지 못하도록 보호합니다. 객체의 내부 구현은 숨기고, 외부에 필요한 인터페이스만 제공합니다.

상속(Inheritance): 클래스 간의 상속 관계를 통해 부모 클래스(슈퍼 클래스)의 특성을 자식 클래스(서브 클래스)가 상속받을 수 있습니다. 이로써 코드의 재사용성을 증가시키고 계층 구조를 형성할 수 있습니다.

다형성(Polymorphism): 다양한 객체가 동일한 인터페이스를 사용하거나 동일한 메서드를 호출할 수 있는 능력을 가리킵니다. 다형성은 인터페이스를 통해 구현되며, 메서드 오버라이딩(Overriding)과 메서드 오버로딩(Overloading)을 통해 구현됩니다.

장점

모듈화(Modularity): 코드를 객체 단위로 모듈화하므로 유지 보수가 쉽고 코드 재사용성이 높습니다.

코드 가독성 및 유지 보수성: 객체 지향 프로그래밍은 현실 세계 개념을 모델링하므로 코드의 가독성이 높고 유지 보수가 쉽습니다.

재사용성: 클래스와 객체의 재사용을 통해 개발 시간을 단축하고 효율적으로 코드를 작성할 수 있습니다.

확장성(Scalability): 객체 지향 프로그래밍은 새로운 클래스와 객체를 추가하거나 기존 클래스를 수정하여 소프트웨어를 확장하기 쉽습니다.

설계의 용이성: 객체 지향 설계는 현실 세계의 개념을 반영하므로 프로그램의 설계와 구조를 용이하게 만듭니다.

단점

복잡성: 큰 규모의 시스템에서 객체 지향 프로그래밍은 복잡성을 증가시킬 수 있습니다.

성능 저하: 일부 상황에서는 객체 지향 프로그래밍이 프로그램 실행 속도를 늦출 수 있습니다.

학습 곡선: 객체 지향 프로그래밍은 초기 학습 곡선이 높을 수 있으며, 올바른 객체 지향 설계를 위한 경험이 필요합니다.

객체 지향 프로그래밍은 프로그램의 구조와 설계를 개선하며 유지 보수성과 재사용성을 증가시키는 데 도움이 되는 중요한 개념입니다. 그러나 프로젝트의 특성과 요구사항에 따라 객체 지향을 적절히 활용해야 합니다.

⭐️ dependencies와 devDependencies의 차이에 대해 설명해 주세요.

dependencies와 devDependencies는 Node.js 및 JavaScript 프로젝트에서 사용되는 두 가지 종류의 종속성(의존성)을 관리하는 데 사용되는 용어입니다.

dependencies의 경우 애플리케이션과 직관되어 있는, 화면에 영향을 미치는 라이브러리 같은 것을 설치하고, devDependencies의 경우 webpack, js-compress, sass 등 개발을 할 때 도움을 주는 개발용 라이브러리를 설치합니다.

devDependencies에 있는 라이브러리는 배포시 설치되지 않습니다.

‍ 네트워크

⭐️ ‍ HTTP에 대해 설명해 주세요.

HTTP (HyperText Transfer Protocol)는 데이터 전송을 위한 클라이언트-서버 구조의 요청 / 응답 프로토콜로, TCP/IP 4계층에서 응용 계층에 속합니다. HTTP는 비연결성과 무상태라는 두 가지 특징이 있습니다. 첫 번째로 비연결성은 클라이언트의 요청에 대해 서버가 응답한 후 연결을 끊는다는 것입니다. 이를 보완하기 위해 HTTP Keep Alive를 사용합니다. 두 번째로 무상태는 서버에서 클라이언트의 상태에 대한 데이터를 저장하지 않는다는 것입니다. 이러한 단점을 보완하기 위해 쿠키와 세션을 사용합니다.

TCP/IP 4계층

(왼쪽에서 오른쪽으로 갈수록 하단)

HTTP : 응용 계층 -> 전송 계층 -> 인터넷 계층 -> 네트워크/인터페이스 계층

HTTPS : 응용 계층 -> 보안 계층 -> 전송 계층 -> 인터넷 계층 -> 네트워크/인터페이스 계층

HTTP Keep Alive에 대해 설명해 주세요.

HTTP Keep Alive는 클라이언트와 서버 간에 연결을 유지하기 위한 하나의 방법입니다. HTTP Keep Alive는 HTTP 프로토콜의 연결을 정해진 시간 동안 유지하는 방식으로, 정해진 시간이 끝나면 연결을 해지합니다. 이런 방식을 통해 클라이언트와 서버 간에 불필요한 연결과 해체의 반복을 줄일 수 있습니다.

HTTP와 HTTPS의 차이점에 대해 설명해 주세요.

HTTP와 HTTPS는 인터넷상에서 데이터를 송수신하기 위한 클라이언트-서버 구조의 통신 프로토콜입니다.

HTTP와 달리 HTTPS에는 보안 계층의 암호화 프로토콜인 SSL/TSL가 있어서 전송하려는 데이터를 암호화해 보호할 수 있습니다. 이런 특징은 인터넷 쇼핑이나 인터넷 뱅킹등 민감한 정보를 사용하는 웹 사이트에서 중요한 요소입니다.

HTTPS에서 사용하는 암호화 방식에 대해 설명해 주세요.

HTTPS는 보안 계층의 암호화 프로토콜인 SSL/TLS에서 암호화가 이뤄집니다. 사용하는 암호화 방식으로는 대칭 키 암호화 방식과 공개 키 암호화 방식이 있습니다.

대칭 키 암호화 방식은 데이터의 송신자와 수신자 모두 대칭 키를 이용해 데이터를 암호화 및 복호화하는 방식입니다. 반면, 공개 키 암호화 방식은 공개 키로 데이터를 암호화하고 비밀 키로 데이터를 복호화하는 방식입니다. SSL/TSL에서는 대칭 키로 데이터를 암호화하는데, 이때 대칭 키가 공개되므로 데이터가 유출되는 것을 막기 위해 대칭 키를 공개 키 암호화 방식으로 암호화합니다.

HTTP Status Code에 대해 설명해 주세요.

HTTP Status Code ( HTTP 상태 코드 )는 클라이언트의 요청에 대한 서버의 상태를 알려 주는 코드로, 세 자리 숫자로 표현 할 수 있습니다. 그리고 코드의 시작 숫자로 의미를 알 수 있습니다.

1xx : 클라이언트로부터 요청을 받아 처리 중
2xx : 요청을 성공적으로 처리함
3xx : 요청을 처리하기 위해 추가 처리 필요
4xx : 클라이언트 오류
5xx : 서버 오류

‍ 자료구조

‍ 배열과 연결 리스트의 차이점을 설명해 주세요.

배열과 연결 리스트는 데이터를 저장하기 위한 자료구조로, 데이터 저장 방식에 큰 차이가 있습니다. 배열은 연속된 메모리 공간에 데이터를 저장합니다. 그래서 특정 인덱스의 데이터에 한 번에 접근할 수 있어서 읽는 속도가 빠릅니다. 하지만 데이터 삭제 또는 삽입 시 요소들의 인덱스를 수정해야 해서 비교적 시간이 오래 걸립니다. 반면에 연결 리스트는 노드를 이용해 메모리 공간에 데이터를 불연속적으로 저장합니다. 각 노드는 데이터와 다음 노드의 주소 값을 저장하고 있어서 다른 노드에 접근할 수 있습니다. 배열과 달리 인덱스가 없으므로 한 번에 특정 데이터에 접근할 수 없지만, 데이터의 삽입과 삭제 시 노드가 기리키는 주소 값만 변경하면 되어서 속도가 빠르다는 장점이 있습니다.

‍ 스택은 어떤 경우에 주로 사용하나요?

스택은 데이터가 쌓이는 구조로 후입선출의 특징이 있습니다. 그래서 주로 마지막에 수행한 작업으로 돌아가야 할 때 자주 사용합니다. 예를 들어, 웹 브라우저에서 뒤로가기 버튼을 눌러 앞에 열었던 페이지를 다시 열거나 작업 프로그램에서 실행 취소 기능을 수행해 마지막 상태로 돌아가야 하는 상황이 있습니다. 이외에도 프로그램을 실행할 때 함수를 수행한 후 돌아가야 하는 주소 값을 저장하는 용도로 사용하기도 합니다.

‍ 큐를 스택으로 구현하는 방법에 대해 설명해 주세요.

큐는 선입선출, 스택은 후입선출 방식이므로 스택 2개를 사용해 큐를 구현할 수 있습니다. 우선 데이터 전체를 첫 번째 스택에 넣습니다. 이때 데이터는 역순으로 뒤집히게 됩니다. 이 데이터를 다시 두 번째 스택에 넣으면 마지막 데이터부터 첫 번째 데이터 순으로 쌓이게 됩니다. 따라서 두 번째 스택에서 pop 연산을 하면 선입선출을 구현할 수 있습니다.

‍ 우선순위 큐가 무엇인가요?

우선순위 큐는 우선순위가 높은 데이터부터 꺼내는 자료구조로, 각 요소가 우선순위를 가집니다. 우선순위 큐를 활용해 정렬하거나 다익스트라 알고리즘을 구현할 때 사용합니다. 우선순위 큐는 주로 힙을 이용해 구현합니다.

‍ 힙이란 무엇인가요?

힙은 완전 이진 트리의 한 종류로, 최대 힙과 최소 힙이 있습니다. 최대 힙은 부모 노드가 자식 노드의 값보다 크다는 조건을 갖습니다. 최소 힙은 부모 노드가 자식 노드의 값보다 작습니다. 최대 힙과 최소 힙을 이용해 최댓값과 최솟값을 빠르게 찾을 수 있어서 우선순위 큐를 구현하거나 힙 정렬을 하는데 주로 사용합니다.

‍ 이진 탐색 트리, 포화 이진 트리, 완전 이진 트리의 차이점은 무엇인가요?

이진 트리 : 자식 노드의 개수가 최대 2개인 트리

3가지 모두 이진 트리이지만, 서로 다른 특징이 있습니다. 먼저 이진 탐색 트리는 모든 노드에 대해 왼쪽 서브 트리는 해당 노드보다 작은 값을 가지고, 오른쪽 서브 트리는 해당 노드보다 큰 값을 가집니다. 포화 이진 트리는 트리의 마지막 레벨까지 모든 노드가 채워져 있습니다. 마지막으로 완전 이진 트리는 트리의 마지막 레벨을 제외한 나머지 레벨에 모든 노드가 채워져 있으며, 마지막 레벨은 왼쪽에서 오른쪽으로 노드가 채워져 있습니다.

‍ 트리와 그래프의 차이점은 무엇인가요?

그래프는 정점과 간선으로 구성된 자료구조입니다. 방향 그래프와 무방향 그래프 모두 존재하며, 사이클은 있을 수도, 없을 수도 있습니다. 또한, 계층 관계가 없습니다. 반면에 트리는 그래프의 한 종류로, 방향성이 있으면서 사이클이 존재하지 않습니다. 또한, 계층 관계가 있어서 부모 노드와 자식 노드라는 관계성과 루트 노드라는 개념이 존재합니다.

‍ BFS ( 너비 우선 탐색 ) 과 DFS ( 깊이 우선 탐색 ) 의 차이점은 무엇인가요?

두 그래프 모두 탐색을 수행할 때 사용합니다. BFS는 너비 우선 탐색으로, 하나의 노드에서 시작해 가까운 노드들을 먼저 탐색합니다. 큐로 구현할 수 있고, 비가중치 그래프에서 각 노드까지의 최단 거리를 알 수 있습니다. DFS는 깊이 우선 탐색으로, 하나의 노드에서 시작해 최대 깊이까지 탐색을 수행합니다. 스택 또는 재귀 함수로 구현할 수 있습니다.

‍ 해시 테이블이란 무엇인가요?

해시 테이블은 키와 값을 저장하고 있는 자료구조입니다. 해시 함수로 키에 대한 해시를 얻을 수 있는데, 해시는 해시 테이블에서 값이 저장되어 있는 인덱스입니다. 해시 테이블은 O(1)이라는 빠른 시간 안에 해시 함수를 통해 원하는 값에 접근할 수 있는 특징이 있습니다. 하지만 서로 다른 키를 넣었을 때 동일한 값이 나오는 해시 충돌이 발생할 수 있다는 단점도 있습니다.

[면접 준비] HTML / CSS

zenghyun — Wed, 27 Sep 2023 12:16:50 +0900

Start!

geekflare .com

‍ DOCTYPE은 무엇을 하나요?

DOCTYPE는 document type의 약어입니다. DOCTYPE는 항상 DTD(Document Type Definition)와 관련됩니다.

DTD는 특정 문서가 어떻게 구성되어야 하는지 정의합니다. (예시: button은 span을 포함할 수 있지만, div는 그럴 수 없다.)

반면, DOCTYPE는 문서가 대략 존중할만한 DTD를 선언합니다.

웹 페이지는 DOCTYPE 선언이 필요합니다. 유저 에이전트에게 문서가 존중하는 HTML 사양의 버전을 알리는 데 사용됩니다. 유저 에이전트가 올바른 DOCTYPE을 인식하면, 문서를 읽는 데에 DOCTYPE과 일치하는 no-quirks mode를 트리거합니다. 유저 에이전트가 올바른 DOCTYPE을 인식하지 못하면, quirks mode를 트리거합니다.

HTML5 표준에 대한 DOCTYPE 선언은 <!DOCTYPE html>입니다.

⭐️ ‍ 시맨틱 마크업에 대해 설명해 주세요.

시맨틱 마크업은 주어진 용도에 맞는 태그를 사용하는 것을 의미합니다. 대표적으로 <div> 대신 <header>, <aside>, <nav> 등을 사용하여 문서를 작성하는 것을 말합니다.

이를 통해 얻을 수 있는 장점으로는 SEO(검색 엔진 최적화)에 유리하며, 웹 접근성을 향상하고, 코드의 가독성을 개선한다는 점이 있습니다.

⭐️ ‍ SEO(검색 엔진 최적화)에 대해 설명해 주세요.

검색 엔진 최적화(Search Engine Optimization)는 웹사이트와 웹페이지를 검색엔진이 쉽게 발견(디스커버리)하고, 읽어가서(크롤링), 색인하고(인덱싱), 상위 노출(랭킹)시켜 자연 유입되는 트래픽의 양과 질을 높일 수 있도록 관련 검색 알고리즘의 특성을 고려해서 웹사이트의 구조나 콘텐츠를 개선하는 일련의 작업을 말합니다.

⭐️ 평소에 SEO를 어떻게 최적화하시나요?

1. 문법에 맞는 HTML 작성하기 :

<title> 태그에는 사이트 제목을 기재하고, <div> 태그를 사용해 줄을 바꾸고, <strong>과 <em> 태그를 활용해 강조하고 싶은 키워드에 붙이기

2. 메타 태그 활용하기

3. 이미지에 alt 속성 기재

4. anchor 태그 적절히 활용하기 ( a 태그 )

5. HTTPS 사용 권장 ( http 보다 https가 구글 검색 엔진에서 1% 정도의 랭킹 가산점 부여 )

‍ HTML 렌더링 도중 JavaScript가 실행되면 렌더링이 멈추는 이유가 뭔가요?

JavaScript는 DOM API를 통해서 DOM Tree를 변경할 수 있기 때문에, JS가 실행되면 렌더링 엔진이 JS엔진에게 제어 권한을 넘겨줍니다.

‍ Attribute와 Property의 차이에 대해 설명해 주세요.

Attribute은 HTML의 속성이며 Property는 DOM의 속성입니다.

가장 큰 차이점은 attribute는 정적인 속성이라는 것이고, property는 동적인 속성이라는 것입니다.

예시로 체크박스에 체크를 했을 때, attribute는 변경되지 않지만, property는 변경되는 것을 볼 수 있습니다.

또 하나는 사용자 정의 속성에 대한 접근 차이가 있습니다.

임의로 지정한 사용자 정의 속성은 프로퍼티로 자동으로 표현되지 않습니다.

따라서 getAttribute()와 setAttribute()로 접근해야 합니다.

이 외에도, 프로퍼티의 이름은 식별자 규칙을 따라야 하기 때문에 이름을 짓는데 규칙이 있으며, 프로퍼티 접근 성능이 어트리뷰트 접근 성능보다 좋다는 차이점이 있습니다.

‍ cookie, sessionStorage, localStorage의 차이점에 대해 설명해 주세요.

위 세 가지 기술은 모두 클라이언트 측에서 값을 저장하는 key-value 저장소 메커니즘입니다. 모두 문자열로만 값을 저장할 수 있습니다.

	cookie	localStorage	sessionStorage
생성자	클라이언트나 서버, 서버는 Set-Cookie 헤더를 사용할 수 있습니다.	클라이언트	클라이언트
만료	수동으로 설정	영구적	탭을 닫을 때
브라우저 세션 전체에서 지속	만료 설정 여부에 따라 다름	o	x
모든 HTTP 요청과 함께 서버로 보냄	쿠키는 Cookie 헤더를 통해 자동 전송	x	x
용량	4kb	5MB	5MB
접근성	모든 윈도우	모든 윈도우	같은 탭

‍ <script>, <script async>, <script defer> 사이의 차이점을 설명해 주세요.

<script> : HTML 파싱이 중단되고, 스크립트를 즉시 가져오고 실행되며, 스크립트 실행 후 HTML 파싱이 다시 시작됩니다.

defer 속성은 해당 스크립트를 백그라운드에서 다운로드합니다. 그리고 페이지 구성이 끝날 때까지 그 실행이 지연됩니다. defer 스크립트의 실행이 끝난 후 DOMContentLoaded 이벤트가 발생합니다.

async 속성은 페이지와 완전히 독립적으로 동작합니다. 따라서 DOMContentLoaded가 스크립트의 실행을 기다려주지 않습니다.

주의: src 속성이 없는 스크립트 태그는 async와 defer 속성이 무시됩니다.

‍ 일반적으로 CSS <link> 태그를 <head></head> 태그 사이에 위치시키고, JS <script> 태그를 </body> 직전에 위치시키는 것이 왜 좋은 방법인가요?

<head> 안에 <link>를 넣는 이유

페이지가 처음 로드되면 HTML과 CSS가 동시에 파싱 됩니다. HTML은 DOM(Document Object Model)을 만들고 CSS는 CSSOM(CSS Object Model)을 만듭니다. 두 가지 모두 웹사이트에서 시각적인 부분을 만드는데 필요합니다.

<link>를 <head> 안에 넣는 것은 점진적 렌더링을 위하여 사이트의 성능 점수에서 측정되는 사이트 최적화의 범위이기 때문입니다.

그 외에도 상단에 배치하면 페이지가 점진적으로 렌더링 되기 때문에 UX가 향상됩니다.

<head> 안에 <link>를 넣는 이유

<script>는 다운로드되고 실행되는 동안 HTML 파싱을 차단합니다. 스크립트를 맨 아래에 두면 HTML을 먼저 파싱 하여 사용자에게 표시할 수 있습니다.

‍ Progressive Rendering (프로그레시브 렌더링)이 무엇인가요?

프로그레시브 렌더링이란 콘텐츠를 가능한 한 빠르게 표시하기 위해 웹 페이지의 성능을 향상하는 데 사용되는 기술입니다. (특히, 인식되는 로딩 시간을 향상합니다.)

관련 기술

이미지 지연 로딩: 페이지의 이미지를 한꺼번에 로딩하지 않고 JS를 사용하여 사용자가 이미지를 표시하는 페이지 부분으로 스크롤할 때 이미지 로드
보이는 콘텐츠의 우선순위 설정: 가능한 한 빨리 표시하기 위해 사용자 브라우저에서 렌더링 될 페이지에 필요한 최소한의 CSS/콘텐츠/스크립트만 포함하면 deferred 스크립트를 사용하거나 DOMContentLoaded/load 이벤트를 사용하여 다른 리소스와 내용을 로드

‍ px, em, rem의 차이에 대해 설명해 주세요.

px는 고정된 절댓값입니다. 그에 반해 em과 rem은 환경에 따라 변하는 단위입니다.

em 같은 요소에서 사용한 font-size 속성값을 기준으로 변경됩니다. 만약 같은 요소에 font-size 속성이 없다면 부모 요소의 font-size를 상속받습니다.

rem은 최상위 요소인 <html>의 font-size를 기준으로 변경됩니다.

em과 rem 모두 만약 font-size가 정의되지 않았다면 16px이 단위가 됩니다.

반응형 웹을 구현할 때는 이 단위 중에서 어떤 단위를 주로 사용하시나요?

대부분 rem를 사용합니다. rem을 사용하면 크기의 예측이 훨씬 쉽습니다. 따라서 컴포넌트의 재사용이 쉽고, 유지보수가 쉽습니다.

‍ vw, vh에 대해 설명해 주세요.

vw는 viewport의 너비 값을 100vw라고 정의합니다.

즉 viewport 너비의 0.01배가 1vw입니다.

vh는 viewport의 높이 값을 100vh로 정의합니다.

즉 viewport 높이의 0.01배가 1vh입니다.

⭐️ ‍ CSS 선택자의 우선순위에 대해 설명해 주세요.

가장 먼저! important가 적용됩니다. !important는 속성 기준으로 가장 우선 적용됩니다. 점수로 산정할 수 없으며, 여러 개가 있다면 마지막에 작성된 코드가 우선됩니다.

그다음 인라인 스타일이 적용됩니다. 인라인 스타일은 요소 기준 가장 우선 적용됩니다. 점수로 산정한다면 1000점이 부여됩니다.

다음으로 ID 선택자입니다. 점수로 산정한다면 100점이 부여됩니다.

Class 선택자, 속성기반 선택자, :hover와 같은 가상 클래스, ::after와 같은 가상요소 선택자가 모두 같은 우선순위를 갖습니다. 점수로 산정한다면 10점이 부여됩니다.

다음으로 태그 선택자 입니다. 점수로 산정한다면 1점이 부여됩니다.

마지막으로 전체 선택자(*)입니다. 점수로 산정한다면 0점입니다.

요약

!important: 점수 산정 불가, 제일 우선순위
인라인 스타일: 1000점
ID 선택자: 100점
Class 선택자, 속성기반선택자, :hover, ::after 등 : 10점
태그 선택자 : 1점
전체 선택자 (*) : 0점

가상 클래스에 대해 설명해 주세요.

가상 클래스는 특정 이벤트마다 적용할 스타일을 설정한 것을 의미합니다.

대표적으로 :hover나 focus 등이 있습니다.

‍ 페이지 크기가 변해도 항상 같은 비율을 유지하는 요소를 만들려면 CSS를 어떻게 설정해야 될까요?

페이지 크기에 따라 같은 비율을 유지하는 요소를 만들려면 % 단위를 사용하면 됩니다.

고정해야 하는 위치에 따라, margin, padding, width, height에 % 단위를 사용할 수 있습니다.

‍ Flexbox에 대해 설명해 주세요

Flexbox는 레이아웃을 좀 더 쉽게 배치할 수 있도록 고안된 스펙입니다.

Flex를 사용할 때, 부모 요소를 Flex container라고 부르고, 자식 요소를 Flex Item이라고 부릅니다.

Flex는 Flex Container에 display: flex;를 적용하여 사용할 수 있습니다. Flex의 속성들은 container에 적용되는 속성과 Item에 적용되는 속성으로 나뉩니다.

대표적인 속성으로 flex-direction, justify-content, align-items 등이 있습니다.

‍ float의 동작에 대해 설명해 주세요.

float을 설정하면 요소를 기존 문서의 흐름에서 빠져나와 포함된 박스나 다른 float 요소의 edge에 닿을 때까지 좌나 우로 이동하게 됩니다.

‍ margin과 padding에 대해 설명해 주세요.

margin은 요소의 바깥 여백 영역을 설정하고, padding은 요소의 안쪽 여백을 설정합니다.

margin 병합에 대해 설명해 주세요.

margin 병합 현상은 인접한 블록요소의 상하단 마진이 병합되는 현상을 의미하며, 그 크기는 두 마진 중 큰 값을 가진 마진의 값으로 병합됩니다.

이는 인접한 블록이 아닌 부모와 자식 요소 간에도 발생합니다.

부모에 margin을 0으로 설정하고 자식 요소의 margin을 10px로 설정하면, 자식요소의 상하단 margin이 부모의 margin으로 병합되어 마치 margin이 사라진 것 같은 현상이 발생합니다.

이런 현상을 막기 위한 대표적인 해결책으로 부모 요소에 overflow: hidden; 을 주는 방법이 있습니다.

Box model에 대해 설명해 주세요.

Box model은 HTML 요소를 바깥쪽부터 margin, border, padding, content로 나누는 것을 말합니다.

여기에서 height와 width는 content의 크기만을 의미합니다.

예시

‍ 콘텐츠를 시각적으로 숨기는 (그리고 screen reader에서만 사용할 수 있게 만드는) 방법에 대해 설명해 주세요.

width: 0; height: 0; : 요소가 화면에 어떤 공간도 차지하지 않도록 합니다. 결과적으로 보이지 않게 됩니다.
position: absolute; left: -99999px : 화면 외부에 배치합니다.
text-indent: -9999px : block인 요소 내의 텍스트에서만 작동합니다.

‍ screen이 아닌 @media 속성의 예를 들어줄 수 있나요?

네, @media 속성은 screen을 포함하여 4가지 타입이 있습니다.

all: 모든 미디어 기기 장치
print : 프린터
speech : 화면을 크게 읽는 스크린리더
screen : 컴퓨터 스크린, 태블릿, 스마트폰 등

**‍ * { box-sizing: border-box; }는 무엇을 하나요? 장점은 무엇인가요**?

기본적으로, 요소들에 box-sizing: content-box가 적용되면, 내용의 크기만 고려됩니다.

box-sizing: border-box는 요소의 width와 height가 어떻게 계산되는지를 변경하여, border와 padding도 계산에 포함됩니다.

요소의 height는 내용의 [height + 수직 padding + 수직 border 폭]으로 계산됩니다.
요소의 width는 내용의 [width + 수평 padding + 수평 border 폭]으로 계산됩니다.
padding과 border를 박스 모델의 일부분으로 생각하면, 디자이너가 실제로 생각하는 것과 잘 들어맞습니다.

⭐️ ‍ SCSS에 대해 설명해 주세요.

SCSS는 CSS과 완전히 호환되며 Sass의 모든 기능을 지원하는 CSS의 상위 집합입니다.

SCSS는 웹에서 직접 동작할 수 없으며, 이를 전처리기로 변환한 후 최종적으로 CSS를 적용해야 합니다.

⭐️ ‍ CSS의 display 속성은 무엇이 있으며 사용법에 대한 예시를 들어주세요.

display 속성은 요소 외부 레이아웃에 관여하는 속성과 내부에 관여하는 속성, 접근성을 위한 속성들이 있습니다.

외부 레이아웃에 관여하는 속성으로는 block, inline

내부 레이아웃에 관여하는 속성으로는 flow, table, flex, grid

접근성을 위한 속성으로는 none, contents 등이 있습니다.

이 외에도 inherit, initial 속성이 있습니다.

block과 inline-block 그리고 inline에 대해 구분해 주세요.

	block	inline-block	inline
크기	부모 컨테이너의 너비를 채웁니다.	내용에 의존합니다.	내용에 의존합니다.
위치	새 줄에서 시작하고, 그 옆에 HTML 요소를 허용하지 않습니다. (한 줄을 다 차지하며, float을 추가할 때는 제외)	다른 콘텐츠와 함께 흐르고, 다른 요소가 옆에 있는 것을 허용합니다.	다른 콘텐츠와 함께 흐르고, 다른 요소가 옆에 있는 것을 허용합니다.
width, height 지정 가능 여부	가능	가능	불가능
vertical-align 정렬 가능 여부	불가능	가능	가능
margin과 padding	모든 방향에서 가능	모든 방향에서 가능	수평 방향만 가능
Float	-	-	수직 margin과 padding을 설정할 수 있는 block 요소와 같아집니다.

⭐️ ‍ position 속성에 대해 설명해 주세요

CSS의 position 속성은 문서상에 요소를 배치하는 방법을 지정합니다.

relative: 요소의 위치가 레이아웃을 변경하지 않고, 자체에 상대적으로 조정됩니다. (따라서 배치되지 않은 요소의 간격을 남겨 둡니다.)
fixed: 문서 흐름에서 요소를 제거하고, viewport의 초기 컨테이닝 블록을 기준으로 배치합니다.
absolute: 문서 흐름에서 요소를 제거하고, 가장 가까운 위치가 지정된 부모요소에 대해 상대적으로 배치합니다.
static: 기본 위치이며, 요소가 평소와 같이 페이지에 위치하게 됩니다. top, right, bottom left, z-index 속성은 적용되지 않습니다.
sticky: 일반적인 문서 흐름에 따라 배치하고, 가장 가까운 스크롤이 되는 조상을 기준으로 배치합니다. 따라서 스크롤을 하게 되면 sticky를 사용하는 요소는 해당 공간을 차지하고 있으면서, 스크롤에서 제외하게 됩니다.

️ 출처

프론트엔드 면접 문제 은행 ★ Front-end Developer Interview Questions

A list of helpful front-end related questions you can use to interview potential candidates, test yourself or completely ignore.

h5bp.org

HTML 질문 | Front End Interview Handbook

프론트엔드 면접 질문 - HTML 질문에 대한 해설입니다. Pull Request를 통한 제안, 수정 요청 환영합니다.