VIKING_J https://velog.io/ 모험을 떠나보자 Tue, 05 Aug 2025 06:24:29 GMT https://validator.w3.org/feed/docs/rss2.html https://github.com/jpmonette/feed VIKING_J https://velog.velcdn.com/images/jay_chae/profile/a68241f5-3635-4bc6-9eab-6492dd4d5b56/image.jpeg https://velog.io/ Copyright (C) 2019. VIKING_J. All rights reserved. <![CDATA[FOUC 해결을 위한 `PreventFlash` 컴포넌트: 다크 모드 전환 시 깜빡임 방지]]> https://velog.io/@jay_chae/FOUC-%ED%95%B4%EA%B2%B0%EC%9D%84-%EC%9C%84%ED%95%9C-PreventFlash-%EC%BB%B4%ED%8F%AC%EB%84%8C%ED%8A%B8-%EB%8B%A4%ED%81%AC-%EB%AA%A8%EB%93%9C-%EC%A0%84%ED%99%98-%EC%8B%9C-%EA%B9%9C%EB%B9%A1%EC%9E%84-%EB%B0%A9%EC%A7%80 https://velog.io/@jay_chae/FOUC-%ED%95%B4%EA%B2%B0%EC%9D%84-%EC%9C%84%ED%95%9C-PreventFlash-%EC%BB%B4%ED%8F%AC%EB%84%8C%ED%8A%B8-%EB%8B%A4%ED%81%AC-%EB%AA%A8%EB%93%9C-%EC%A0%84%ED%99%98-%EC%8B%9C-%EA%B9%9C%EB%B9%A1%EC%9E%84-%EB%B0%A9%EC%A7%80 Tue, 05 Aug 2025 06:24:29 GMT

웹 애플리케이션에서 다크 모드와 라이트 모드를 지원하는 것은 현대 사용자 경험(UX)의 필수 요소입니다. 하지만 테마 전환 시 FOUC(Flash of Unstyled Content)라고 불리는 깜빡임이 발생하면 사용자가 불편함을 느낄 수 있습니다. 이를 해결하기 위해 소개할 PreventFlash 컴포넌트는 <head> 태그에 위치하여 HTML 파싱 중에 미리 실행되며, 깜빡임을 방지합니다.

1. 깜빡임(FOUC) 문제란?

FOUC(Flash of Unstyled Content)는 웹 페이지가 로드될 때 잠깐 동안 잘못된 스타일이나 테마로 표시되는 현상을 뜻합니다. 특히 다크 모드와 라이트 모드 전환에서 자주 발생합니다.

FOUC 발생 예시

  • 다크 모드 사용자가 페이지를 열 때, 처음에 라이트 모드로 표시되다가 다크 모드로 전환되며 깜빡이는 경우.
  • 라이트 모드 사용자가 잠깐 다크 모드 화면을 보게 되는 상황.

FOUC의 주요 원인

  1. 클라이언트 측 지연: React의 useEffect 같은 훅은 컴포넌트가 화면에 렌더링된 후에 실행됩니다. 이로 인해 초기 렌더링 시 기본 테마(예: 라이트 모드)가 먼저 표시되고, 이후 테마가 변경됩니다.
  2. 서버 렌더링 한계: 서버에서 HTML을 생성할 때는 사용자의 테마 선호도를 알 수 없어 기본 테마로 렌더링됩니다. 클라이언트가 테마를 적용하기 전까지 잘못된 테마가 노출됩니다.

2. PreventFlash 컴포넌트

//_document.tsx
import { Html, Head, Main, NextScript } from 'next/document'

/**
 * Document 컴포넌트는 Next.js 애플리케이션의 HTML 문서 구조를 정의합니다.
 */
export default function Document() {
  return (
    <Html className="bg-default">
      <Head>
        {/* 다크 모드와 라이트 모드 전환 시 깜빡임을 방지 */}
        <PreventFlash />
      </Head>
      <body>
        <Main />
        <NextScript />
      </body>
    </Html>
  )
}

const background = {
  light: 'white',
  dark: '#24292e',
}

function PreventFlash() {
  const setColorScheme = () => {
    const mql = window.matchMedia('(prefers-color-scheme: dark)')
    const scheme = localStorage.getItem('literal-color-scheme') ?? 'system'
    if (scheme === '"dark"' || (scheme === '"system"' && mql.matches)) {
      document.documentElement.classList.toggle('dark', true)
      document
        .querySelector('#theme-color')
        ?.setAttribute('content', background.dark)
    }
  }

  return (
    <>
      <style>{`
        .bg-default, .hover\\:bg-default:hover {
          background: ${background.light};
        }
        .dark.bg-default, .dark .bg-default, .dark .hover\\:bg-default:hover {
          background: ${background.dark};
        }
      `}</style>

      <script
        dangerouslySetInnerHTML={{
          __html: `const background=${JSON.stringify(background)}`,
        }}
      ></script>
      <script
        dangerouslySetInnerHTML={{ __html: `(${setColorScheme})()` }}
      ></script>
    </>
  )
}

<head>에 위치

PreventFlash는 <head> 태그 안에 삽입되어야 합니다. 이는 브라우저가 HTML을 위에서 아래로 파싱할 때 <head> 내의 <script> 태그를 만나면 즉시 실행하기 때문입니다. 따라서 페이지 렌더링이 시작되기 전에 테마를 설정할 수 있습니다.

주요 기능

  • 테마 확인: 로컬 스토리지의 사용자 설정이나 시스템의 prefers-color-scheme를 확인합니다.
  • 즉시 실행: <head> 내 <script> 태그를 통해 HTML 파싱 중에 테마 설정 코드를 실행합니다.
  • 스타일 사전 정의: <style> 태그로 기본 스타일을 미리 정의해 깜빡임을 방지합니다.

3. dangerouslySetInnerHTML

  • React의 기본 원칙: React는 보안을 위해 JSX라는 안전한 방식으로만 HTML을 생성하게 해요. 그래서 <div>나 <p> 같은 태그는 괜찮지만, 직접 <script> 태그나 HTML 문자열을 삽입하려고 하면 제대로 작동하지 않습니다.
  • dangerouslySetInnerHTML: 이 속성은 React에게 "이 HTML 코드를 그대로 DOM에 넣어줘"라고 지시하는 방법입니다.

dangerouslySetInnerHTML 사용 이유

React에서 dangerouslySetInnerHTML을 사용하는 가장 큰 이유는 클라이언트 측에서 즉시 실행되는 JavaScript 코드를 삽입하거나, React 변수와 함수를 브라우저에 전달해야 할 때입니다. 일반적인 JSX로는 이런 작업이 안 되지 않습니다.

예시 1: <script> 태그로 콘솔 출력하기

  • 목표: 페이지에 <script> 태그를 넣어서 "Hello"를 콘솔에 출력하고 싶은 경우.
  • 잘못된 방법:
    function MyComponent() {
  return <script>console.log('Hello')</script>
}
    이 코드는 동작하지 않습니다. React는 JSX에서 <script> 태그를 사용하면 보안상의 이유로 스크립트가 실행되지 않도록 처리합니다. 그래서 <script>console.log('Hello')</script>는 DOM에 추가되지만, console.log('Hello')가 실행되지 않습니다.
  • 올바른 방법:
    function MyComponent() {
  return (
    <script
      dangerouslySetInnerHTML={{ __html: "console.log('Hello')" }}
    ></script>
  )
}
    • 이렇게 하면 브라우저가 <script>console.log('Hello')</script>를 제대로 실행해서 콘솔에 "Hello"를 출력합니다.
    • 왜 필요했나?: React가 <script>를 실행하지 않으니까, dangerouslySetInnerHTML로 강제로 HTML을 삽입합니다.

예시 2: React 변수 전달하기

  • 목표: React에서 정의한 변수를 클라이언트 측 JavaScript에서 사용하고 싶은 경우.
  • 코드:
    function MyComponent() {
  const myVar = 'Hello from React'
  return (
    <>
      <script
        dangerouslySetInnerHTML={{ __html: `const myVar = "${myVar}";` }}
      ></script>
      <script
        dangerouslySetInnerHTML={{ __html: `console.log(myVar);` }}
      ></script>
    </>
  )
}
    • 결과: 브라우저 콘솔에 "Hello from React"가 출력.
    • 설명:
      1. 첫 번째 <script>는 React의 myVar 값을 클라이언트에 전달.
      2. 두 번째 <script>는 그 값을 사용해서 콘솔에 출력.
    • 왜 필요했나?: React 컴포넌트 안의 변수(myVar)는 클라이언트 측 JavaScript에서 바로 접근할 수 없습니다. dangerouslySetInnerHTML로 <script>를 통해 값을 전달해야만 브라우저가 인식할 수 있습니다.

PreventFlash 예시

const background = {
  light: 'white',
  dark: '#24292e',
}
function PreventFlash() {
 ...
  return (
    <>
      ...

      <script
        dangerouslySetInnerHTML={{
          __html: `const background=${JSON.stringify(background)}`,
        }}
      ></script>
      <script
        dangerouslySetInnerHTML={{ __html: `(${setColorScheme})()` }}
      ></script>
    </>
  )
}

  1. 첫 번째 <script>:

    • 목적: background 객체를 클라이언트 측에 전달합니다.
    • 왜 필요해요?: setColorScheme 함수가 background.dark 같은 값을 사용하려면, 이 객체를 브라우저가 알아야 해요. JSX로는 변수 전달이 안 되니까 dangerouslySetInnerHTML로 삽입합니다.

  2. 두 번째 <script>:

    • 목적: setColorScheme 함수를 페이지 로드 시점에 바로 실행합니다.
    • 왜 필요해요?: 페이지가 로드되자마자 테마를 설정해서, 사용자가 라이트 모드와 다크 모드 전환으로 깜빡이는 걸 보지 않게 합니다.

dangerouslySetInnerHTML 안전성

  • 안전한 경우: 위 코드처럼 개발자가 직접 작성한 데이터(background)와 함수(setColorScheme)를 사용할 때는 보안 문제가 없습니다.
  • 위험한 경우: 사용자가 입력한 값(예: <script>alert('해킹')</script>)을 dangerouslySetInnerHTML에 넣으면 악성 코드가 실행될 수 있어요. 하지만 이런 경우가 아니라면 괜찮습니다.

