Java

<blockquote>아이디 &amp; 비밀번호 없이 소셜로그인을 구현해보자</blockquote><h3>간편 로그인이란?</h3>: 비밀번호를 제공하지 않고 다른 웹사이트 서비스에 접근할 수 있는 접근성 위임 기능<img src="https://image.until.blog/mushroombud/article/1727372158903.png" alt="until-1572">이런 거 있잖아요저걸 만드는 명세의 표준이 바로 OAuth 2.0이다.<h2>왜 2.0인가?</h2><img src="https://image.until.blog/mushroombud/article/1727372474785.png" alt="until-1573">출처: Stackacademic이것만큼 OAuth 1.0과 2.0의 차이에 대해서 잘 설명한 그림이 없어서 들고와봤다. 사실 Token 교환을 보여주는 것이라면 더 잘 설명한 그림이 있겠으나, 이 그림을 좋아하는 이유는 "User Flow" 단위로 보여주기 때문이다. 브라우저가 되어서 플로우를 따라가면서 무슨 일이 일어나는지 체험할 수 있다.난 공식 Docs를 보는 <s>간지나는</s> 행동을 추구하는 사람이기 때문에 명세 표준을 보면서 한번 어떻게 동작하는 물건인지 이해해보자.<a target="_blank" rel="noopener noreferrer nofollow" href="https://datatracker.ietf.org/doc/html/rfc6750">RFC 6750-OAuth 2.0 Authorization Framework</a><img src="https://image.until.blog/mushroombud/article/1727372863726.png" alt="until-1574">개발자들답게 무슨 Flow도 아스키 아트로 그려놨다. 먼저 네 가지의 요소가 존재해야 하며, Client/Resource Owner/Authorization Server/Resource Server이 바로 그것이다. 이 그림은 유저와 서버 간의 관계가 아니라, 특정 서비스를 제공하는 서버와 인증 서버 간의 관계를 표현한 것이라는 데에 주의를 기울여야 한다.카카오톡 소셜로그인을 개발한다고 하자. 카카오톡 서버가 Resource Owner 겸 Authorization Server의 역할을 하고 (아마 리버스 프록시같은 걸 써서 도메인별로 분리를 할 것이다.) Client는 내가 이용하고자 하는 특정 서비스의 서버이다. 유저가 로그인 요청을 하면 카카오톡 로그인 페이지로 Redirection을 해 주고 Authorization을 요청해서 승인을 받은 다음, 이 승인을 다시 액세스 토큰으로 바꿔먹는다. 그 다음부터는 Access Token을 활용해 내 서비스의 서버가 카카오톡 리소스 서버에서 유저 정보에 관한 내용을 마음껏 빼먹을 수 있다.직접 개발한 서비스 중에 Graduart의 코드를 참고해보겠다. Google OAuth 2.0을 이용한 소셜로그인 기능이 구현되었다.먼저 프론트엔드 퍼블리싱 요소를 보자.<pre spellcheck="false"><code> return (
 &lt;div onClick={handleSignIn} align={"center"}&gt;
 &lt;img
 alt={"Google Login Button"}
 src={`/assets/googleLoginImg.png`}
 width={"50%"}
 &gt;&lt;/img&gt;
 &lt;/div&gt;
 );</code></pre><img src="https://image.until.blog/mushroombud/article/1727375283931.png" alt="until-1575">이렇게 구글 로그인 이미지를 가져오는 컴포넌트를 반환한다. 클릭시에 호출되는 handleSignIn함수가 중요한데, 로직을 살펴보면<pre spellcheck="false"><code class="language-javascript"> const handleSignIn = async (response) =&gt; {
 const { data, error } = await supabase.auth.signInWithOAuth({
 provider: "google",
 options: {
 redirectTo: import.meta.env.VITE_FRONT_URL,
 },
 });

 if (error) {
 console.error("Error signing in with Google:", error.message);
 } else {
 const { user } = data;
 if (user) {
 localStorage.setItem("supabase.auth.token", JSON.stringify(user));
 navigate("/");
 }
 }
 };</code></pre>supabase 백엔드를 활용했기 때문에, 관련 내용이 보인다. 우리 백엔드에 redirection URL을 포함해 "너 구글이랑 잘 연락해서 우리 유저 받아봐" 라는 요청을 날리라고 시키는 내용이다. 이 뒤에서 요청을 받은 후 일어나는 백엔드 로직을 살펴보자.(여기부터는 Supabase 코드 아님, 임의로 짠 코드) NestJS를 통해서 받아보자.<pre spellcheck="false"><code class="language-typescript">import { Injectable } from '@nestjs/common';
import { PassportStrategy } from '@nestjs/passport';
import { Strategy } from 'passport-oauth2';
import axios from 'axios';

@Injectable()
export class KakaoOAuthStrategy extends PassportStrategy(Strategy, 'kakao') {
 constructor() {
 super({
 authorizationURL: 'https://kauth.kakao.com/oauth/authorize',
 tokenURL: 'https://kauth.kakao.com/oauth/token',
 clientID: process.env.KAKAO_CLIENT_ID,
 clientSecret: process.env.KAKAO_CLIENT_SECRET,
 callbackURL: 'http://localhost:3000/auth/kakao/callback',
 });
 }