dangerouslySetInnerHTML를 쓰지 않으면 어떻게 될까요?

4. 사용하지 않았을 경우

import { useEffect } from 'react'

function App() {
  useEffect(() => {
    const theme = localStorage.getItem('theme') || 'light'
    document.documentElement.classList.add(theme)
  }, [])

  return <div>컨텐츠</div>
}

과정

  1. 서버에서 기본 테마(라이트 모드)로 HTML을 렌더링합니다.
  2. 브라우저가 HTML과 CSS를 로드해 라이트 모드로 화면을 표시합니다.
  3. React가 마운트되고 useEffect가 실행되어 로컬 스토리지에서 them 정보를 가져옵니다.
  4. 화면이 라이트에서 다크로 바뀌며 깜빡임이 발생합니다.

5. 사용한 경우

PreventFlash가 <head>에 위치하여 HTML 파싱 중에 실행되는 점이 핵심입니다.

브라우저 렌더링 단계

  1. HTML 파싱: HTML을 다운로드하고 DOM 트리를 생성합니다.
  2. CSS 파싱: CSS를 파싱해 CSSOM을 만듭니다.
  3. 렌더 트리 생성: DOM과 CSSOM을 결합해 렌더 트리를 생성합니다.
  4. 레이아웃: 요소의 크기와 위치를 계산합니다.
  5. 페인팅: 화면에 픽셀을 그립니다.

<head>에서 <script> 실행

  • 브라우저는 HTML을 위에서 아래로 파싱하며, <head> 내 <script>를 만나면 파싱을 멈추고 스크립트를 실행합니다.
  • PreventFlash의 <script>는 이 시점에 테마를 설정하므로, 렌더 트리가 생성되기 전에 올바른 테마가 적용됩니다.

실제 사용 예시

6. 렌더링 비교

단계 PreventFlash 미사용 PreventFlash 사용
HTML 파싱 기본 테마로 진행 <head>에서 <script> 실행, 테마 설정
렌더 트리 생성 기본 테마로 생성 올바른 테마로 생성
페인팅 라이트 → 다크 (깜빡임) 처음부터 다크 모드 표시

7. 정리

// 라이트 모드와 다크 모드의 배경색을 정의합니다.
const background = {
  light: 'white',
  dark: '#24292e',
}

/**
 * PreventFlash 컴포넌트는 다크 모드와 라이트 모드 전환 시 깜빡임을 방지합니다.
 * - 초기 렌더링 시 사용자의 테마 선호도(로컬 스토리지 또는 시스템 설정)에 따라 올바른 스타일을 적용합니다.
 * - `dangerouslySetInnerHTML`을 사용하여 `<script>` 태그에 클라이언트 측에서 즉시 실행되는 JavaScript 코드를 삽입하며,
 *   이는 외부 import가 빠른 새로고침(fast refresh)을 방해하기 때문에 여기서 직접 구현됩니다.
 * - 목적: 페이지 로드 시 테마 전환으로 인한 깜빡임(FOUC)을 방지하고 사용자 경험을 개선합니다.
 * @returns {JSX.Element} 스타일과 스크립트를 포함한 JSX 요소
 */
function PreventFlash() {
  // setColorScheme 함수는 클라이언트 측에서 테마를 설정합니다.
  const setColorScheme = () => {
    // 시스템의 다크 모드 선호 여부를 확인합니다.
    const mql = window.matchMedia('(prefers-color-scheme: dark)')
    // 로컬 스토리지에서 사용자 테마 설정을 가져오며, 기본값은 'system'입니다.
    const scheme = localStorage.getItem('literal-color-scheme') ?? 'system'

    // 다크 모드 조건: 사용자가 'dark'를 선택했거나, 'system'이고 시스템이 다크 모드일 때
    if (scheme === '"dark"' || (scheme === '"system"' && mql.matches)) {
      // HTML 요소에 'dark' 클래스를 추가하여 다크 모드 스타일을 적용합니다.
      document.documentElement.classList.toggle('dark', true)
      // 테마 색상을 다크 모드 배경색으로 업데이트합니다.
      document
        .querySelector('#theme-color')
        ?.setAttribute('content', background.dark)
    }
  }

  return (
    <>
      {/* 배경색을 정의하는 CSS 스타일을 삽입합니다. */}
      <style>{`
        .bg-default, .hover\\:bg-default:hover {
          background: ${background.light};
        }
        .dark.bg-default, .dark .bg-default, .dark .hover\\:bg-default:hover {
          background: ${background.dark};
        }
      `}</style>
      {/* background 객체를 클라이언트 측에서 사용할 수 있도록 JSON 형태로 삽입합니다. */}
      <script
        dangerouslySetInnerHTML={{
          __html: `const background=${JSON.stringify(background)}`,
        }}
      ></script>
      {/* setColorScheme 함수를 즉시 실행하여 초기 테마를 설정합니다. */}
      <script
        dangerouslySetInnerHTML={{ __html: `(${setColorScheme})()` }}
      ></script>
    </>
  )
}

PreventFlash 컴포넌트는 <head> 태그에 삽입되어 HTML 파싱 중에 실행되며, 테마를 즉시 적용해 FOUC를 방지합니다.

]]> <![CDATA[웹 성능 최적화 ]]> https://velog.io/@jay_chae/%EC%9B%B9-%EC%84%B1%EB%8A%A5-%EC%B5%9C%EC%A0%81%ED%99%94 https://velog.io/@jay_chae/%EC%9B%B9-%EC%84%B1%EB%8A%A5-%EC%B5%9C%EC%A0%81%ED%99%94 Wed, 05 Feb 2025 07:18:30 GMT 아래 링크에 정리

이미지 최적화 - LCP https://velog.io/@jay_chae/LCP-%EC%9D%B4%EB%AF%B8%EC%A7%80-%EC%B5%9C%EC%A0%81%ED%99%94

폰트 최적화 - FCP https://velog.io/@jay_chae/Next-font-%EC%B5%9C%EC%A0%81%ED%99%94

]]> <![CDATA[그렇게 쓰면 아무도 안 읽습니다]]> https://velog.io/@jay_chae/%EA%B7%B8%EB%A0%87%EA%B2%8C-%EC%93%B0%EB%A9%B4-%EC%95%84%EB%AC%B4%EB%8F%84-%EC%95%88-%EC%9D%BD%EC%8A%B5%EB%8B%88%EB%8B%A4 https://velog.io/@jay_chae/%EA%B7%B8%EB%A0%87%EA%B2%8C-%EC%93%B0%EB%A9%B4-%EC%95%84%EB%AC%B4%EB%8F%84-%EC%95%88-%EC%9D%BD%EC%8A%B5%EB%8B%88%EB%8B%A4 Mon, 20 Jan 2025 13:36:10 GMT

“가장 우선해야 하는 것은 사용자의 과업의 완성을 위해 적정한 정보를 생산하고 전달하는 일이고, 오직 우리가 집중해야 할 문제는 정보를 어떻게 디자인해서 사용자와 진정한 의미의 대화를 할지이다.”

: 이력서 보는 사람의 과업

what you say 그다음 how you say

선택하기 → 선택

주어1 동사1, 중복 피하기

무엇인가요?(문장형) ←x→ ~선택(명사구)

일관성 중요!

글쓰기도 코드처럼 컨벤션 필요

해요체 vs 하십시오 체

높임의 정도 차이 편할거냐 대접받을거냐

보통 섞이기 마련.

뭘 부탁할 때는 해보세요.

유머 좋아. 근데 너무 자주 나오면 안됨

사용자 이름 부르기

친근과 부담 균형 맞추기

이름 부르면 별 내용 아니더라도 외면하기 힘들다. → 칵테일 파티 효과

: 음 인사 담당자인지 개발자인지, 리더인지 선택하기

리스크도 있다. 너무 자주 부르면 안됨

독이 될 수 있는 공감 표현

예단해 버리는 느낌, 민감한 부분일 수 있다.(대출)

고난이도다

아이콘 밑에 텍스트는 있으면 좋다

팝업

최소한, 중요한, 무조건 받아야 할 때

버튼 먼저 읽고 제목을 읽는다.

본문은 1문장 최소 2문장

타이틀 본문은 중복 내용 없어야 함

버튼 하나 → 의문 X

버튼 둘 → 평서문 x

버튼 3개는 좀...

왼쪽에는 후퇴동작 오른쪽 전진동작(프라이머리 색, 순서 바꾸지 마!→ 골탕 먹이려 하지마 기분 나쁨)

버튼→ 간결한 동사

텍스트 버튼→ 링크→ 명사(도착 페이지)

세로로 정렬된 버튼에는 좀 길게 휴대폰에 저장하기로 텍스트 하고 본문 없애는 방법도 있다. 버튼이 비어보일수 있으니까

버튼의 텍스트는 사용자의 보이스다. 사용자의 말투를 어떻게 할 것인가?

대화체→ 직접 말하는 느낌→ 자기 입장을 표현한 느낌→ 좋음

그러나 길어지는 위험 그리고 권력 관계의 미묘한 조정

토스트는 피드백 그러나 그렇게 중요한게 아닐때

2~3초 최대 2줄 10단어 이하 → 다 못 읽었는데 없어지면 찝찝

툴팁: 말풍선

사용자가 모를 것 같은 정보만 넣는다

많아지면 구차해짐 많아지면 실력이 좋지 않다는 말

오류 해결 방안 제시

부정적, 저자세(굽신) 안됨

fail→실패라는 번역 너무 부정적임

다크 패턴 좀 별로 → 바보 취급하지 마랓

]]> <![CDATA[UX 7가지 디자인]]> https://velog.io/@jay_chae/UX-7%EA%B0%80%EC%A7%80-%EB%94%94%EC%9E%90%EC%9D%B8 https://velog.io/@jay_chae/UX-7%EA%B0%80%EC%A7%80-%EB%94%94%EC%9E%90%EC%9D%B8 Mon, 20 Jan 2025 13:34:44 GMT

“UX 디자인은 사용자가 제품을 구입하기 전부터 구입해서 사용하고 폐기하는 전 과정을 포함하기 때문에 전 회사 차원에서 협력해야 달성할 수 있는 목표다”

: 사용하기 전 후 과정 다 고려해야 함. 이력서 열기 전, 후 과정을 고려 → 이력서 보기 직전 화면에 메시지를 넣는다면, 재밌고 좋지 않을까. 말을 건다던지 왜냐면 pdf든 노션이든 이력서가 뜨기 전에는 무조건 지루한 흰바탕일테니까. 만일 나에게 말을 건다면 집중력이 벌써 증가할 것 같다.

“사용자가 처음 보는 제품을 사용할 때 사용자의 장기기억에 저장된 의미를 활용해서 제품의 사용법에 의미를 부여하고 해석할 수 있도록 인터랙션을 설계해야 한다.” ... “요컨대 사용자는 자신에게 의미 없는 것을 잘 기억하지 못한다.”

: 이력서를 보는 사람 머리에는 어떤 의미가 들어 있을까. 내가 겪었던 문제, 제목을 직관적이고 의미 파악이 쉽게 한다. → 문제해결능력: “만들어주신 공동 컴포넌트 수정해도 돼요?”, 협업능력: “마감기한이 늦춰졌어요”

필수요소와 매력요소

: 필수요소는 적당히 매력요소를 열심히. 만족도 효율이 좋다.

: 우리 사이트의 매력요소는? splitview? 재미?

기능이 많아지면 UI를 익숙하게 해서 긴장도를 해소하자

피드백

0.1초→ 즉각적이네, 1초→ 느리네 1초보다 크면→ 끊기네, 10초→ 중단됐네

2초 이상은 무조건 진행 상태를 알려줘야 함

: split view가 일단 바로 나와야 함 컨텐츠는 느리더라도.

“설계원칙 5: 모든/특정 사용자의 시나리오를 고려하라”

“ux 디자이너는 모든 상황을 고려해서 사용자가 어려움을 겪지 않도록 ux를 디자인 한다.”

: 모든 상황을 고려하라... 내 이력서를 공유할 수 있게 할까?

→ 마우스 없는 상황 고려하기

“설계원칙 6: 사용자의 실수를 방지, 복구할 수 있는 방법을 제공하라”

“설계원칙 10: 중복코딩 이점 활용하고 간섭이 일어나지 않도록 설계하라”

색깔+이미지

“설계원칙11: 모든 상황에서 반드시 의도된 행위를 유발하도록 설계하라”

:유도 유도 유도해야 함. 어떻게 split view를 열게 하지? 어떻게 이것저것 눌러보게 하지?

“즉 제품이나 서비스 경쟁은 결국 고객의 시간을 누가 많이 뺐느냐의 싸움이란 것이다.”

: 시간→ 정→ 합격

설계원칙 16: 화면 전환 시에 시각적인 연속성을 부여해야 한다.

: 그 하일라이트 해야 한다는 아주 좋은 근거

설계원칙 17: 사용자가 기억하게 하지 마라 ‘회상보다 인식’

cli보다 gui가 편한 이유

: 그 태그 검색해야 하는 좋은 근거 아주 좋아

설계원칙 18: 인터페이스를 접어라

힉의 법칙: 의사결정을 내리는 데 선택 가능한 대안의 수가 많을수록 오랜 시간이 걸린다.

모든 것을 나열하지 말고 중요하고 필수적인 것은 옵션에 넣어라

: 이력서에 핵심만 넣고 splitview는 접어두는 용도

: 힉의 법칙에 따라 링크를 넣고 시각적인 연속성을 위해 splitview

설계원칙 19: 자주 쓰이고 중요한 것을 더 쉽게 접근

가깝고 크게

: 블록 전체를 클릭 vs 자세히 보기 버튼

좋은 ux 떠올리는 비결

좋은 비유 찾기

사이트 → 논문 → 구글

“좋은 메타포는 제품과 전혀 닮지 않았는데 기능적 유사성이나 내적 연관성이 크고 메타포의 도입으로 보이지 않았던 새로운 특징이 드러나게 된다.”

:클로드 아주 좋아

“사용자가 처음 보는 제품을 사용할 때 사용자의 장기기억에 저장된 의미를 활용해서 제품의 사용법에 의미를 부여하고 해석할 수 있도록 인터랙션을 설계해야 한다.” ... “요컨대 사용자는 자신에게 의미 없는 것을 잘 기억하지 못한다.”

: 이력서를 보는 사람 머리에는 어떤 의미가 들어 있을까. 내가 겪었던 문제, 제목을 직관적이고 의미 파악이 쉽게 한다. → 문제해결능력: “만들어주신 공동 컴포넌트 수정해도 돼요?”, 협업능력: “마감기한이 늦춰졌어요”

필수요소와 매력요소

: 필수요소는 적당히 매력요소를 열심히. 만족도 효율이 좋다.

: 우리 사이트의 매력요소는? splitview? 재미?

기능이 많아지면 UI를 익숙하게 해서 긴장도를 해소하자

피드백

0.1초→ 즉각적이네, 1초→ 느리네 1초보다 크면→ 끊기네, 10초→ 중단됐네

2초 이상은 무조건 진행 상태를 알려줘야 함

: split view가 일단 바로 나와야 함 컨텐츠는 느리더라도.

“설계원칙 5: 모든/특정 사용자의 시나리오를 고려하라”

“ux 디자이너는 모든 상황을 고려해서 사용자가 어려움을 겪지 않도록 ux를 디자인 한다.”

: 모든 상황을 고려하라... 내 이력서를 공유할 수 있게 할까?

“설게원칙 6: 사용자의 실수를 방지, 복구할 수 있는 방법을 제공하라”

“설계원칙 10: 중복코딩 이점 활용하고 간섭이 일어나지 않도록 설계하라”

색깔+이미지

“설계원칙11: 모든 상황에서 반드시 의도된 행위를 유발하도록 설계하라”

:유도 유도 유도해야 함. 어떻게 split view를 열게 하지? 어떻게 이것저것 눌러보게 하지?

“즉 제품이나 서비스 경쟁은 결국 고객의 시간을 누가 많이 뺐느냐의 싸움이란 것이다.”

: 시간→ 정→ 합격

설계원칙 16: 화면 전환 시에 시각적인 연속성을 부여해야 한다.

: 그 하일라이트 해야 한다는 아주 좋은 근거

설계원칙 17: 사용자가 기억하게 하지 마라 ‘회상보다 인식’

cli보다 gui가 편한 이유

: 그 태그 검색해야 하는 좋은 근거 아주 좋아

설계원칙 18: 인터페이스를 접어라

힉의 법칙: 의사결정을 내리는 데 선택 가능한 대안의 수가 많을수록 오랜 시간이 걸린다.

모든 것을 나열하지 말고 중요하고 필수적인 것은 옵션에 넣어라

: 이력서에 핵심만 넣고 splitview는 접어두는 용도

: 힉의 법칙에 따라 링크를 넣고 시각적인 연속성을 위해 splitview

설계원칙 19: 자주 쓰이고 중요한 것을 더 쉽게 접근

가깝고 크게

: 블록 전체를 클릭 vs 자세히 보기 버튼

좋은 ux 떠올리는 비결

좋은 비유 찾기

사이트 → 논문 → 구글

“좋은 메타포는 제품과 전혀 닮지 않았는데 기능적 유사성이나 내적 연관성이 크고 메타포의 도입으로 보이지 않았던 새로운 특징이 드러나게 된다.”

:클로드 아주 좋아

태스크 vs 목적

사용하는 이유→ 목적→ 싸게 산다(마트)

목적을 위해 필요한 거 → 태스크 → 쿠폰 이용, 전단지에 있는 제품 구매

태스크를 분석 잘해야 함

: 이력서를 보는 이유→ 좋은 놈인지 알아보기 위해

:태스크→ 공고 올리기, 이력서 받기, 이력서 열기, 읽기, 분석(여기가 복잡), 합격, 불합격 메일 보내기

: 분석→ 역량 파악, 블로그 깃헙 들어가기, 등등

: 합격 메일 보내기 기능+ 불합격 통보 이걸 쉽게 할 수 있게 한다?

]]> <![CDATA[📏단일 책임 원칙으로 렌더링 개선(react next js)]]> https://velog.io/@jay_chae/%EB%8B%A8%EC%9D%BC-%EC%B1%85%EC%9E%84-%EC%9B%90%EC%B9%99%EC%9C%BC%EB%A1%9C-%EB%A0%8C%EB%8D%94%EB%A7%81-%EA%B0%9C%EC%84%A0react-next-js https://velog.io/@jay_chae/%EB%8B%A8%EC%9D%BC-%EC%B1%85%EC%9E%84-%EC%9B%90%EC%B9%99%EC%9C%BC%EB%A1%9C-%EB%A0%8C%EB%8D%94%EB%A7%81-%EA%B0%9C%EC%84%A0react-next-js Sun, 22 Dec 2024 10:11:08 GMT 😤 문제

“어떤 문제가 있었나요”

splitView 내용만 바뀌는 데 splitView 컨테이너까지 리렌더링 된다.

🧐 문제 원인

“문제 원인이 무엇인가요”

splitView 컨테이너 열고 닫는 로직과 내용 바꾸는 로직이 같은 컴포넌트에 있다. 그래서 내용이 바뀔 때 컨테이너 까지 리렝더링

😎 해결책

“해결책”

단일 책임 원칙으로 splitView 안에 내용을 결정하는 컴포넌트와 splitView 열고 닫는 컴포넌트로 분리한다.

🤔 이유

“왜 이런 해결책 사용했나요”

splitView 안에 내용을 결정하는 컴포넌트가 분리되면 안에 내용이 바뀌어을 때 컨테이너는 영향을 받지 않는다.

  • splitViewContainer prop 가독성이 더 좋아졌다. 클린 코드!

🤩 적용

“어떻게 적용했나요”

비포

//분리 전
import SecondaryViewContainer from "./SecondaryViewContainer "
function SplitViewContainer({ PrimaryView }: SplitViewContainerProp) {
  //여는 로직
  const isOpen = useStoreSelector(splitViewStore, (state) => state.isOpen)
  //안에 내용 결정 로직
  const id = useStoreSelector(splitViewStore, (state) => state.id)
  const Content = id != null ? ssulContents[id] : () => null

  return (
    <div className="relative flex size-full justify-end">
      <div
        className={`absolute size-full lg:w-3/6 ${
          isOpen ? 'lg:left-0' : 'lg:left-1/2 lg:-translate-x-1/2'
        } overflow-y-scroll transition-all duration-300 ease-out`}
      >
        {PrimaryView}
      </div>
      {isOpen && (
        <div className="size-full animate-slide-in-right lg:w-5/12">
          <SecondaryViewContainer>
            <Content />
          </SecondaryViewContainer>
        </div>
      )}
    </div>
  )
}