 async validate(accessToken: string, refreshToken: string, profile: any, done: Function) {
 try {
 const response = await axios.get('https://kapi.kakao.com/v2/user/me', {
 headers: {
 Authorization: `Bearer ${accessToken}`,
 },
 });

 const { id, kakao_account } = response.data;
 const user = {
 id,
 email: kakao_account.email,
 nickname: kakao_account.profile.nickname,
 };

 done(null, user);
 } catch (err) {
 done(err, false);
 }
 }
}</code></pre>먼저 src/auth/strategies/kakao.strategy.ts 파일을 생성한다. 이 파일을 적용시킬 모듈은<pre spellcheck="false"><code class="language-typescript">import { Module } from '@nestjs/common';
import { PassportModule } from '@nestjs/passport';
import { KakaoOAuthStrategy } from './strategies/kakao-oauth.strategy';
import { AuthController } from './auth.controller';

@Module({
 imports: [PassportModule.register({ defaultStrategy: 'kakao' })],
 controllers: [AuthController],
 providers: [KakaoOAuthStrategy],
})
export class AuthModule {}</code></pre>이렇게 만들어주면 된다. (Passport 패키지 설치 필요) 마지막으로 <pre spellcheck="false"><code class="language-typescript">import { Controller, Get, Req, UseGuards } from '@nestjs/common';
import { AuthGuard } from '@nestjs/passport';
import { Request } from 'express';

@Controller('auth')
export class AuthController {
 @Get('kakao')
 @UseGuards(AuthGuard('kakao'))
 async kakaoLogin() {
 // 카카오 로그인 페이지로 리디렉션합니다.
 }

 @Get('kakao/callback')
 @UseGuards(AuthGuard('kakao'))
 async kakaoLoginCallback(@Req() req: Request) {
 // 카카오 로그인 성공 후 리디렉션된 후 처리 로직
 const user = req.user;
 return {
 message: 'Kakao login successful',
 user,
 };
 }
}</code></pre>이렇게 짜주면 우리 백엔드에서 user을 반환하게 된다. JSON을 파싱하면 이렇게 생겼다. (동의항목을 통해 가져오는 추가 유저 정보에 대한 고려는 일단 하지 말자.)<pre spellcheck="false"><code>{
 id: 1234567890,
 email: 'user@example.com',
 nickname: '새싹버섯'
}</code></pre>ID의 경우 카카오 서버에서 내부적으로 유저들에게 부여하는 고유 ID이다. 뭔가 남의 서비스 DB에 있는 은밀한 정보를 빼내오는 느낌이라 내 ID가 궁금해지는 부분이다.NestJS를 잘 알지 못하지만 지금 개발중인 서비스가 NestJS를 써야 해서 공부하면서 코드를 가져와봤는데, @UseGuards 데코레이터를 처음 봐서 좀더 알아보았다. &nbsp;Guard는 HTTP 요청이 처리되기 전에 실행되어, 특정 요청에 대한 접근을 허용하거나 거부하는 역할을 한다. 클라이언트가 요청을 보내면 해당 Guard가 먼저 실행되어 인증 또는 권한을 검증한 후에, 요청을 처리할 수 있는지 여부를 결정하는 방식이라고 한다.카카오톡을 예시로 OAuth 2.0을 이용한 간편로그인의 개념과 진행과정, 그리고 백엔드단에서 필요한 코드에 대해 간략히 알아봤다. 앞으로 잘 써먹어야겠다.

카카오톡을 예시로 알아보는 OAuth 2.0의 개념, 소셜로그인 처리를 위한 백엔드 구현 Abstract

간편 로그인(OAuth 2.0) 3분만에 정복하기

일상

Kafka

Convention

Spring

⚛️ React

<img src="https://image.until.blog/morethanmin/article/1716912103640" alt="until-344"><blockquote>next.js 의 pages router 기준으로 작성되었어요.</blockquote>next.js서버사이드에서 데이터를 prefetch하기 위해서 리액트쿼리에서 제안하는 방식은 크게 두가지가 존재한다.<ol><li>데이터 패칭을 한 뒤에 <code spellcheck="false">serverSideProps</code>의 props로 넘겨주는 방식</li><li>서버사이드에서 <code spellcheck="false">queryClient</code>에 데이터를 저장하고, <code spellcheck="false">queryClient</code>자체를 <code spellcheck="false">dehydrate</code>하여 넘겨주는 <code spellcheck="false">Hydration</code> 방식</li></ol>첫번째 방식은 비교적 간단하지만 props drilling이나 여러곳에서 사용할 경우 initialData를 넣어주는 것이 까다롭다는 단점이 있다.때문에 프리패칭하는 데이터가 여러곳에 존재하고, 복잡할 경우 두번째 방식을 사용하는 것이 좋을것이다.<code spellcheck="false">Hydration</code>방식을 사용하기 위해서는 <code spellcheck="false">fetchQuery</code>와 <code spellcheck="false">prefetchQuery</code>의 차이점을 알아보자.<h1>prefetchQuery</h1>prefetchQuery는 결과값을 리턴하지 않으며, 데이터 패칭에 실패할 경우 에러를 던지지 않는다는 특징을 가지고 있다.따라서 데이터를 불러오지 못하더라도, UI를 그려줄 수 있는 경우에는 prefetchQuery를 사용하면 된다.<pre spellcheck="false"><code class="language-typescript">// ...
await queryClient.prefetchQuery({
 queryKey: queryKeys.articles()
 queryFn: getArticles()
});
// ...</code></pre><h1>fetchQuery</h1>fetchQuery와 같은 경우에는 결과값을 리턴하고, 데이터 패칭에 실패하는 경우에는 에러를 던진다.따라서 error handling이 가능하다는 얘기이다.언틸에서의 블로그 프로필 페이지를 예로 들어보자.<pre spellcheck="false"><code class="language-typescript">export const getServerSideProps: GetServerSideProps = async (context) =&gt; {
 try {
 setCookie(context)
 const username = getUsername(context)await queryClient.fetchQuery({
 queryKey: queryKeys.blog.username.body(username),
 queryFn: createGetBlog(username),
 })
 return {
 props: {
 dehydratedState: dehydrate(queryClient),
 },
 }} catch (error) {
 return {
 notFound: true,
 }
 }
}</code></pre>블로그를 조회하는 api는 잘못된 username으로 요청하는 경우 404 페이지를 보여줘야 하기에 <code spellcheck="false">fetchQuery</code>를 통해 구현해주었다.또한 return value를 사용하는 경우에도 fetchQuery를 사용해 구현해줄 수 있다.