애프터

//컨테이너(열고 닫는 로직만 담당)
function SplitViewContainer({
  PrimaryView,
  SecondaryView,
}: SplitViewContainerProp) {
  const isOpen = useStoreSelector(splitViewStore, (state) => state.isOpen)

  return (
    <div className="relative flex size-full justify-end">
      <div
        className={`absolute size-full lg:w-3/6 ${
          isOpen ? 'lg:left-0' : 'lg:left-1/2 lg:-translate-x-1/2'
        } overflow-y-scroll transition-all duration-300 ease-out`}
      >
        {PrimaryView}
      </div>
      {isOpen && (
        <div className="size-full animate-slide-in-right lg:w-5/12">
          {SecondaryView}
        </div>
      )}
    </div>
  )
}
//컨텐트 (안의 내용물 결정 로직만 담당)
function SecondaryViewContent({ id }: SecondaryViewContentProps) {
  const id = useStoreSelector(splitViewStore, (state) => state.id)
  const Content = id != null ? ssulContents[id] : () => null

  return (
    <article className="prose size-full !max-w-full py-5 md:prose">
      <Content />
    </article>
  )
}

분리하고 나니까 prop도 더 가독성이 좋아졌다.

//before
//세컨더리뷰는 어딨지? 의문인 코드
function Page() {
  return <SplitViewContainer PrimaryView={<PrimaryViewContainer/>} />
}
//after
//프라이머리 뷰와 세컨더리 뷰가 각각 어떤 컴포넌트지 알수 있다.
function Page() {
  return (
    <SplitViewContainer
      PrimaryView={<PrimaryViewContainer/>}
      SecondaryView={<SecondaryViewContainer/>}
    />
  )
}

렌더링 갯수

비포: 5개

애프터: 4개

렌더링 시간

비포: 5.7ms

애프터

렌더링 시간 3.3ms

]]> <![CDATA[⭕ LCP 이미지 최적화]]> https://velog.io/@jay_chae/LCP-%EC%9D%B4%EB%AF%B8%EC%A7%80-%EC%B5%9C%EC%A0%81%ED%99%94 https://velog.io/@jay_chae/LCP-%EC%9D%B4%EB%AF%B8%EC%A7%80-%EC%B5%9C%EC%A0%81%ED%99%94 Sun, 22 Dec 2024 10:07:50 GMT 😤 문제

“어떤 문제가 있었나요”

LCP 점수 나쁨

🧐 문제 원인

“문제 원인이 무엇인가요”

이미지가 늦게 뜬다

😎 해결책

“해결책”

next Image에 priorty 속성 true 적용

🤔 이유

“왜 이런 해결책 사용했나요”

priorty 적용하면 이미지를 preload 한다.

공식 문서

priority가 true로 설정되면 해당 이미지는 높은 우선순위로 간주되어 사전 로드(preload)됩니다. ... priority 속성은 이미지가 Largest Contentful Paint (LCP) 요소로 감지될 때 사용해야 합니다. 다양한 뷰포트 크기에 따라 서로 다른 이미지가 LCP 요소가 될 수 있으므로, 여러 개의 우선순위 이미지를 지정하는 것이 적절할 수 있습니다. 또한 이 속성은 화면 상단(above the fold)에 표시되는 이미지에만 사용해야 합니다. 기본값은 false입니다. Largest Content인 이미지에 priority 속성을 주자

🤩 적용

“어떻게 적용했나요”

LCP 11초 개선

before

after

]]> <![CDATA[🔠Next font 최적화]]> https://velog.io/@jay_chae/Next-font-%EC%B5%9C%EC%A0%81%ED%99%94 https://velog.io/@jay_chae/Next-font-%EC%B5%9C%EC%A0%81%ED%99%94 Sun, 22 Dec 2024 10:05:22 GMT 😤 문제

“어떤 문제가 있었나요”

폰트를 다운로드 하는 데 오래 걸렸다.

🧐 문제 원인

“문제 원인이 무엇인가요”

CDN으로 받아오는 데 시간이 오래 걸린다.

😎 해결책

“해결책”

폰트를 다운로드하고 next/font를 사용한다.

🤔 이유

“왜 이런 해결책 사용했나요”

셀프 호스팅 + next font

다른 곳에 요청을 해서 폰트를 받지 않고 내 서버에서 받으면 빠르기 때문에 폰트를 다운로드해서 빌드해둔다.

next font (next 공식문서)

next/font는 폰트(맞춤형 폰트 포함)를 자동으로 최적화하고 외부 네트워크 요청을 제거하여 개인정보 보호와 성능을 향상시킵니다. next/font는 모든 폰트 파일에 대해 자동 자체 호스팅을 기본적으로 제공합니다. 이를 통해 size-adjust CSS 속성을 활용하여 레이아웃 이동 없이 웹 폰트를 최적의 방식으로 로드할 수 있습니다. 이 새로운 폰트 시스템은 Google Fonts도 성능과 개인정보 보호를 고려하여 편리하게 사용할 수 있도록 합니다. CSS와 폰트 파일은 빌드 시 다운로드되며 나머지 정적 자산과 함께 자체 호스팅됩니다. 브라우저에서 Google로 요청이 전송되지 않습니다.

즉 셀프 호스팅 + fallback font 최적화로 레이아웃 이동 최소화해준다.

원하는 폰트와 가장 비슷한 폰트를 자동으로 fall back font를 넣어주는 게 참 신기하다

🤩 적용

“어떻게 적용했나요”

import localFont from 'next/font/local'

const pretendard = localFont({
  src: '../public/fonts/PretendardVariable.woff2',
  display: 'swap',
  weight: '45 920',
  preload: true,
})

export default function RootLayout({
  children,
}: Readonly<{
  children: React.ReactNode
}>) {
  return (
    <html lang="ko" className={`${pretendard.className} size-full`}>
      <body className="size-full">
        <div className="size-full overflow-x-hidden">{children}</div>
      </body>
    </html>
  )
}

FCP 1초 개선!

]]> <![CDATA[⛏️selector로 렌더링 최적화 (react,next js)]]> https://velog.io/@jay_chae/selector%EB%A1%9C-%EB%A0%8C%EB%8D%94%EB%A7%81-%EC%B5%9C%EC%A0%81%ED%99%94-reactnext-js https://velog.io/@jay_chae/selector%EB%A1%9C-%EB%A0%8C%EB%8D%94%EB%A7%81-%EC%B5%9C%EC%A0%81%ED%99%94-reactnext-js Sun, 22 Dec 2024 10:01:05 GMT 😤 문제

“어떤 문제가 있었나요”

버튼을 누르면 누른 버튼 색이 바뀐다. 그런데 버튼 하나를 누르면 색이 변하지 않는 모든 버튼이 리렌더링 된다.

🧐 문제 원인

“문제 원인이 무엇인가요”

버튼 컴포넌트가 전역 상태를 가지고 있기 때문에 렌더링 변화가 없어도 전역상태가 바뀌면 리렌더링이 된다.

😎 해결책

“해결책”

selector의 반환 값을 해당 버튼이 활성화 되었는지에 대한 값으로 바꾸어 값이 변하는 경우만 렌더링 되게 한다. 

//before: 전역 상태 id를 사용 => isActive 값이 변하지 않아도 id만 변해도 리렌더링
const id = useStoreSelector(splitViewStore, (state) => state.id)
const isActive = splitViewId === id

//after: isActive 값이 바뀔 때만 리레더링
const isActive = useStoreSelector( splitViewStore,(state) => state.id === splitViewId)

🤔 이유

“왜 이런 해결책 사용했나요”

전역 상태를 사용하는 컴포넌트는 그 전역 상태 값이 바뀔 때 업데이트 해야 하는 컴포넌트로 콜백에 등록이 된다.

그런데 selector를 사용하여 어떤 값이 어떻게 변경 되었을 떄 업데이트 시켜줄지 정해줄 수 있다

🤩 적용

“어떻게 적용했나요”

//before
function OpenSplitView({ children, splitViewId }: OpenSplitViewProps) {
  const id = useStoreSelector(splitViewStore, (state) => state.id)
  const isActive = splitViewId === id

  const handleOpenSplitView = () => {
    splitViewStore.setState({
      isOpen: true,
      id: splitViewId,
    })
  }

//after
function OpenSplitView({ children, splitViewId }: OpenSplitViewProps) {
  const isActive = useStoreSelector(
    splitViewStore,
    (state) => state.id === splitViewId,
  )

  const handleOpenSplitView = () => {
    splitViewStore.setState({
      isOpen: true,
      id: splitViewId,
    })
  }

렌더링 갯수:

before: 버튼을 누르면 모든 버튼 4개가 리렌더링

after: 눌린 버튼, 해제된 버튼 2개만 리렌더링

렌더링 시간:

before: 5.8ms

after: 2.4ms

]]> <![CDATA[지역 상태의 문제점 ]]> https://velog.io/@jay_chae/%EC%A7%80%EC%97%AD-%EC%83%81%ED%83%9C%EC%9D%98-%EB%AC%B8%EC%A0%9C%EC%A0%90 https://velog.io/@jay_chae/%EC%A7%80%EC%97%AD-%EC%83%81%ED%83%9C%EC%9D%98-%EB%AC%B8%EC%A0%9C%EC%A0%90 Tue, 19 Nov 2024 12:44:40 GMT

요약

문제:

지역 상태를 컴포넌트 간에 공유하려면 prop drilling과 리렌더링 문제가 생긴다.

해결방법:

  1. context:하위 트리마다 특정 값을 공유해야 할 때 사용한다.
  2. subscribe: 트리 외부에 store를 두고 그 값을 특정 컴포넌트가 가져다가 쓰는 모델

지역 상태의 문제점

지역 상태(useState)는 선언된 컴포넌트 내에서만 사용 가능하다. 그런데 컴포넌트 간에 같은 상태를 공유하고 싶다면 어떻게 해야 할까?

공통 부모 컴포넌트까지 올라가서 지역 상태를 선언해 준 후 prop으로 내려줘야 한다. 이럴 경우 먼저 prop drilling이 심하게 일어날 가능성이 높다.

게다가 렌더링 측면에서도 좋지 않다. 예를 들어 멀리 떨어진 컴포넌트 간에 상태를 공유할 경우를 생각해 보자. 심할 경우 최상위 부모에 상태 선언 후 prop으로 내려줘야 할 수도 있다. 이 경우 상태가 변했을 때 문제가 생긴다. 최상위가 리렌더링 되기 때문에 + 내려오는 하위 prop들이 변하기 때문에 어플 전체가 리렌더링 된다.

즉 컴포넌트 간 같은 상태를 공유하고자 할 때, 지역 상태는 2가지 문제점이 발생한다.

  1. prop drilling
  2. re-rendering

context

해결 방법은 크게 두 가지가 있다. 첫 번째는 context이고 그 다음이 구독 모델이다.

리액트에서는 context api를 제공해 주고 있다. 이 친구를 사용하면 prop drill을 하지 않고 prop 점프를 할 수 있게 된다.

위 그림을 보면 최상단 부모에서 상태가 쭉쭉 걸어 내려오는 것을 확인 할 수 있다. 그러나 context를 사용하면 걸어 내려오지 않습니다.

위 그림처럼 최상위에서 상태가 필요한 컴포넌트로 바로 점프해서 도달하게 된다. 이런 방식을 사용해서 상태를 사용하는 컴포넌트만 렌더링 시키는 것이 가능해진다.

그러나 이 방식에는 뼈아픈 단점이 있다. 먼저 상태 값이 객체인 경우 렌더링 최적화가 되지 않는다. {a:1,b:2} 인 상태 값을 사용한다고 해보자. 컴포넌트 A에는 a 값만을 사용하고 컴포넌트 B에서는 b만을 사용한다. 이 경우 a 값을 변경 했을 경우, A만 리렌더링 하면 좋겠지만 B도 함께 리렌더링 된다. context를 사용할 때에 꼭 알아야 하는 리렌더링 이슈다. 이 문제는 객체를 여러 context로 나누는 방법이 있다고 한다. 그러나 그럴 경우 컴포넌트를 감싸는 provider가 많아지는 등, 더티하고 유지 보수하기 힘든 코드가 된다.

다음은 문제는 아니지만 context 사용하는 적절한 상황이라는 게 존재한다. context는 '문맥'이라는 뜻, 즉 이름처럼 어떤 문맥을 형성할 때 사용하는 것이 좋다. 예를 들어 한 남자의 인생을 다룬 소설을 읽고 있다고 해보자 책 초반부에서 '사랑'이라는 단어가 나올 때, 그 단어의 뜻은 로맨틱한 '에로틱 사랑'을 의미했다. 그러나 남자가 늙어버린 책 후반부에서 '사랑'은 인류애적인 '아가페 사랑'을 의미하게 된다. 같은'사랑'이라는 단어지만 문맥에 따라 다른 뜻으로 사용된다. context도 비슷한 상황에서 쓰인다. 어떤 상태를 하위 트리에서 일관되게 사용하고 싶을 때 사용한다. 하위 트리마다 다르게 쓰여야 할 때, provider를 사용하면 효과적으로 사용할 수 있다.

즉, 하위 트리에 문맥을 형성하는 상태 값이 있을 때 사용하라고 있는 친구다. 그러므로 context는 어떤 전역 상태에는 적절하지 않을 수 있다. 예를 들어서 모달이 열렸는지 닫혔는지에 대한 정보를 저장하기에는 부적절하다. 왜나하면 특정 하위 트리 전체에 의미 있는 값이 아니기 때문이다. 그저 무작위적으로 모달을 사용하는 컴포넌트에서 사용되는 값이다. 이런 경우 어쩔 수 없이 최상위에 context provider를 주어야 한다. 가능은 하지만 context가 정체성에 그다지 맞는 사용법은 아니라고 할 수 있다. 마치 포크로 밥을 퍼먹는 느낌? 솔직히 잘 퍼먹을 수 있지만, 포크는 찍어먹을 때 쓰라고 만든 거긴 해 ㅎㅎ

subscribe

지역 상태 해결 방법 두 번째는 바로 구독 모델이다. 이 경우 context로 사용하기에는 부적절해 보이는 전역 상태를 사용하기에 적합한 모델이다.

위 그림처럼 전역 상태가 컴포넌트 상위에 있지 않는다. store는 전역 상태가 들어있는 창고인 store를 따로 빼둔다. 그 다음 해당 전역 상태를 사용하는 컴포넌트가 저 창고에서 빼오는 식으로 사용한다. 값을 사용하는 컴포넌트가 상태값을 구독해서 배달받는 느낌으로 이름을 이렇게 지은게 아닌가 싶다.(걍 내 생각, 적절한 네이밍 좋았다)

이런 모델을 사용하는 대표적인 예는 zustand이다.

이렇게 될 경우 prop drilling은 손쉽게 해결된다. 그리고 context에서 언급된 객체인 경우 렌더링 최적화가 되지 않는다는 문제는 어떨까? 동일한 문제가 발생은 하지만 selector라는 것을 활용해 해결할 수 있다. {a:1,b:2}일 때 필요한 a만 select하는 기법이다. 구현하는 방식은 라이브러리마다 다르고 어떻게 구현하느냐에 따라 달라질 테니 설명은 생략, 그러나 간단하니 필요하면 찾아보자. context보다는 조금 손쉽 효율적인 해결책이라고 한다.

구독 모델은 전역상태 관리에 모델로 널리 쓰이고 있으면 대표적인 예시가 zustand라고 할 수 있다. zustand를 사용할 때 그러니 꼭 selector 기능을 사용해 렌더링 최적화를 하라.

구독 모델은 같은 구조의 상태를 하위 트리 문맥에 따라 다르게 사용하지 못한다. 이런 경우는 context가 좋다. 그래서 이 둘은 혼합해서 사용할 수 있다. 두 가지 장점을 모두 취하는 방식으로 만들어진 대표적인 라이브러리가 바로 jotai다. jotai에는 context처럼 provider를 제공하니 활용할 수 있으면 활용해 보자.

NEXT

나는 모달이나 split view처럼 열고 닫아야 하는 값을 전역 상태로 관리하고자 한다. 이 경우 구독 모델이 더 적절해 보이니, 구독 모델 전역 상태를 직접 구현해 보고자 한다.

]]> <![CDATA[NEXT MIDDLEWARE]]> https://velog.io/@jay_chae/NEXT-MIDDLEWARE https://velog.io/@jay_chae/NEXT-MIDDLEWARE Sat, 26 Oct 2024 05:58:53 GMT next js로 프로젝트 할 경우 middleWare 활용법

로그인 안 했으면 접근 못하는 페이지의 경우 미들웨어 쓰면 좋다

예를 들면 마이페이지는 로그인 하지 않으면 로그인 페이지로 리다이렉트 시켜주어야 한다.

브라우저에서 리다이렉트 할 경우

브라우저 -> 마이 페이지요청 -> 프런트 서버 브라우저 <- 마이 페이지 html <- 프런트 서버 브라우저 로그인 유뮤 검사 브라우저-> 로그인 페이지 요청 -> 프런트 서버 브라우저 <- 로그인 페이지 html <- 프런트 서버

미들웨어 사용해 리다이렉트 할 경우

브라우저 -> 마이 페이지요청 -> 프런트 서버 미들웨어가 로그인 유뮤 검사 브라우저 <- 로그인 페이지 html <- 프런트 서버

이렇게 줄어드는 것을 확인 할 수 있다.

]]> <![CDATA[디버깅 툴 활용해 주세요]]> https://velog.io/@jay_chae/%EB%94%94%EB%B2%84%EA%B9%85-%ED%88%B4-%ED%99%9C%EC%9A%A9%ED%95%B4-%EC%A3%BC%EC%84%B8%EC%9A%94 https://velog.io/@jay_chae/%EB%94%94%EB%B2%84%EA%B9%85-%ED%88%B4-%ED%99%9C%EC%9A%A9%ED%95%B4-%EC%A3%BC%EC%84%B8%EC%9A%94 Mon, 21 Oct 2024 13:47:52 GMT

결론: 복잡해지기 전에 미리 미리 디버깅 툴을 활용해서 개발하자

profiler를 통해 불필용한 렌더링 줄이자 회색 좋아요, 노란색 싫어요

부모 렌더링 되면 자식 다 렌더링 되니까, state는 최소 컴포넌트로 쪼개자.

]]> <![CDATA[전역 상태 관리 selector]]> https://velog.io/@jay_chae/%EC%A0%84%EC%97%AD-%EC%83%81%ED%83%9C-%EA%B4%80%EB%A6%AC-selector https://velog.io/@jay_chae/%EC%A0%84%EC%97%AD-%EC%83%81%ED%83%9C-%EA%B4%80%EB%A6%AC-selector Wed, 16 Oct 2024 15:54:55 GMT 결론:

전역 상태에서 필요한 값만 select해서 가져오면 렌더링을 최적화 할 수 있다.

예를 들어 전역 상태가 객체 {a:1,b:2}라고 해보자.

이때 컴포넌트A가 a만을 사용하고, 컴포넌트B는 b만 사용한다.

만일 이 때 B가 b의 값을 바꾸었을 때, 컴포넌트 A는 리렌더링이 되지 말아야 한다.

전역 상태 관리 라이브러리는 이런 최적화가 되어 있다.

그래서 해당 컴포넌트에서 필요한 값만 select해서 쓰면 렌더링 최적화를 할 수 있다.

전역 상태관리 라이브러리는 기존의 상태로 새로운 상태를 만들 수 있고, select도 제공하고 있다. 이 기능을 잘 활용해 보자.

예시

//jotai

const counterState = atom(0);
const biggerThan10 = atom((get)=>get(counterState) > 10);

function Temp(){
  const count = useAtomValue(biggerThan10);
}

function Temp2(){
  const [,setCount] =  useAtom(counterStae);
  ...
  //setCount 3에서 2로 변경 
}

Jotai를 예시로 들어 보자.

Atom은 전역 상태 단위를 의미한다.

counterState라는 상태로 biggerThan10이라는 상태를 만들었다.

대신 10보다 클 경우에만 가져온다.