next.js 의 pages router 기준으로 작성되었어요.next.js서버사이드에서 데이터를 prefetch하기 위해서 리액트쿼리에서 제안하는 방식은 크게 두가지가 존재한다.데이터 패칭을 한 뒤에 serverSideProps의 props로 넘겨주는 방식서버사이드에서 queryClient에 데이터를 저장하고, queryClient자체를 dehydrate

react-query의 fetchQuery과 prefetchQuery

개발을 하다보면 로컬에서 https환경이 필요한 경우들이 생기게된다. 주로 쿠키를 다룰 때 생기는데 이러한 개발환경을 <a target="_blank" rel="noopener noreferrer nofollow" href="https://github.com/FiloSottile/mkcert">mkcert</a>를 통해 쉽게 만들 수 있다.https가 무엇인지, 인증서가 어떤 역할을 하는지에 대해서 궁금한 사람은 <a target="_blank" rel="noopener noreferrer nofollow" href="https://opentutorials.org/course/228/4894">해당 아티클</a>을 읽어보자.해당 아티클에서는 next.js에서 mkcert를 통해서 https 개발환경 세팅하는 과정을 다룰 것이다.<h1>mkcert?</h1>레포에서는 아래와 같이 설명하고 있다.<blockquote>A simple zero-config tool to make locally trusted development certificates with any names you'd like.</blockquote>해당 내용처럼 mkcert는 로컬 개발환경에서 사용할 수 있는 인증서를 별다른 설정없이 손쉽게 만들 수 있다.<h1>mkcert 설치</h1><h2>window</h2><code spellcheck="false">readme.md</code> 상으로는 choco나 scoop를 사용해서 설치하는 것을 권하지만, 내장되어있는 winget을 사용하면 별다른 프로그램 없이 바로 설치가 가능하다.아래 명령어를 입력해주자.<pre spellcheck="false"><code>winget install mkcert</code></pre><h2>mac</h2>homebrew로 설치해주면 된다.<pre spellcheck="false"><code>brew install mkcert</code></pre><hr>설치가 끝났다면 아래 커맨드를 통해 local ca를 설치해준다.<pre spellcheck="false"><code>mkcert -install</code></pre><h1>인증서 생성 및 적용</h1><h2>로컬 도메인 적용</h2>특정 도메인에 대해서 https를 적용해주어야하기 때문에 hosts 파일을 수정해주어야한다.본인의 로컬아이피로 접속했을 때 사용할 도메인을 hosts파일에 저장해주자. 윈도우는 기본적으로 <code spellcheck="false">c:\Windows\System32\drivers\etc</code>, mac은<code spellcheck="false">/private/etc/hosts</code> 에 위치하고 있으니 해당 파일을 수정해주면 될 것이다.나는 dev.until.blog를 적용했다.<pre spellcheck="false"><code># Copyright (c) 1993-2009 Microsoft Corp.
#
# This is a sample HOSTS file used by Microsoft TCP/IP for Windows.
#
# This file contains the mappings of IP addresses to host names. Each
# entry should be kept on an individual line. The IP address should
# be placed in the first column followed by the corresponding host name.
# The IP address and the host name should be separated by at least one
# space.
#
# Additionally, comments (such as these) may be inserted on individual
# lines or following the machine name denoted by a '#' symbol.
#
# For example:
#
# 102.54.94.97 rhino.acme.com # source server
# 38.25.63.10 x.acme.com # x client host
localhost name resolution is handled within DNS itself.127.0.0.1 localhost::1 localhost127.0.0.1 dev.until.blog</code></pre><h2>next local server 연동</h2>이제 next.js 프로젝트에서 인증서를 적용해보자. 본인 next 프로젝트에서 아래 커멘드를 입력해 인증서와 pem 파일을 생성해주자. dev.until.blog에는 본인이 특정한 도메인을 입력하면 된다.<pre spellcheck="false"><code>mkcert dev.until.blog</code></pre><a target="_blank" rel="noopener noreferrer nofollow" href="https://nextjs.org/docs/pages/building-your-application/configuring/custom-server">next custom server</a>를 통해 생성된 파일을 연결해주면된다.<pre spellcheck="false"><code class="language-javascript">// server.jsconst { parse } = require('url')
const next = require('next')const dev = process.env['NODE_ENV'] !== 'production'
const app = next({ dev })
const handle = app.getRequestHandler()const PORT = process.env['PORT'] || 3050app.prepare().then(() =&gt; {
const https = require('https')
const fs = require('fs')
const options = {
key: fs.readFileSync('./dev.until.blog-key.pem'),
cert: fs.readFileSync('./dev.until.blog.pem'),
}
https
.createServer(options, function (req, res) {
// Be sure to pass true as the second argument to url.parse.
// This tells it to parse the query portion of the URL.
const parsedUrl = parse(req.url, true)
handle(req, res, parsedUrl)
})
.listen(PORT, (err) =&gt; {
if (err) throw err
console.log(&amp;gt; Ready on https://dev.until.blog:${PORT})
})
})</code></pre>이제 package.json에 해당 <code spellcheck="false">dev:https</code>스크립트를 추가해주고 실행하면 끝.<pre spellcheck="false"><code> ....."scripts": {
"dev": "next dev -p 3050",
"dev:https": "node --inspect server.js ",
"build": "next build",
"start": "next start",
"lint": "next lint"
},.....</code></pre>

개발을 하다보면 로컬에서 https환경이 필요한 경우들이 생기게된다. 주로 쿠키를 다룰 때 생기는데 이러한 개발환경을 mkcert를 통해 쉽게 만들 수 있다.https가 무엇인지, 인증서가 어떤 역할을 하는지에 대해서 궁금한 사람은 해당 아티클을 읽어보자.해당 아티클에서는 next.js에서 mkcert를 통해서 https 개발환경 세팅하는 과정을 다룰 것이

next.js 로컬 환경에서 https 개발 환경 만들기 (mkcert)

<h2>JSX란?</h2><pre spellcheck="false"><code class="language-jsx">const element = &lt;h1&gt;Hello, world!&lt;/h1&gt;;
</code></pre><blockquote>JSX(JavaScript XML), JavaScript에 XML을 추가하여 확장한 문법</blockquote><h3>브라우저는 JSX를 알고있을까?</h3>JSX가 포함된 코드를 아무런 처리 없이 그대로 실행하면 에러가 발생한다.JSXS는 자바스크립트 표준 코드가 아닌 페이즈북이 임의로 만든 새로운 문법이기 때문에 반드시 트랜스파일러를 거쳐야 비로소 자바스크립트 런타임이 이해할 수 있는 의미있는 코드로 변환된다.JSX는 어떻게 자바스크립트로 변환될까?우선 JS가 JSX로 변환되는 방식을 알려면 리액트에서 JSX를 변환하는 <code spellcheck="false">@babel/plugin-transform-react-jsx</code>플러그인을 알아야 한다.이 플러그인은 JSX 구문을 자바스크립트가 이해할 수 있는 형태로 변환한다.<pre spellcheck="false"><code class="language-jsx">// JSX
const element = (
 &lt;h1 className="greeting"&gt;
 Hello, world!
 &lt;/h1&gt;
);

// JS로 변환된 JSX
const element = React.createElement(
 'h1',
 {className: 'greeting'},
 'Hello, world!'
);
</code></pre><h3>JSX의 설계 목적</h3>다양한 트랜스파일러에서 다양한 속성을 가진 트리 구조를 토큰화해 ECMAScript로 변환하는데 초점을 두고 있다.<ul class="tight" data-tight="true"><li>트리 구조로 표현하고 싶은 다양한 것들을 작성</li><li>HTML, XML이외에도 다른 구문으로도 확장될 수 있도록, 개발자들에게 친숙함을 느낄 수 있기 위해</li></ul><h2>JSX 정의</h2><h3>1. JSXElement</h3><blockquote>JSX를 구성하는 가장 기본적인 요소로, HTML element와 비슷한 역할을 한다.</blockquote><ul class="tight" data-tight="true"><li>JSXOpeningElement: &lt;div&gt;</li><li>JSXClosingElement: &lt;/div&gt;</li><li>JSXSelfClosingElement: &lt;div /&gt;</li><li>JSXFragment: &lt;&gt;&lt;/&gt;</li></ul>❓ 컴포넌트 명이 대문자로 시작해야 하는 이유는 무엇인가요?리액트에서 HTML 구문 이외 사용자 정의 컴포넌트는 반드시 대문자로 시작해야 사용가능하다. 이는 HTML 태그명과 사용자가 만든 컴포넌트 태그명을 구분 짓기 위해서다.<pre spellcheck="false"><code class="language-jsx">// HTML 태그명
&lt;span&gt;&lt;/span&gt;
// 컴포넌트명
&lt;Span&gt;&lt;/Span&gt;
</code></pre>JSXElementName<blockquote>JSXElement의 요소 이름으로 쓸 수 있는 것을 의미한다.</blockquote><ul class="tight" data-tight="true"><li>JSXIdentifier: <code spellcheck="false">$</code>와<code spellcheck="false">_</code> 외에 다른 특수문자나 숫자로 시작할 수 없다.</li><li>JSXNamespacedName: JSXIdentifier:JSXIdentifier의 조합, 두 개 이상은 불가</li><li>JSXMemberExperssion: JSXIdentifier.JSXIdentifier의 조합, 두 개 이상 가능</li></ul><h3>2. JSXAttributes</h3><blockquote>JSXElement에 부여할 수 있는 속성을 의미한다. 필수값이 아니고, 존재하지 않아도 에러가 발생하지 않는다.</blockquote><ul><li>JSXSpreadAttributes<ul class="tight" data-tight="true"><li>{…AssignmentExpression}</li><li>단순히 객체뿐만 아니라 자바스크립트에서 AssignmentExpression로 취급되는 모든 표현식 존재 가능<ul class="tight" data-tight="true"><li>조건문 표현식</li><li>화살표 함수</li><li>할당식</li></ul></li></ul></li><li>JSXAttribute<ul><li>JSXAttributeName - JSXAttributeValue로 짝을 이루어 표현</li><li>JSXAttributeName: 속성의 키 값</li><li>JSXAttributeValue<ul><li>큰 따옴표로 구성된 문자열</li><li>작은 따옴표로 구성된 문자열</li><li>{ AssignmentExpression }</li><li>JSXElement: 값으로 다른 JSX요소가 들어갈 수 있다.&lt;aside&gt; 💡 값을 전달할 때 { }로 감싸는게 리액트의 문법으로 오해하는 개발자들이 있다.이는 리액트의 문법이 아닌 prettier의 규칙이다. prettier 규칙은 태그가 포함된 JSX 구문을 좀 더 읽기 쉽게 만들기 위해 제공된다.<pre spellcheck="false"><code class="language-jsx">&lt;div attribute=&lt;div&gt;hello&lt;/div&gt; /&gt;
&lt;div attribute={&lt;div&gt;hello&lt;/div&gt;} /&gt;
</code></pre>&lt;/aside&gt;</li><li>JSXFragment</li></ul></li></ul></li></ul><h3>3. JSXChildren</h3><blockquote>JSXElement의 자식 값을 나타낸다.</blockquote><ul><li>JSXChild: JSXChildren을 이루는 기본 단위다. JSXChildren은 JSChild가 없어도 상관없다.<ul><li>JSXText: 문자열</li><li>JSXElement: 다른 JSX요소</li><li>JSXFragment: 빈 요소</li><li>{JSXChildExpression (optional)}<pre spellcheck="false"><code class="language-jsx">// 해당 컴포넌트를 렌더링하면 "foo"라는 문자열이 출력된다.
return &lt;&gt;{(()=&gt; 'foo')()}&lt;/&gt;
</code></pre></li></ul></li></ul><h3>4. JSXStrings</h3><blockquote>HTML에서 사용 가능한 문자열은 모두 JSXStrings에서도 가능하다.</blockquote><ul class="tight" data-tight="true"><li>큰따옴표로 구성된 문자열</li><li>작은 따옴표로 구성된 문자열</li><li>JSXText</li></ul>💡 자바스크립트와는 한 가지 중요한 차이점이 발생하는데 바로 <code spellcheck="false">\\</code> 로 시작하는 이스케이프 문자 형태소다.<code spellcheck="false">\\</code> 는 자바스크립트에서 특수문자를 처리할 때 사용되므로 몇 가지 제약사항이 있지만, HTML에서 아무런 제약없이 사용할 수 있다.따라서 JSX에서는 HTML처럼 <code spellcheck="false">\\</code>을 이스케이프 문자열로 처리하고 있지 않다.<h2>마무리</h2>이처럼 JSX는 자바스크립트 코드 내부에 HTML과 같은 트리 구조를 가진 컴포넌트를 표현할 수 있다는 점에 각광받고 있다.물론 JSX가 HTML문법과 자바스크립트 문법이 뒤섞여서 코드의 가독성을 해친다는 의견도 있다. JSX 내부에 자바스크립트 문법이 많아질수록 복잡성이 증대하면서 코드의 가독성도 해칠 것이므로 주의해서 사용해야 한다.

2장 리액트 핵심 요소 깊게 살펴보기

2-1. JSX란?

<h2>DOM과 브라우저 렌더링 과정</h2>DOM은 웹 페이지에 대한 인터페이스로 브라우저가 웹 페이지의 콘텐츠와 구조를 어떻게 보여줄지에 대한 정보를 담고 있다.<ol><li>HTML 파일 다운로드</li><li>브라우저 렌더링 엔진은 HTML을 파싱해 DOM노드로 구성된 트리를 만든다.</li><li>2번 과정에서 CSS 파일을 만나면 해당 CSS 파일도 다운로드한다.</li><li>브라우저 렌더링 엔진은 이 CSS도 파싱해 CSS 노드로 구성된 트리를 만든다.</li><li>2번에서 만든 DOM 노드를 순회하는데, 여기서 모든 노드를 방문하는 것이 아닌 사용자 눈에 보이는 노드만 방문한다. 즉, <code spellcheck="false">display:none;</code>과 같이 사용자 화면에 보이지 않는 요소는 방문하지 않는다.→ 트리를 분석하는 과정을 조금이라도 빠르게 하기 위해서</li><li>5번에서 제외된, 눈에 보이는 노드들 대상으로 CSS 스타일 정보를 노드에 적용한다.<ul class="tight" data-tight="true"><li>레이아웃: 각 노드가 브라우저 화면의 어느 좌표에 정확히 나타나야 하는지 계산하는 과정<ul class="tight" data-tight="true"><li>레이아웃 과정을 거치면 반드시 페인팅 과정도 거치게 됨</li></ul></li><li>페인팅: 레이아웃 단계를 거친 노드에 색과 같은 실제 유효한 모습을 그리는 과정</li></ul></li></ol><h3>reflow(layout)</h3><blockquote>뷰포트 내에서 렌더 트리상 노드의 정확한 위치와 크기를 계산하는 과정이다.</blockquote><ul class="tight" data-tight="true"><li>윈도우 리사이징</li><li>폰트 변화</li><li>스타일 추가 또는 제거</li><li>:hover와 같은 CSS Pseudo Class(의사 클래스)</li><li>JS를 통한 DOM 동작 변화</li><li>등등..</li></ul><h3>reflow 최적화</h3><ol><li>인라인 스타일 자제인라인 스타일은 HTML이 파싱될 때, 레이아웃에 영향을 미쳐 추가 리플로우를 발생시킨다.</li><li>js를 통해 스타일 변화를 주어야할 경우 가급적 한번에 처리해라.특정 요소에 여러 스타일 변화를 지정해야 할 경우 한번에 처리하면 중복된 reflow를 최소화할 수 있다.<pre spellcheck="false"><code class="language-jsx">var toChange = document.getElementById('elem');
toChange.style.background = '#333';
toChange.style.color = '#fff';
toChange.style.border = '1px solid #ccc';
</code></pre><pre spellcheck="false"><code class="language-jsx">/* CSS */
#elem { border:1px solid #000; color:#000; background:#ddd; }
.highlight { border-color:#00f; color:#fff; background:#333; }
/* js */
document.getElementById('elem').className = 'highlight';
</code></pre></li><li>하위 선택자를 최소화 한다.CSS 하위 선택자를 최소화 하는 것이 렌더링 성능에 더 좋다.CSS 하위 선택자가 많아지면 CSSOM 트리의 깊이(Depth)가 깊어지게 되고 결국 렌더 트리를 만드는 시간이 더 오래 걸리게 된다.<pre spellcheck="false"><code class="language-jsx">/* 잘못된 예 */
.reflow_box .reflow_list li .btn{
 display:block;
}
/* 올바른 예 */
.reflow_list .btn {
 display:block;
}
</code></pre></li><li>숨겨진 노드의 스타일을 변경한다.<code spellcheck="false">display: none</code> 으로 숨겨진 노드를 변경할 때는 reflow가 발생하지 않는다. 숨겨진 노드를 표시하기 전에 노드의 컨텐츠를 먼저 변경한 후 화면에 나타내면 reflow를 줄일 수 있다.</li></ol><h3>repaint</h3><blockquote>레이아웃에 영향을 미치지 않고 요소의 외관을 변경하는 과정이다</blockquote><ul class="tight" data-tight="true"><li>요소 색상 지정 (background-color, color)</li><li>visibility</li></ul><a target="_blank" rel="noopener noreferrer nofollow" href="https://devowen.com/463">Reflow와 Repaint에 대하여</a><a target="_blank" rel="noopener noreferrer nofollow" href="https://csstriggers.com/">CSS Triggers List - What Kind of Changes You Can Make</a><h3>CLS (Cumulative Layout Shift) → 누적 레이아웃 시프트</h3><blockquote>Layout Shift란 페이지 콘텐츠가 예기치 않게 이동하는 현상이다.</blockquote>보통 리소스가 비동기 식으로 로드되거나 DOM 요소가 동적으로 추가되어 발생한다.<blockquote>CLS는 페이지 수명 동안 발생하는 모든&nbsp;<a target="_blank" rel="noopener noreferrer nofollow" href="https://web.dev/articles/cls?hl=ko#expected-unexpected-layout-shifts">예상치 못한</a>&nbsp;레이아웃 변경에 관한&nbsp;레이아웃 변경 점수의 가장 큰 버스트를 측정한 것입니다. → layout shift 현상을 측정한 것</blockquote>계산방법<blockquote>브라우저는 표시 영역 크기 및 렌더링된 두 프레임 간 표시 영역 내 불안정한 요소의 이동을 고려합니다.</blockquote>레이아웃 변경 점수는 이동의 두 가지 측정값, 즉&nbsp;영향 비율과&nbsp;거리 비율의 곱입니다. = 영향 비율 * 거리 비율<pre spellcheck="false"><code class="language-jsx">layout shift score = impact fraction * distance fraction
</code></pre>기존 영역 = 50%이동된 거리 비율 = 25%영향 비율 = 75%0.75 * 0.25 = 0.1875의 레이아웃 변경 점수 측정💡 좋은 CLS 점수는 0.1 이하여야 한다.<a target="_blank" rel="noopener noreferrer nofollow" href="https://web.dev/articles/cls?hl=ko">Cumulative Layout Shift (CLS) &nbsp;|&nbsp; Articles &nbsp;|&nbsp; </a><a target="_blank" rel="noopener noreferrer nofollow" href="http://web.dev">web.dev</a><h2>Virtual DOM (가상 돔)</h2><h3>가상돔의 배경</h3>앞서 본것처럼 브라우저가 웹 페이지를 렌더링 하는 과정은 매우 복잡하고 많은 비용이 든다.MPA의 경우는 다른 페이지로 가서 처음부터 HTML을 새로 받아서 다시금 렌더링 과정을 시작한다. 하지만 SPA의 경우 계속해서 요소의 위치를 재계산하기 때문에 렌더링 이후 추가 렌더링 작업이 많아진다.SPA는 하나의 페이지로 페이지 이동 깜빡임 없이 자연스러운 탐색이 가능하지만, 그만큼 DOM을 관리하는 과정에서 부담해야 할 비용이 커진다.개발자 입장에서 생각해보면 개발자는 인터렉션에 모든 DOM의 변경보다는 결과적으로 만들어지는 DOM 결과물 하나만 알고 싶을 것이다. 이러한 문제점을 해결하기 위해 탄생한 것이 바로 가상 DOM이다.<h3>가상돔</h3><blockquote>가상 DOM은 실제 브라우저의 DOM이 아닌 리액트에서 관리하는 가상의 <s>DOM</s> 객체을 의미한다.</blockquote>가상 DOM은 웹페이지가 표시해야 할 DOM을 일단 메모리에 저장하고, 리액트가 실제 변경에 대한 준비가 완료됐을 때 실제 브라우저의 DOM에 반영한다.💡 리액트의 이러한 방식이 일반적인 DOM을 관리하는 브라우저보다 빠르다는 오해가 있다.가상 DOM 방식은 브라우저 DOM보다 무조건 빠른 것이 아니라 웬만한 애플리케이션을 만들 수 있을 정도로 충분히 빠르다는 것이다.<h2>리액트 파이버</h2>그렇다면 이러한 가상 DOM을 만드는 과정을 리액트에서 어떻게 처리하고 있을까?이러한 가상 DOM과 렌더링 과정 최적화를 가능하게 해주는 것이 바로 리액트 파이버다.<h3>리액트 파이버란?</h3><blockquote>리액트에서 관리하는 평범한 자바스크립트 객체다.<ul class="tight" data-tight="true"><li>파이버 재조정자에 의해 관리된다.</li><li>재조정이라는 용어는 가상 DOM과 실제 DOM을 비교하는 작업(알고리즘)이라고 이해하면 된다.</li></ul></blockquote><ul class="tight" data-tight="true"><li>가상 DOM과 실제 DOM을 비교하며 변경사항을 수집한다<ul class="tight" data-tight="true"><li>이 둘 사이에 차이가 있으면 변경에 관련된 정보를 가지고 있는 파이버를 기준으로 화면에 렌더링을 요청한다.</li></ul></li></ul><h3>파이버의 배경</h3>파이버는 다음과 같은 일을 할 수 있다.<ol class="tight" data-tight="true"><li>작업을 작은 단위로 분할하고 쪼갠 다음, 우선순위를 매긴다.</li><li>이러한 작업을 일시중지하고 나중에 다시 시작할 수 있다.</li><li>이전에 했던 작업을 다시 재사용하거나 필요하지 않은 경우에는 폐기할 수 있다.</li></ol>💡 여기서 중요한 것은 이러한 모든 과정이 비동기로 일어난다는 것이다.과거의 알고리즘이전에는 조정 알고리즘이 스택 알고리즘으로 이루어있었다.렌더링에 필요한 작업이 쌓이면 해당 스택이 빌 때 까지 동기적으로 작업이 이루어지게 된다.한계자바스크립트의 특징인 싱글 스레드라는 점으로 인해 동기 작업이 중단될 수 없고, 다른 우선순위가 높은 작업이 수행되고 싶어도 중단할 수 없어 리액트의 비효율성으로 이어졌다.이러한 기존 렌더링 스택의 비효율성을 해결하기 위해 파이버라는 개념이 탄생된 것이다.<h3>파이버의 동작 과정(리액트의 생명주기)</h3><ol class="tight" data-tight="true"><li>파이버는 일단 하나의 작업 단위로 구성되어 있다.</li><li>이러한 작업 단위를 하나씩 처리하고 <code spellcheck="false">finishedWork()</code> 라는 작업으로 마무리 한다.</li><li>이 작업을 커밋해 실제 브라우저 DOM에 가시적인 변경사항 만들어 낸다.</li></ol>이러한 단계는 다음 두 단계로 나눌 수 있다.<ul><li>렌더 단계랜더 단계에서 사용자에게 노출되지 않는 모든 비동기 작업을 수행한다. 앞서 말한 파이버의 작업, 우선순위 지정/중지/삭제 등의 작업이 일어난다.</li><li>커밋 단계DOM에 실제 변경 사항을 반영하기 위한 작업니다.<code spellcheck="false">commitWork()</code>가 동기적으로 실행되어 해당 과정은 중단될 수 없다.</li></ul>💡 파이버의 실제 구조를 보면 리액트의 요소와 유사하다고 느낄 수 있지만, 중요한 차이점은 리액트 요소는 렌더링이 발생할 때 마다 새롭게 생성되지만, 파이버는 가급적이면 재사용된다는 사실이다.파이버는 컴포넌트가 최초로 마운트되는 시점에 생성되어 이후에는 가급적이면 재사용된다.<ol class="tight" data-tight="true"><li>state가 변경</li><li>생명주기 메서드가 실행</li><li>DOM의 변경이 필요한 시점</li></ol>등에 실행된다.최적화<ul class="tight" data-tight="true"><li>작은 단위로 나눠서 처리</li><li>우선순위가 높은 작업은 가능한 한 바르게 처리</li><li>낮은 작업을 연기</li></ul>시키는 등 좀 더 유연하게 처리된다.<h3>리액트 파이버 트리</h3>파이버 트리는 리액트 내부에서 두 개가 존재한다.<ol class="tight" data-tight="true"><li>현재 모습을 담은 파이버 트리</li><li>작업 중인 상태를 나타내는 <code spellcheck="false">workInProgress</code> 트리</li></ol>리액트 파이버 작업이 끝나면 리액트는 단순히 <code spellcheck="false">workInProgress</code> 트리를 현재 트리로 변경한다.이러한 기술을 더블 버퍼링이라고 한다.그래픽 처리의 문제점그래픽을 통해 화면에 표시되는 것을 그리기 위해서 내부적으로 처리하던 중, 사용자에게 미처 다 그리지 못한 모습을 보는 경우가 발생하게 된다.(한번에 모든 작업을 마무리할 수 없기 때문)더블 버퍼링?그래서 이러한 상황을 방지하기 위해 보이지 않는 곳에서 그림을 미리 그린 다음, 해당 그림이 완성되면 현재 상태를 새로운 그림으로 바꾸는 기법을 의미한다.리액트에서도 마찬가지로 불완전한 트리를 노출시키지 않도록 더블 버퍼링 기법을 사용한다. 이러한 더블 버퍼링을 위해 두개의 트리가 존재하며, 더블 버퍼링은 커밋 단계에서 수행된다.즉, 먼저 현재 렌더링을 위해 존재하는 트리인 current를 기준으로 모든 작업이 시작된다.<ol class="tight" data-tight="true"><li>업데이트가 발생하면, 파이버는 리액트에서 새로 받은 데이터로 새로운 <code spellcheck="false">workInProgress</code> 트리 빌드</li><li><code spellcheck="false">workInProgress</code> 빌드가 완료되면, 다음 렌더링에 해당 트리를 사용한다.</li><li><code spellcheck="false">workInProgress</code> 트리가 UI에 최종적으로 렌더링이 반영되면</li><li>current가 <code spellcheck="false">workInProgress</code>로 변경된다.</li></ol><h3>파이버의 작업 순서</h3><ol class="tight" data-tight="true"><li>리액트는 <code spellcheck="false">beginWork()</code> 함수를 실행해 파이버 작업을 수행하는데, 더 이상 자식이 없는 파이버를 만날 때 까지 트리 형식으로 시작된다.</li><li>1번에서 작업이 긑난다면 그 다음 <code spellcheck="false">completeWork()</code> 함수를 실행해 파이버 작업을 완료한다.</li><li>형제가 있다면 형제로 넘어간다.</li><li>2, 3번이 끝났다면 return으로 돌아가 자신의 작업이 완료됐음을 알린다. → <code spellcheck="false">commitWork()</code>가 수행되어 변경사항이 DOM에 반영</li></ol>이제 여기서 setState 등으로 업데이트가 발생하면 어떻게 될까?<ol class="tight" data-tight="true"><li>앞서 만든 current 트리가 존재함</li><li>setState로 인한 업데이트 요청을 받아 <code spellcheck="false">workInprogress</code> 트리를 다시 빌드하기 시작한다.</li><li>최초 렌더링 시에는 모든 파이버를 새롭게 만들어야 했지만, 최초 렌더링 이후에는 파이버가 이미 존재하므로 되도록 새로 생성하지 않고 기존 파이버에서 업데이트된 props를 받아 파이버 내부에서 처리한다.</li></ol>💡 가급적 새로운 파이버를 생성하지 않는다.새롭게 파이버 자바스크립트 객체를 만드는 것은 리소스 낭비라고 볼 수 있다.<h2>마무리</h2>컴포넌트에 대한 정보를 1:1로 가지고 있는 것이 파이버이며, 이 파이버는 내부에서 비동기로 이루어진다.실제 브라우저 구조인 DOM에 반영하는 것은 동기적으로 일어난다.또 처리하는 작업이 많을 때 DOM 트리가 불완전할 수 있으므로, 메모리상에서 먼저 수행 후 최종적인 결과물만 실제 브라우저 DOM에 적용한다.💡 화면에 표시되는 자바스크립트의 문자열, 배열 등과 마찬가지로 값으로 관리하고 이러한 흐름을 효율적으로 관리하기 위한 메커니즘이 바로 리액트의 핵심이다. (값으로 UI를 표현하는 것)<h3>새로 알게 된 점</h3><ul class="tight" data-tight="true"><li>CLS의 계산 방법</li><li>reflow 최적화 방법</li><li>파이버의 두가지 동작 과정 (렌더/커밋 단계)</li><li>더블 버퍼링</li></ul>

2-2. 가상 DOM과 리액트 파이버

<h2>파일 경로</h2>project {	back{	}	front {		main.html		script.js		style.css	}	node_modules {		. . .	}	package-lock.json	package.json	server.js}<h2>front/main.html</h2><pre spellcheck="false"><code class="language-html">&lt;!DOCTYPE html&gt;
&lt;html lang="ko"&gt;
&lt;head&gt;
 &lt;meta charset="UTF-8"&gt;
 &lt;meta name="viewport" content="width=device-width, initial-scale=1.0"&gt;
 &lt;title&gt;펜션 사이트&lt;/title&gt;
 &lt;link rel="stylesheet" type="text/css" href="style.css"&gt;
&lt;/head&gt;
&lt;body&gt;
 . . .
 &lt;script src="script.js"&gt;&lt;/script&gt;
&lt;/body&gt;
&lt;/html&gt;
</code></pre><h2>server.js</h2><pre spellcheck="false"><code class="language-javascript">const express = require('express')
const app = express()
const port = 8080
const path = require('path');

app.get('/', (req, res) =&gt; {
 res.sendFile(path.join(__dirname, 'front', 'main.html'));
});

app.listen(port, () =&gt; {
 console.log(`Example app listening on port ${port}`)
})</code></pre>

파일 경로project {	back{	}	front {		main.html		script.js		style.css	}	node_modules {		. . .	}	package-lock.json	package.json	server.js}front/main.html&lt;!DOCTYPE html&gt;
&lt;html lang="ko"&gt;
&lt;head&

express.js에서 css가 로딩이 안됨

nextjs

저의 경우에는 그래도 결국  useSearchParams을 사용하는 부분을 따로 분리해서 Suspense로 감싸주지 않으면 의도는 서버 컴포넌트로 동작하도록 설계했는데, 빌드해보니 클라이언트로 동작하게 돼서 예상치 못한 동작이 일어나더라구요

https://nextjs.org/docs/messages/deopted-into-client-rendering