이 경우 biggerThan10을 사용하는 Temp 컴포넌트는 10보다 큰 경우에만 변화가 감지된다.

즉 10보다 큰 수로 바뀔 때만 렌더링이 일어난다.

아래는 나쁜 예시다.

//jotai

const counterState = atom(0);
const biggerThan10 = atom((get)=>get(counterState) > 10);

function Temp(){
  const count = useAtomValue(counterStae);
  cosnt biggerThanTen = count > 10 ? count:null;

  ///biggerThanTen 사용하는 렌더링 있다고 하자
}

이런 경우 다른 컴포넌트에서 counterState가 10보다 작은 값으로 변경이 될 때마다, 이 컴포넌트는 무의이하게 리렌더링 될 거다.

다시 결론, 전역 상태 관리를 할 때 select 해서 쓰면 렌더링 최적화를 이룰 수 있다.

]]> <![CDATA[전역 상태 관리]]> https://velog.io/@jay_chae/%EC%A0%84%EC%97%AD-%EC%83%81%ED%83%9C-%EA%B4%80%EB%A6%AC https://velog.io/@jay_chae/%EC%A0%84%EC%97%AD-%EC%83%81%ED%83%9C-%EA%B4%80%EB%A6%AC Tue, 15 Oct 2024 15:22:53 GMT 결론:

컴포넌트 내부에서만 사용할 수 있는 useState를 극복하기 위해 전역상태관리 라이브러리 등장. 작동방식은 컴포넌트 밖 어딘가에 상태를 둔다.(컴포넌트 최상단 또는 격린된 파일) 그리고 이 외부 상태 변경을 각자의 방식으로 감지해 컴포넌트를 렌더링 한다. 예를 들면 변경이 되면 useState의 set 함수를 돌려 렌더링 시킨다.

전역 상태 관리 조건 3가지

  1. 여러 컴포넌트에서 접근 가능해야 한다.
  2. 상태를 바꾸면 이 상태를 가지고 있는 모든 컴포넌트에서 리렌더링이 일어나야 한다.
  3. 상태가 객체인 경우, 예를 들어 {a:1,b:2} 경우 a만을 사용하는 컴포넌트는 b가 변경 되었을 때 렌더링이 일어나서는 안 된다.

직접 구현

전역 상태 store를 만든다. 아래 코드 참고

type Initializer<T> = T extends unknown ? T | ((prev: T) => T) : never;

type Store<State> = {
  get: () => State
  set: (action: Initializer<State>) => State 
  subscribe: (callback: () => void) => () => void // 변경을 감지하고 싶은 컴포넌트들의 setState 동작 등록
};

export const createStore = <State>(
  initialState: Initializer<State>,
): Store<State> => {

  let state = typeof initialState !== 'function' ? initialState : initialState();

  // 콜백 함수를 저장하는 곳
  const callbacks = new Set<() => void>();

  const get = () => state;
  const set = (nextState: State | ((prev: State) => State)) => {
    state = typeof nextState === 'function' ? (nextState as (prev: State) => State)(state) : nextState;

    // 값이 변경됐으므로 콜백 목록을 순회하면서 모든 콜백을 실행한다.
    callbacks.forEach((callback) => callback());

    return state;
  }

  // 
  const subscribe = (callback: () => void) => {
    // 콜백 등록
    callbacks.add(callback);

    // 클린업 실행 시 삭제해 반복적으로 추가되는 것 방지
    return () => {
      callbacks.delete(callback);
    }
  }

  return {get, set, subscribe};
}

그러나 여기 set을 써서 state 값을 바꾼다고 해서 렌더리이 일어나지는 않는다.

set 함수를 보면 state 값을 바꾼 후에 쌓아둔 콜백 함수들을 실행하는 것을 볼 수 있다.

변경을 감지하고 싶은 컴포넌트들의 useState setter 함수를 전부 돌리기 위함이다.

이 전역 변수 쓰는 모든 컴포넌트를 리렌더링 하기 위해서다.

이 로직은 useStore에 제작, 

export type State = { counter: number; text: string };

const useStoreSelector = (
  store: Store<State>,
  selector: (state: State) => unknown, // store 값에서 어떤 값을 가져올지 정의하는 함수
) => {
  const [state, setState] = useState(() => selector(store.get()));

  useEffect(() => {
    const unsubscribe = store.subscribe(() => {
      const value = selector(store.get());
      setState(value);
    });

    return unsubscribe;
  }, [store, selector]);
  return state;
};

여기서 보면 useState를 사용해서 스토어 값을 return state 해주는 것을 확인 할 수 있다. 그리고 setState를 store 콜백에 저장해주고 있다.

사용법은 아래와 같다.

// Counter.tsx
const Counter = (props: {
  store: Store<{ counter: number; text: string }>;
}) => {
  const { store } = props;
  const counter = useStoreSelector(
    store,
    useCallback(state => state.counter, []),
  );

  function handleClick() {
    store.set(prev => ({ ...prev, counter: prev.counter + 1 }));
  }
  return (
    <>
      <h1>Counter</h1>
      <h3>{counter}</h3>
      <button onClick={handleClick}>+</button>
    </>
  );
};

이렇게 되면 useStore를 사용하는 모든 컴포넌트의 전역 상태를 바라보는 지역 useState가 생긴다. 그리고 지역 useState의 setter 함수가 전역 콜백으로 들어가 전역 set 함수가 샐행될 때 실행되므로 리렌더링이 발생한다.

useCallback(state => state.counter, []),

이 친구(selector)의 정체는 만일 전역 상태가 객체일 때 객체의 일부만 사용하느 경우를 위해서 작성되었다. {a:1,b:2}일 때 b만 사용한 경우 a가 바뀌었을 때 useState의 setter가 돌지 않도록, 즉 리렌더링을 막을 수 있게 된다.

useCallBack을 사용한 이유는 리렌더링이 되었을 경우 불필요한 동작을 막기 위해서다. useStoreSelector 안 useEffect를 보면 의존성 배열에 selector가 들어가 있다. 컴포넌트가 리렌더링 되어서 이 함수가 새로 생성이 되면 같은 로직인 함수 임에도 불구하고 useEffect가 의미없이 한 번 돌아가기 때문이다.

]]> <![CDATA[import { cookies } from 'next/headers']]> https://velog.io/@jay_chae/import-cookies-from-nextheaders https://velog.io/@jay_chae/import-cookies-from-nextheaders Sun, 13 Oct 2024 15:25:45 GMT 결론:

쿠키를 다루고 싶은 경우, 프런트 서버에서 돌아가는 코드는 "next/headers"의 cookies 메소드를 사용하면 된다. 그러나 서버 컴포넌트에서 set cookies는 해줄 수는 없다. 클라이언트에서도 "next/headers"의 cookies 메소드를 사용할 수는 있지만 프런트 서버와 통신을 한다.

이유:

next가 제공하는 쿠키 메소드는 모두 서버 액션이다. get은 프런트 서버가 브라우저로부터 들어오는 요청의 헤더를 읽는 메소드, set은 프런트 서버가 브라우저로 보내는 요청에 쿠키를 set해주라고 명령하는 메소드다.

적용:

왠만하면 클라이언트에서 돌아가는 코드는 브라우저 저장소에 있는 쿠키 값을 활용하는 게 좋겠다. 예를 들어 document.cookie를 사용하면 된다.

쿠키란?

브라우저가 가지고 있는 작은 데이터다. 이렇게 브라우저 store에 로컬 스코리지 처럼 있는 것을 확인 할 수 있다. 브라우저는 어떤 요청을 보낼 때 이 쿠키를 자동으로 요청 헤더에 넣어서 보낸다.

넥스트는 "next/headers"에서 쿠키와 관련된 메소드를 제공하고 있다. https://nextjs.org/docs/app/api-reference/functions/cookies#cookiessetname-value-options

"next/headers"는 서버 컴포넌트에서만 import 할 수 있다. 그러니까 관련 메소드들이 전부 프런트 서버에서 작동하는 서버 액션이라는 의미다.

그러나 이 액션을 클라이언트에서 사용하고 싶으면 어떻게 하면 좋을까?

라이브러리를 사용해도 좋고, 아래와 같이 util 함수로 빼서 클라이언트 컴포넌트에 import 해서 사용하면 된다고 한다.

"use server";

import { cookies } from "next/headers";

export async function setCookie(name: string, value: string) {
  const oneDay = 24 * 60 * 60 * 1000; // Set expiry for one day
  cookies().set(name, value, { expires: Date.now() + oneDay });
}

export async function deleteCookie(name: string) {
  cookies().delete(name);
}

export async function getCookie(name: string) {
  return cookies().get(name)?.value;
}

클라이언트에서 next cookies를 사용한 경우

//test 페이지
"use client";

import React, { useEffect } from "react";

import { getCookie, setCookie } from "@/utils/next-cookie";

export default function TestPage() {
  useEffect(() => {
    async function testCookieAction() {
      await setCookie("test", "cookie");
      await getCookie("test");
    }

    testCookieAction();
  }, []);
  return <div>TestPage</div>;
}

이런 코드가 있다고 해보자.

그런 경우 브라우저 네트워크 창을 확이하면 아래와 같이 프런트 서버와 통신을 한 것을 확인할 수 있다.

가장 먼저 set cookie를 하기 위해 프런트 서버에 요청을 보냈다. 그리고 오는 리스폰스에 Set-Cookie가 있다. 이걸 받은 브러우저는 쿠키를 만들게 된다.

그 다음 get cookie를 하기 위해서 프런트 서버에 또 요청을 하는 것을 확인 할 수 있다. 응답으로 쿠키 값을 주고 있다.

즉, next/headers가 제공하고 있는 cookies 메소드들을 클라이언트에서 사용할 경우 프런트 서버와 통신이 일어난다는 점이다.

이를 클라이언트 코드에 남발할 경우 통신을 많이 하게 돼서 성능에 좋지 않을 수 있다.

get

The cookies function allows you to read the HTTP incoming request cookies from a Server Component or write outgoing request cookies in a Server Action or Route Handler.

넥스트 공식문서를 확인하면 위와 같이 설명하고 있다.

예를 들어 get은 프런트 서버가 프런트 서버에서 오는 요청의 헤더를 읽는 메소드, set은 프런트 서버가 브라우저로 보내는 요청에 쿠키를 set해주라고 명령하는 메소드다.

이걸 어떻게 활용할 수 있을까?

예를 들어 로그인이 되어 있다면 버튼 글자가 프로필, 아니면 로그인인 경우를 생각해 보자. 이 로그인 버튼을 서버 사이드 렌더링 하고 싶다면 어떻게 하는 게 좋을까? 로그인 유무에 대한 정보를 어디에 담으면 좋을까? 로컬 스토리지와 같은 곳은 프런트 서버가 접근하지 못한다. 그런데 쿠키에 저장하면 어떨까? 쿠키가 서버 측에 보내는 요청에 담겨서 가게 된다. 그러면 이때 next/headers를 읽고 사용하면 된다.

import { cookies } from "next/headers";

export default function ServerComponent() {
  const cookieStore = cookies();
  const loggedIn = !!cookieStore.get("accessToken");
  return (
    <button>
        {loggedIn ? "프로필":"로그인"}
    </button>
  );
}

set

HTTP does not allow setting cookies after streaming starts, so you must use .set() in a Server Action or Route Handler.

주의해야 할 점이 하나 있다.

위에서 보면 스트리밍 중일 때는 쿠키를 set 할 수 없다는 얘기를 하고 있다.

import { cookies } from "next/headers";

export default function Test() {
  cookies().set("test", "cookie");
  return <div>Test</div>;
}

예를 들어 위와 같은 코드가 있다고 해보자. 의도는 이 이 컴포넌트가 돌아갈 때마다 쿠키를 set 해주는 거다. 그러나 위와 같은 코드를 돌려보면 에러가 뜬다.

이는 스트리밍과 연관이 있다. 스트리밍이란 서버에서 렌더링 한 걸 조금씩 넘겨주는 걸 말한다. 만일 스트리밍을 하지 않는다면 전부 렌더링한 뒤에 넘겨줘야 한다.'

그래서 내 생각에는 저렇게 서버 컴포넌트가 돌아가면 바로 스트리밍이 시작되는데 그 중간에 Set-Cookie를 헤더에 넣어주지 않는다는 말인 것 같다.

결론은 서버 컴포넌트에서는 구조적으로 setCookie를 해줄 수 없다.

다시 결론

쿠키를 다루고 싶은 경우, 프런트 서버에서 돌아가는 코드는 "next/headers"의 cookies 메소드를 사용하면 된다. 그러나 서버 컴포넌트에서 set cookies는 해줄 수는 없다. 클라이언트에서도 "next/headers"의 cookies 메소드를 사용할 수는 있지만 프런트 서버와 통신을 한다. 그래서 왠만하면 클라이언트에서 돌아가는 코드는 브라우저 저장소에 있는 쿠키 값을 활용하는 게 좋겠다. 예를 들어 document.cookie를 사용하면 된다.

]]> <![CDATA[카카오 소셜 로그인]]> https://velog.io/@jay_chae/%EC%86%8C%EC%85%9C-%EB%A1%9C%EA%B7%B8%EC%9D%B8 https://velog.io/@jay_chae/%EC%86%8C%EC%85%9C-%EB%A1%9C%EA%B7%B8%EC%9D%B8 Fri, 11 Oct 2024 16:00:02 GMT 프런트 개발 들어가기 전에!

카카오 소셜 로그인 4단계로 가기 전에 알아야 할 기초 지식들

  • 인증

    • 인증은 "너는 누구냐?"를 묻는 단계
    • ex) 카카오가 아는 놈인지 모르는 놈인지 확인
    • ex) 로그인

  • 인가

    • 인가는 “너 어디까지 할 수 있어?” 묻는 단계
    • 권한을 확인하는 단계

  • 토큰

    • 토큰은 일종의 증명서, 신분증이다.
    • 토큰 값으로 인증,인가를 간편하게 한다.

프런트 구현 전에 필요한 세팅

  • kakao developers에서 진행중인 프로젝트 id 받아놓아야 합니다.
  • 개발 test app인 경우 kakao developers에 등록된 이메일만 로그인 가능합니다.
  • 인가 코드를 받을 redirect_url도 등록 해놓아야 합니다.

카카오 소셜 로그인 구현 과정 4단계

  1. https://kauth.kakao.com/oauth/authorize ← 일단 여기로 가서 로그인 합니다.

    • 위 링크에 searchParams을 꼭 넣어줘야 함

      • response_type: code로 고정

      • client_id: 카카오한테 받은 우리 서비스 id

    - **redirect_url**: 로그인 성공하고 동의하고 가야하는 페이지, 3번 단계에 나옴

    - **scope: 어떤 정보 받을지**

    - ex) `https://kauth.kakao.com/oauth/authorize?response_type=code&client_id=1ndma,fnlemsm&redirect_uri=https://localhost:3000/auth/login/oauth/kakao&scope=profile_nickname,account_email`
     저 링크로 들어가면 카카오 로그인 화면이 뜹니다
  1. 로그인(인증)에 성공하면 이제 인가 단계
    • 동의 화면이 나옵니다.
    • 특정 정보에 접근하는 거에 동의합니다.
  1. 인가에 성공하면 카카오 측에서 redirect_url로 이동시켜 줌
    • redirect_url에 해당하는 페이지를 만들어놔야 함
    • 카카오 측에서 인가 코드를 searchParams에 넣어줌 ex) https://localhost:3000/redirect_url?code=oauthPermittedCode
  1. 인가 코드로 카카오 측에 토큰을 요청한다. https://kauth.kakao.com/oauth/token ← 요기로 인가 코드 넘겨주면 토큰을 준다.

]]> <![CDATA[hydrate]]> https://velog.io/@jay_chae/hydrate https://velog.io/@jay_chae/hydrate Thu, 10 Oct 2024 17:39:09 GMT 결론: SSR 시 서버 렌더링(트리) 된 것과 클라이언트에서 렌더링(트리) 된 것이 다르면 안 된다.(hydration 오류)

이유: paint 과정이 두 번 발생해서 좋지 않다.

설명:

  1. ReactDom.hydrate
ReactDom.hydrate(리액트컴포넌트, 서버에서 만든 HTML)

서버에서 받은 html을 받는다. -> 화면에 보여준다. -> hydrate가 서버에서 만든 HTML과 리액트 컴포넌트를 받는다 -> hydrate가 리액트 컴포넌트를 토대로 다시 DOM을 만든다, -> 만든 DOM을 서버에서 받은 HTML과 비교한다. -> 일치하면 자바스크립트를 적용해서 interactive하게 만든다. -> 일치하지 않으면 새로 만든 DOM으로 화면에 다시 그린다.(hydration 오류)

  1. hydrate error 발생 예시

  1. 데이터 패칭 경우

서버에서 서버 패치 받은 후 SSR 했을 경우, 클라이언트에서 hydration 하기 위해 또 패치 받아서 렌더링 후 비교하고 js 적용하면 패치를 두 번 받게 된다. 이런 경우 패치를 한 번 받도록 처리를 해준다. 프레임워크가 이를 잘 해주고 있다.

]]> <![CDATA[SSR vs SPA]]> https://velog.io/@jay_chae/SSR-vs-SPA https://velog.io/@jay_chae/SSR-vs-SPA Thu, 10 Oct 2024 08:08:25 GMT 결론: SPA와 SSR 둘 다 알아야 함 이유: SPA와 SSR 의 장단점을 섞어서 개발해야 하기 때문

적용: 최초 진입은 SSR로 하고 그 이후는 내려 받은 자바스크립트로 SPA처럼 작동하게 한다.

spa: 최초 접근할 때 브라우저가 필요한 자바스크입트를 모두 받는다. 이후 라우팅은 이미 받은 자바스크립를 사용해 페이지를 만든다.

ssr: 페이지 마다 서버에 요청해서 받는다.

spa는 최초에 전부 받아야 하기 때문에 최초 진입이 느리다. 그리고 검색 엔진 못은 자바스크립트를 돌리지 않기 때문에 SEO에 약하다. 대신 한 번 진입하면 매우 부드럽고 좋은 사용자 경험을 제공한다.

ssr 장점

  • 최초 진입 빠르다.
  • SEO 좋다.
  • 누적 레이아웃 변경이 적다.
  • 사용자 디바이스 성능에서 자유
  • 보안에 좋다

단점

  • 서버를 고려하면서 개발해야 함
  • 서버 구축해야 함
  • 렌더링 지연 가능성
]]> <![CDATA[화면 크기 전역 상태로 관리]]> https://velog.io/@jay_chae/%ED%99%94%EB%A9%B4-%ED%81%AC%EA%B8%B0-%EC%A0%84%EC%97%AD-%EC%83%81%ED%83%9C%EB%A1%9C-%EA%B4%80%EB%A6%AC https://velog.io/@jay_chae/%ED%99%94%EB%A9%B4-%ED%81%AC%EA%B8%B0-%EC%A0%84%EC%97%AD-%EC%83%81%ED%83%9C%EB%A1%9C-%EA%B4%80%EB%A6%AC Sun, 22 Sep 2024 11:19:34 GMT 문제

우주윗미 프로젝트 리팩토링 했어요.

문제: 화면을 조금만 바꿔도 handleResize가 엄청 많이 돌아간다.

상황

// 커스텀 훅 제작
"use client";

import { useEffect, useState } from "react";

const useIsMobile = (): boolean => {
  const [isMobile, setIsMobile] = useState(false);

  useEffect(() => {
    const handleResize = () => {
      setIsMobile(window.innerWidth <= 480);
    };

    handleResize();

    window.addEventListener("resize", handleResize);

    return () => {
      window.removeEventListener("resize", handleResize);
    };
  }, []);

  return isMobile;
};

export default useIsMobile;

상황1: 화면 크기가 모바일인지 아닌지에 따라서 조건부 렌더링이 필요. 상황2: 화면 크기를 검사하는 useIsMobile 훅을 만듬. 상황3: 조건부 렌더링이 필요한 컴포넌트가 여러 곳에 있다. 상황4: 여러 곳에서 useIsMobile 훅을 사용 중.

문제 원인

원인1: resize는 화면 크기가 바뀔 때 마다 코드가 돌아간다.

원인2: useIsMobile를 여러 곳에서 사용했기 때문에 동일한 로직의 이벤트 리스너가 여러 번 등록된다.

원인1 + 원인2: 동일한 이벤트 핸들러 여러 개가 화면 크기가 바뀔 때 마다 돌아간다.

해결

해결1:

isMobile 변수를 zotai를 활용해 전역 상태로 만든다.

//전역 상태  생성
import { atom } from "jotai";

/** 모바일 화면인지 아닌지 */
const isMobileAtom = atom<boolean>(false);

export default isMobileAtom;

=> 화면 크기는 어떤 컴포넌트에서나 똑같다. 그러므로 동일한 값을 가진 상태를 여러개 만들 이유가 없다. 예를 들어 다크모드이거나 언어가 영어로 설정 된다면 모든 컴포넌트에서 다크이고 영어다. 그래서 이런 경우 전역상태로 관리하곤 한다. 화면 크기도 마찬가지다.

해결2:

화면 크기가 필요한 곳에서는 전역 상태 값을 이용하도록 한다.

// 훅 로직 변경
"use client";

import { useAtom } from "jotai";

import { isMobileAtom } from "@/stores";

const useIsMobile = (): boolean => {
  const [isMobile] = useAtom(isMobileAtom);

  return isMobile;
};

export default useIsMobile;

=> 이벤트 리스너를 등록하고 빼는 로직은 전부 삭제. 여러 곳에서 동일한 이벤트 리스너를 등록할 필요가 없다.

해결3:

화면 크기를 검사하는 로직을 가진 컴포넌트 하나를 제작해서 최상위에 넣는다.

// example
export default function RootLayout({
  children,
}:{
  children: React.ReactNode;
}) {
  return (
    <html lang="ko">
      <body>
        <MobileSizeWatcher /> // 이 친구!
        <Header />
        {children}
      </body>
    </html>
  );
}

=> Next.js & app router를 사용 중이기 때문에 최상단 레이아웃에 컴포넌트를 넣어주었다. 저 컴포넌트 안에서만 화면 크기를 검사하고 isMobile 전역상태를 업데이트 해준다.

해결4:

resize 대신 matchMedia 사용.

"use client";

import { useAtom } from "jotai";
import { useEffect } from "react";

import { isMobileAtom } from "@/stores";

export default function MobileSizeWatcher() {
  const [, setIsMobile] = useAtom(isMobileAtom);
  useEffect(() => {
    const mediaQuery = window.matchMedia("(max-width: 480px)");

    const handleMediaQueryChange = (e: MediaQueryListEvent) => {
      setIsMobile(e.matches);
    };

    // 초기 렌더링 시 확인
    setIsMobile(mediaQuery.matches);

    // 미디어 쿼리 변경 시 이벤트 등록
    mediaQuery.addEventListener("change", handleMediaQueryChange);

    return () => {
      mediaQuery.removeEventListener("change", handleMediaQueryChange);
    };
  }, [setIsMobile]);

  return null;
}

=> matchMedia는 미디어 쿼리가 일치하는지 검사하는 메소드. 이 메소드를 사용해서 모바일 사이즈보다 작아졌을 때만 함수가 돌아가도록 했다.

결과

결과1: 모바일인지 아닌지 정보를 가진 변수를 전역 변수 하나로만 관리 됨.

결과2: 이벤트 리스너가 하나만 등록됨.

결과3: 화면 크기가 모바일로 줄어들 때 한번만 함수가 돈다.

]]> <![CDATA[matchMedia]]> https://velog.io/@jay_chae/matchMedia https://velog.io/@jay_chae/matchMedia Sun, 22 Sep 2024 10:27:52 GMT 핵심: 미디어 쿼리 조건이 현재 환경과 일치하는지 확인하는 메서드. 실천: matchMedia()를 통해 미디어 쿼리를 감지하고, 화면 크기나 디스플레이 조건이 변경될 때마다 해당 이벤트를 처리하고자 할 때 사용


///matchMedia와 change 이벤트 활용
let mediaQuery = window.matchMedia("(max-width: 600px)");

mediaQuery.addEventListener("change", (e) => {
  if (e.matches) {
    console.log("화면 너비가 600px 이하로 변경되었습니다.");
  } else {
    console.log("화면 너비가 600px 이상으로 변경되었습니다.");
  }
});

vs

//reszie활용
window.addEventListener("resize", () => {
  console.log("브라우저 창 크기가 변경되었습니다.");
});

change는 미디어 쿼리 조건이 변하는 순간에 반응. resize는 창 크기 자체가 변화할 때 반응하는 이벤트.

=> 브라우저 크기가 특정 이상이나 이하 일 때 로직이 필요하다면 matchMedia와 change 이벤트 활용하는 게 더 효율적이다. 왜냐하면 matchMedia로 특정 크기 일 때만 코드를 돌리도록 할 수 있기 때문. resize는 화면 크기가 좀만 변해도 코드를 돌리게 된다.

]]> <![CDATA[하위 폴더에서 husky 설정]]> https://velog.io/@jay_chae/%ED%95%98%EC%9C%84-%ED%8F%B4%EB%8D%94%EC%97%90%EC%84%9C-husky-%EC%84%A4%EC%A0%95 https://velog.io/@jay_chae/%ED%95%98%EC%9C%84-%ED%8F%B4%EB%8D%94%EC%97%90%EC%84%9C-husky-%EC%84%A4%EC%A0%95 Wed, 18 Sep 2024 10:10:53 GMT 상황: husky 폴더가 .git 폴더보다 하위에 있는 폴더 구조.

문제: husky와 git 파일은 동일 선상에 없으면 돌아가지 않는다.

해결: package.json에 script 추가, husky 파일에 코드 추가

문제 상황

├── project
│    ├── git //git 폴더
│   ├── backend
│   └── frontend
│       └── husky //허스키 폴더가 git 폴더 보다 하위에 있다.
│            ├──commit-msg
│           ├── pre-commit
│           └── pre-push

프로젝트 폴더 구조는 위와 같다. backend 폴더와 frontend 폴더가 한 곳에 있다. 커밋을 포함해 깃 관리를 project 최상 위에서 하고 있다. 그래서 git 폴더가 최상위에 있는 상황이다.

git init 명령어를 실행하면 현재 디렉토리가 Git 저장소로 초기화. 이때 .git이라는 숨겨진 디렉토리가 생성된다. .git 폴더 안에는 Git이 버전 관리를 수행하는 데 필요한 파일과 데이터가 저장됩니다.

백과 프런트를 한 곳에서 관리하기로 했기 때문에 이런 폴더 구조가 생겼다. 이러한 상황에서 frontend 폴더 안에 있는 코드만 husky를 사용해 린트 등을 검사하고 싶었다.

Husky는 Git 훅(Git Hooks)을 쉽게 설정하고 관리할 수 있게 도와주는 도구다. Git 훅은 Git에서 특정 이벤트가 발생할 때 자동으로 실행되는 스크립트다. 예를 들어, 커밋을 하기 전에 코드 스타일을 검사하거나, 푸시 전에 테스트를 실행하는 등의 작업을 자동화할 수 있다.

그러나 역시나 husky는 돌아가지 않았다.

git 폴더의 위치 때문일 수도 있겠다는 생각이 들었다. 아무래도 git 관리를 담당하고 있는 폴더와 husk는 같은 선상에 있어야 하지 않을까? 정답이었다.

문제 1

간단한 해결책으로는 npm이나 yarn으로 최상 위에 husky를 설치하고 husky 폴더를 최상 위로 뺴는 방법이 있었다.

그러나 그렇게 되면 backend 코드에도 frontend lint나 fomatter등이 적용되고 말거다. 그러므로 이 방법은 사용할 수 없다.

해결책 2


//package.json
"scripts": {
    "postinstall": "cd .. && husky ./frontend/.husky"
  },

먼저 frontend 안에 있는 package.json에 script를 추가했다.

scritps

scripts는 package.json 파일 내에서 정의되는 속성 중 하나다. Node.js 프로젝트에서 자주 사용하는 명령어들을 관리하고 자동화하는 역할을 한다. 프로젝트 작업에 필요한 명령어들을 간편하게 실행할 수 있도록 도와준다.

postinstall

postinstall은 install 명령어가 실행된 후 자동으로 실행된다. 즉, 프로젝트에 필요한 패키지들을 설치한 후에 postinstall 스크립트가 실행되도록 설정해준다. husky 패키지는 설치된 후 husky install 이라는 명령어가 실행되어야 하기 때문에 패키지가 설치 된 후 실행되는 라이프 사이클 스크립트를 사용해야 합니다. NPM을 사용하는 경우 prepare라는 스크립트를 사용할 수 있지만 Yarn 2+은 prepare 스크립트를 지원하지 않기 때문에 postinstall이라는 스크립트를 사용해야 한다.

"cd .. && husky ./frontend/.husky"

cd .. 으로 일단 상위 폴더로 이동한다. -> 상위 폴더에서 frontend/.husky 폴더에 있는 Husky 설정을 설치하고 적용한다.

문제 2

위 과정을 완료하면 husky가 돌아는 간다. 그러나 문제는 잘 안 돌아간다.

husky 폴더 안에 있는 이 3가지 파일을 작성했다.

  1. commit-msg (커밋 메시지가 특정 규칙을 따르는지 검사)
  2. pre-commit (커밋이 실행되기 전에 실행됩니다.)
  3. pre-push(코드를 원격 저장소로 푸시하기 전에 실행됩니다.)

커밋 전에, 푸쉬 전에 코드를 검사하고자 했다.

그런데 이번 문제는 기 때문에 발생한다. husky가 실행될 때 위에 cd ..으로 인해 최상위에 있게 된다. 그런데 lint 관련 설정 파일이 frontend 폴더 안에 있어서 lint를 제대로 검사해주지 못한다.

해결

cd ./frontend 명령어를 husky 파일에 추가해준다.

// commit-msg 
#!/bin/sh
cd ./frontend
npx --no-install commitlint --edit "$1"

cd ./frontend는 현재 디렉토리에서 frontend라는 폴더로 이동하라는 뜻입니다. 이유는, commitlint의 설정 파일 또는 실행 환경이 frontend 폴더 안에 존재하기 때문입니다.

정리

husky와 git 폴더는 같은 선상에 있어야 돌아간다. 그러나 만일 다른 경우 package.json 의 postintall scripts를 활용해 같은 선상에서 husky를 적용할 수 있도록 한다.

]]>