real-bird.log

[Next.js] 공식 문서만 보고 Next.js 익히기(5)

Fri, 08 Dec 2023 19:20:15 GMT

공식 문서 보기를 돌같이 하는 버릇을 고치자!

11. Handling Errors

예기치 못한 에러 발생은 사용자에게 안 좋은 경험을 심어준다. 거기에 에러 스택까지 보여준다면? 사용자에게도, 개발자에게도 최악의 페이지가 될 것이다. Next.js에서는 파일로 에러를 핸들링하는 기능을 제공한다. 에러 처리가 필요한 폴더 하위에 error.tsx를 추가한다.

'use client';

import { useEffect } from 'react';

export default function Error({
  error,
  reset,
}: {
  error: Error & { digest?: string };
  reset: () => void;
}) {
  useEffect(() => {
    // Optionally log the error to an error reporting service
    console.error(error);
  }, [error]);

  return (
    
      Something went wrong!
      
    
  );
}

error는 JS의 에러 객체이고, reset은 에러 경계로 되돌리는 함수이다. reset을 실행하면 에러가 발생한 라우트의 리렌더링을 시도하도록 유도할 수 있다.

error.tsx는 전체 에러를 핸들링하는 역할이라면, not-found.tsx는 404 error를 핸들링한다. not-found가 필요한 라우트 하위에 파일을 생성한다.

// app/dashboard/invoices/[id]/edit/not-found.tsx
import Link from 'next/link';
import { FaceFrownIcon } from '@heroicons/react/24/outline';

export default function NotFound() {
  return (
    
      
      404 Not Found
      Could not find the requested invoice.
      
        Go Back
      
    
  );
}

페이지에서는 notfound() 함수를 호출한다.

// app/dashboard/invoices/[id]/edit/page.tsx

import { fetchInvoiceById, fetchCustomers } from '@/app/lib/data';
import { updateInvoice } from '@/app/lib/actions';
+ import { notFound } from 'next/navigation';

export default async function Page({ params }: { params: { id: string } }) {
  const id = params.id;
  const [invoice, customers] = await Promise.all([
    fetchInvoiceById(id),
    fetchCustomers(),
  ]);

+  if (!invoice) {
+    notFound();
+  }

  // ...
}

12. Improving Accessibility

접근성은 장애인을 포함한 모든 사람이 사용할 수 있는 애플리케이션을 설계하고 구현하는 것을 말한다. 참고 web.dev - learn accessibility

12-1. Using the ESLint accessibility plugin in Next.js

Next.js는 기본적으로 eslint-plugin-jsx-a11y를 포함하고 있다. 이 플러그인은 aria-*, alt, role 등 접근성에 대한 이슈를 체크해준다. "lint": "next lint" 스크립트를 추가하여 검사할 수 있다. 예를 들어, 이미지의 alt가 없다면 검사했을 때의 경고 문구이다.

./app/ui/invoices/table.tsx
29:23  Warning: Image elements must have an alt prop, either with meaningful text, or an empty string for decorative images.  jsx-a11y/alt-text

12-2. Improving form accessibility

사용하고 있는 form에서는 접근성 향상을 위해 3가지를 이미 실천하고 있다.

Semantic HTML : div 대신 input, option 등의 시멘틱 태그를 사용하여 사용자에게 양식을 탐색하고 이해하기 쉽게 만든다.
Labelling : label과 htmlFor를 사용하면 사용자가 label를 클릭하여 해당 입력 필드에 집중할 수 있다.
Focus Outline : 탭을 눌러 필드에 초점이 맞춰졌을 때 윤곽선이 표시되도록하여 키보드 및 화면 리더 사용자가 양식의 현재 위치를 이해하는 데 도움이 된다.

일반적인 접근성 설정을 했지만, form validation을 충족하지는 못한다. 현재 비어 있는 양식을 제출하면 에러가 발생하기 때문이다.

12-3. Form validation

클라이언트 측에서 간단한 대응은 input에 required 속성을 추가하는 것이다.

일반적으로는 괜찮지만, dev tool에서 해당 요소의 required 속성을 지우면 검증이 먹히지 않는다. Next.js에서는 서버 측 대안을 제시한다. 서버 측 검증에서는

데이터를 데이터베이스로 보내기 전에 데이터가 예상되는 형식인지 확인한다.
악의적인 사용자가 클라이언트 측 유효성 검사를 우회하는 위험을 줄일 수 있다.
유효한 데이터로 간주되는 데이터에 대한 신뢰할 수 있는 단일 소스를 확보한다.

useFormState를 사용하여 서버 측 검증을 진행한다. 훅을 사용하므로 use client를 명시해 클라이언트 컴포넌트로 전환한다.

'use client';

// ...
import { useFormState } from 'react-dom';

useFormState는 useReducer와 유사한 실험적 기능이다. action과 initialState를 인자로 받고, state와 dispatch를 반환한다.

에 dispatch를 주입한다.

// ...
import { useFormState } from 'react-dom';

export default function Form({ customers }: { customers: CustomerField[] }) {
  const initialState = { message: null, errors: {} };
  const [state, dispatch] = useFormState(createInvoice, initialState);

  return ...;
}

zod를 이용해 검증할 데이터 스키마를 추가한다.

const FormSchema = z.object({
  id: z.string(),
  customerId: z.string({
    invalid_type_error: 'Please select a customer.',
  }),
  amount: z.coerce
    .number()
    .gt(0, { message: 'Please enter an amount greater than $0.' }),
  status: z.enum(['pending', 'paid'], {
    invalid_type_error: 'Please select an invoice status.',
  }),
  date: z.string(),
});

useFormState를 위해 createInvoice에 prevState를 추가한다. 사용하지 않더라도 useFormState가 필수로 요구하기 때문이다.

// This is temporary until @types/react-dom is updated
export type State = {
  errors?: {
    customerId?: string[];
    amount?: string[];
    status?: string[];
  };
  message?: string | null;
};

export async function createInvoice(prevState: State, formData: FormData) {
  // ...
}

zod의 parse 대신 safeParse로 교체한다. safeParse는 성공 또는 실패 시의 객체를 반환하여 try/catch 구문에 넣지 않아도 유효성 검사를 처리할 수 있다.

export async function createInvoice(prevState: State, formData: FormData) {
  // Validate form fields using Zod
  const validatedFields = CreateInvoice.safeParse({
    customerId: formData.get('customerId'),
    amount: formData.get('amount'),
    status: formData.get('status'),
  });

  // If form validation fails, return errors early. Otherwise, continue.
  if (!validatedFields.success) {
    return {
      errors: validatedFields.error.flatten().fieldErrors,
      message: 'Missing Fields. Failed to Create Invoice.',
    };
  }

  // ...
}

검증을 통과하지 못하면 useFormState의 state는 다음과 같은 에러 객체를 반환한다.

{
  errors: { customerId: Array(1), amount: Array(1), status: Array(1) },
  message: "Missing Fields. Failed to Create Invoice."
}

에러가 발생하면 화면에 표시하는 코드를 작성한다.


  {/* ... */}
    
+   
+     {state.errors?.customerId &&
+       state.errors.customerId.map((error: string) => (
+         
+           {error}
+         
+       ))}
+   
    {/* ... */}

aria-describedby="customer-error"는 id="customer-error"와 관계를 형성해 오류가 발생하면 화면 판독기가 해당 설명을 읽게 된다. aria-live="polite"는 오류가 발생했음을 알릴 때 사용자를 방해하지 않고 유휴 상태일 때만 알린다.

13. Adding Authentication

Authentication(인증)은 웹앱의 핵심 중 하나로, 실제 유저와 시스템이 바라는 유저가 같은지 확인하는 단계이다. 인증의 방법에는 여러 가지가 있다. 아이디와 비밀번호 입력 후 인증 코드를 발급한다거나 Google이나 Naver 등의 서드 파티를 이용한다. 혹은 외부 앱을 이용한 2단계 인증(2FA)으로 보안을 강화할 수도 있다. 이러한 인증 방법은 로그인 정보에 접근하더라도 고유 토큰 없이는 액세스할 수 없도록 한다.

13-1. Authentication vs. Authorization

웹 개발에서 Authentication과 Authorization은 비슷하지만 서로 다른 역할을 하는 개념이다.

Authentication(인증)은 사용자가 자신이 말한 사람이 맞는지 확인하는 것이다.

Authorization(인가)은 사용자의 신원이 확인되면 애플리케이션의 어떤 부분에 대한 권한이 있는지 결정하는 것이다.

13-2. NextAuth.js

여기서 사용하는 인증 라이브러리는 NextAuth.js이다. 세션 관리, 로그인 및 로그아웃, 기타 인증과 관련된 복잡한 과정에 대한 솔루션을 제공한다. Next.js @14와 호환되는 버전을 npm install next-auth@beta로 설치한다.

다음으로 openssl rand -base64 32로 비밀키를 생성하고, .env에 추가한다.

AUTH_SECRET=your-secret-key

루트 폴더에 auth.config.ts 파일을 생성해 NextAuth에 대한 옵션을 추가한다.

import type { NextAuthConfig } from 'next-auth';

export const authConfig = {
  pages: {
    signIn: '/login',
  },
  callbacks: {
    authorized({ auth, request: { nextUrl } }) {
      const isLoggedIn = !!auth?.user;
      const isOnDashboard = nextUrl.pathname.startsWith('/dashboard');
      if (isOnDashboard) {
        if (isLoggedIn) return true;
        return false; // Redirect unauthenticated users to login page
      } else if (isLoggedIn) {
        return Response.redirect(new URL('/dashboard', nextUrl));
      }
      return true;
    },
  },
  providers: [], // Add providers with an empty array for now
} satisfies NextAuthConfig;

pages 옵션을 통해 로그인, 로그아웃, 오류 페이지 경로 등을 지정할 수 있다. signIn: '/login'을 추가하면 NextAuth의 기본 페이지가 아닌 커스텀 로그인 페이지로 리디렉션한다(고 한다. 뭔 소린지 모르겠다.).

callbacks은 Next.js의 middleware를 통해 로그인 요청이 완료되기 전 권한이 있는지 확인하는 데 사용한다. auth는 유저의 session, request 속성 등이 들어있다.

providers는 다양한 로그인 옵션을 나열하는 배열이다. NextAuth의 구성을 충족하기 위해 일단 빈 배열로 설정되어 있다.

authConfig 객체를 가져올 middleware.ts 파일도 루트 폴더에 생성한다.

import NextAuth from 'next-auth';
import { authConfig } from './auth.config';

export default NextAuth(authConfig).auth;

export const config = {
  // https://nextjs.org/docs/app/building-your-application/routing/middleware#matcher
  matcher: ['/((?!api|_next/static|_next/image|.*\\.png$).*)'],
};

NextAuth 객체를 초기화하고, matcher에 따라 middleware를 실행한다. 배열에 담긴 문자열은 api나 _next/static, _next/image, .png로 끝나는 경로를 제외하고 middleware를 실행한다는 의미이다. 이렇게 하면 미들웨어가 보호된 경로에서 인증이 확인될 때까지 렌더링을 하지 않아 성능 향상의 이점이 생긴다.

패스워드는 보통 생성할 때 해싱하여 저장한다. 이 프로젝트에서는 bcrypt 패키지를 사용하여 해싱 처리했는데, 문제는 Node API에 의존하는 패키지이기 때문에 미들웨어에서는 실행할 수 없다는 점이다. 이를 위해 authConfig 객체를 퍼트리는 auth.ts 파일을 새로 만든다.

import NextAuth from 'next-auth';
import { authConfig } from './auth.config';

export const { auth, signIn, signOut } = NextAuth({
  ...authConfig,
});

NextAuth에 providers 옵션을 추가해야 한다. providers는 Google 또는 GitHub와 같은 다양한 로그인 옵션을 나열하는 배열이다. 여기서는 Credentials provider만 사용한다.

import NextAuth from 'next-auth';
import { authConfig } from './auth.config';
import Credentials from 'next-auth/providers/credentials';

export const { auth, signIn, signOut } = NextAuth({
  ...authConfig,
  providers: [Credentials({})],
});

zod를 사용하여 이메일과 비밀번호 유효성을 검사한 후 유저 정보를 확인하자.

import NextAuth from 'next-auth';
import { authConfig } from './auth.config';
import Credentials from 'next-auth/providers/credentials';
import { z } from 'zod';
import { sql } from '@vercel/postgres';
import type { User } from '@/app/lib/definitions';
import bcrypt from 'bcrypt';

async function getUser(email: string): Promise {
  try {
    const user = await sql`SELECT * FROM users WHERE email=${email}`;
    return user.rows[0];
  } catch (error) {
    console.error('Failed to fetch user:', error);
    throw new Error('Failed to fetch user.');
  }
}

export const { auth, signIn, signOut } = NextAuth({
  ...authConfig,
  providers: [
    Credentials({
      async authorize(credentials) {
        const parsedCredentials = z
          .object({ email: z.string().email(), password: z.string().min(6) })
          .safeParse(credentials);
        if (parsedCredentials.success) {
          const { email, password } = parsedCredentials.data;
          const user = await getUser(email);
          if (!user) return null;

          const passwordsMatch = await bcrypt.compare(password, user.password);

          if (passwordsMatch) return user;
        }
        return null;
      },
    }),
  ],
});

로그인 action을 작성한 다음 form을 수정한다.

// lib/actions

import { signIn } from '@/auth';
import { AuthError } from 'next-auth';

// ...

export async function authenticate(
  prevState: string | undefined,
  formData: FormData,
) {
  try {
    await signIn('credentials', formData);
  } catch (error) {
    if (error instanceof AuthError) {
      switch (error.type) {
        case 'CredentialsSignin':
          return 'Invalid credentials.';
        default:
          return 'Something went wrong.';
      }
    }
    throw error;
  }
}

// login-form

'use client';

import { lusitana } from '@/app/ui/fonts';
import {
  AtSymbolIcon,
  KeyIcon,
  ExclamationCircleIcon,
} from '@heroicons/react/24/outline';
import { ArrowRightIcon } from '@heroicons/react/20/solid';
import { Button } from '@/app/ui/button';
import { useFormState, useFormStatus } from 'react-dom';
import { authenticate } from '@/app/lib/actions';

export default function LoginForm() {
  const [errorMessage, dispatch] = useFormState(authenticate, undefined);

  return (
    
      
        
          Please log in to continue.
        
        {/* ... */}
        
        
          {errorMessage && (
            <>
              
              {errorMessage}
            
          )}
        
      
    
  );
}

function LoginButton() {
  const { pending } = useFormStatus();

  return (
    
  );
}

로그아웃 기능도 추가한다.

import Link from 'next/link';
import NavLinks from '@/app/ui/dashboard/nav-links';
import AcmeLogo from '@/app/ui/acme-logo';
import { PowerIcon } from '@heroicons/react/24/outline';
import { signOut } from '@/auth';

export default function SideNav() {
  return (
    
      // ...
      
        
        
         {
            'use server';
            await signOut();
          }}
        >
          
        
      
    
  );
}

use server를 최상단이 아닌 action 속성 내에 선언하는 게 신기했다. 이게 그 유명한 밈으로 탄생한 부분인 듯하다.

아무튼 다 작성하고 나니 위 authConfig에서 궁금했던 signIn: '/login'의 정체를 알았다. 이것을 설정하지 않으면 비로그인 유저가 인증이 필요한 페이지로 접근했을 때 리디렉션하지 않고 not-found를 실행한다. 설정했다면 자동으로 로그인 페이지로 연결한다.

14. Adding Metadata

SEO와 콘텐츠 공유에 관련해서 웹앱의 metadata는 매우 중요한 요소이다. 최종장에서는 metadata에 대해서 학습한다.

14-1. What is metadata?

metadata는 웹 페이지에 대한 추가 세부 정보를 제공한다. 사용자에게는 표시되지 않지만, 태그 내에 포함되어 백그라운드에서 동작한다. 이는 검색 엔진 등이 웹 페이지를 더 잘 이해하도록 돕는다. SEO를 향상시키는 데 중요한 역할을 하며, 적절한 metadata는 검색 엔진에서 웹 페이지의 순위를 높인다.

Next.js가 제공하는 Metadata API에는 두 가지 방식이 있다. 하나는 Config-based로, 정적인 metadata 객체를 export하거나 동적으로 metadata를 생성하는 함수를 layout.tsx나 page.tsx에서 export하는 방식이다. 다른 하나는 File-based로, favicon.ico, opengraph-image.jpg, robots.txt, sitemap.xml 등 특수한 목적의 이름을 가진 파일들을 사용한다. 두 방식을 사용하면 Next.js가 자동으로 적절한 요소를 생성한다.

예시로, /public 폴더에 favicon.ico와 opengraph-image.jpg 파일이 들어있다. 이것을 /app 폴더로 옮기면 자동으로 head에 추가된다.

layout.tsx나 page.tsx 파일 내에 metadata 객체를 포함할 수도 있다.

// app/layout.tsx

import { Metadata } from 'next';

export const metadata: Metadata = {
  title: 'Acme Dashboard',
  description: 'The official Next.js Course Dashboard, built with App Router.',
  metadataBase: new URL('https://next-learn-dashboard.vercel.sh'),
};

export default function RootLayout() {
  // ...
}

특정 페이지에 추가하여 해당 페이지의 정보만 담을 수 있다.

// dashboard/invoices
import { Metadata } from 'next';

export const metadata: Metadata = {
  title: 'Invoices | Acme Dashboard',
};

export default async function Page() {}

하지만 이렇게 입력하면 문제가 하나 있다. 회사명과 같은 주요 정보가 바뀌었을 때 모든 페이지의 metadata를 찾아 수정해야 한다. 그렇게 하는 대신 title.template을 사용하여 기본값을 정하고 페이지마다 다른 title을 부여할 수 있다.

// app/layout.tsx

import { Metadata } from 'next';

export const metadata: Metadata = {
  title: {
    template: '%s | Acme Dashboard',
    default: 'Acme Dashboard',
  },
  description: 'The official Next.js Learn Dashboard built with App Router.',
  metadataBase: new URL('https://next-learn-dashboard.vercel.sh'),
};

// dashboard/invoices

export const metadata: Metadata = {
  title: 'Invoices',
};

[Next.js] 공식 문서만 보고 Next.js 익히기(4)

Tue, 05 Dec 2023 14:53:01 GMT

공식 문서 보기를 돌같이 하는 버릇을 고치자!

9. Adding Search and Pagination

이 장에서는 URL search params을 통한 검색과 pagination을 학습한다.

9-1. Why use URL search params?

URL search params를 이용하여 검색을 하면 몇 가지 이점이 있다.

북마크 및 공유 가능 : 검색 정보가 URL에 담겨 있기 때문에 사용자는 북마크에 추가해 나중에 참조하거나 공유하기 쉽다.
서버 측 렌더링과 초기 로드 : URL 매개변수를 서버에서 직접 조작하여 초기 상태 렌더링을 더 처리하기 쉽다.
분석 및 추적: 검색 쿼리와 필터를 URL에 직접 넣으면 추가적인 클라이언트 측 로직 없이도 사용자 행동을 더 쉽게 추적할 수 있다.

URL search params를 이용하는데 Next.js의 다음 훅들을 사용한다.

useSearchParams : 현재 URL의 매개변수에 액세스한다. 예를 들어, /dashboard/invoices?page=1&query=pending에 대한 검색 매개 변수는{page: '1', query: 'pending'}이다.
usePathname : 현재 URL의 경로 이름을 읽는다. 예를 들어, /dashboard/invoices의 경우, 사용 경로명은 /dashboard/invoices를 반환한다.
useRouter : 클라이언트 구성 요소 내에서 경로 간 탐색을 활성화한다.

9-2. Adding the search functionality

검색의 첫 번째 순서는 유저의 입력 정보를 얻는 것으로, 클라이언트 컴포넌트에서 이루어진다. 때문에 검색 파일 최상단에 use client를 작성하여 클라이언트 컴포넌트임을 명시해야 이벤트 리스너나 훅을 사용할 수 있다.

'use client'; // client component

import { useSearchParams, usePathname, useRouter } from 'next/navigation';

export default function Search({ placeholder }: { placeholder: string }) {
  const searchParams = useSearchParams();
  const pathname = usePathname();
  const { replace } = useRouter();

  function handleSearch(term: string) {
    console.log(`Searching... ${term}`);

    const params = new URLSearchParams(searchParams);
    if (term) {
      params.set('query', term);
    } else {
      params.delete('query');
    }
    replace(`${pathname}?${params.toString()}`);
  }

  return (
    
      
        Search
      
       {
          handleSearch(e.target.value);
        }}
        defaultValue={searchParams.get('query')?.toString()}
      />
    
  );
}

URLSearchParams는 Web API 메서드로, 쿼리 파라미터를 ?page=1&query=a와 같은 문자열로 만들어준다. set으로 검색어를 추가하고 delete로 비운다.
usePathname으로 가져온 경로에 useRouter의 replace를 이용하여 쿼리를 추가한다.
URL로 직접 이동했을 때 쿼리와 input을 동기화하려면 defaultValue를 설정한다.

9-3. Best practice: Debouncing

검색 기능을 최적화하자.

Searching... S
Searching... St
Searching... Ste
Searching... Stev
Searching... Steve
Searching... Steven

지금은 입력할 때마다 요청을 보내 서버 부하를 유발한다. 입력 이벤트가 끝났을 때만 쿼리를 보내도록 Debounce로 이벤트를 제어한다. 여기서는 use-debounce 라이브러리를 사용한다.

// ...
import { useDebouncedCallback } from 'use-debounce';

// Inside the Search Component...
const handleSearch = useDebouncedCallback((term) => {
  console.log(`Searching... ${term}`);

  const params = new URLSearchParams(searchParams);
  if (term) {
    params.set('query', term);
  } else {
    params.delete('query');
  }
  replace(`${pathname}?${params.toString()}`);
}, 300);

300ms이내에 아무런 입력값이 없을 때 쿼리 요청을 보낸다. 띄엄띄엄 입력했을 때의 결과다.

Searching... ste
Searching... steven

9-4. Adding pagination

pagination도 비슷한 과정으로 진행한다.

'use client';

// ...
import { usePathname, useSearchParams } from 'next/navigation';

export default function Pagination({ totalPages }: { totalPages: number }) {
  const pathname = usePathname();
  const searchParams = useSearchParams();
  const currentPage = Number(searchParams.get('page')) || 1;

  const createPageURL = (pageNumber: number | string) => {
    const params = new URLSearchParams(searchParams);
    params.set('page', pageNumber.toString());
    return `${pathname}?${params.toString()}`;
  };
  // ...
}

검색했을 때는 페이지가 1이 되도록 Search를 수정한다.

export default function Search({ placeholder }: { placeholder: string }) {
  // ...
  const handleSearch = useDebouncedCallback((term) => {
    // ...
    params.set('page', '1');
    // ...
  }, 300);

10. Mutating Data

이전 장에서 CRUD 중 Read를 배웠으니 여기서는 Create, Update, Delete 기능을 추가한다.

10-1. What are Server Actions?

React Server Actions는 서버에서 실행되는 비동기 함수를 클라이언트나 서버에서 호출하여 사용하고, API 엔드포인트 없이 데이터 변경이 가능하다. Next.js가 서버 액션을 권장하는 이유는 보안 때문이다. 다양한 공격으로부터 데이터를 안전하게 보호하고 접근을 보장하는 효과적인 보안 솔루션을 제공한다고 한다. POST 요청, 암호화, 엄격한 입력 확인, 오류 메세지 해싱, 호스트 제한과 같은 기술을 통해 보안 목표를 달성하면서 앱의 안정성을 크게 향상시킨다.

JS의 내장 API인 FormData를 통해 action 속성으로 입력값을 수신할 수 있다.

// Server Component
export default function Page() {
  // Action
  async function create(formData: FormData) {
    'use server';

    // Logic to mutate data...
  }

  // Invoke the action using the "action" attribute
  return ...;
}

use server는 서버 컴포넌트를 가리키는데, 서버 컴포넌트에서 서버 액션을 호출하면 클라이언트의 JS가 비활성화되어 있더라도 양식이 작동하는 이점이 있다.

Next.js에서의 서버 액션은 Next.js Caching과 긴밀하게 통합되어 있다. 서버 액션을 통해 양식이 제출되면 해당 액션을 사용하여 데이터를 변경할 수 있을 뿐만 아니라 revalidatePath 및 revalidateTag와 같은 API를 사용하여 관련 캐시의 유효성을 다시 검사할 수도 있다.

10-2. Create a Server Action

서버 액션에서 사용하는 함수를 모아둔 파일을 만들고 최상단에 use server 지시문을 작성한다. 해당 지시문이 추가된 파일에서 내보낸 함수는 서버 함수로 표시되어 클라이언트나 서버에서 다양하게 사용할 수 있다.

// app/lib/actions.ts
'use server';

export async function createInvoice(formData: FormData) {}

생성한 서버 액션 함수를 form에 전달한다.

'use client';

import { customerField } from '@/app/lib/definitions';
import Link from 'next/link';
import {
  CheckIcon,
  ClockIcon,
  CurrencyDollarIcon,
  UserCircleIcon,
} from '@heroicons/react/24/outline';
import { Button } from '@/app/ui/button';
import { createInvoice } from '@/app/lib/actions';

export default function Form({
  customers,
}: {
  customers: customerField[];
}) {
  return (
    
      // ...
  )
}

HTML의 과 다른 점은 action에 URL이 아닌 함수가 들어갔다는 점이다. React에서는 특별한 속성으로 간주되어 액션을 호출할 수 있도록 그 위에 빌드됨을 의미한다. 서버 액션은 뒤에서 POST API 엔드포인트를 자동으로 생성한다.

10-3. Validate and Revalidate and Redirect

form을 제출하여 서버 액션이 실행되었을 때 다음과 같은 타입을 기댓값으로 원한다.

export type Invoice = {
  id: string; // Will be created on the database
  customer_id: string;
  amount: number; // Stored in cents
  status: 'pending' | 'paid';
  date: string;
};

하지만 console.log(typeof rawFormData.amount)를 해보면 number가 아닌 string으로 찍히는 것을 볼 수 있다. input type="number"를 했다손 쳐도 FomData에서는 string을 반환한다. 이러한 검증을 수동으로 할 수도 있지만, 여기서는 Zod 라이브러리를 사용하여 검증한다.

'use server';

import { z } from 'zod';

const FormSchema = z.object({
  id: z.string(),
  customerId: z.string(),
  amount: z.coerce.number(),
  status: z.enum(['pending', 'paid']),
  date: z.string(),
});

const CreateInvoice = FormSchema.omit({ id: true, date: true });

export async function createInvoice(formData: FormData) {
  const { customerId, amount, status } = CreateInvoice.parse({
    customerId: formData.get('customerId'),
    amount: formData.get('amount'),
    status: formData.get('status'),
  });
  // ...
}

데이터를 새로 생성하면 기존의 invoices 페이지가 stale한지 아닌지 검증해야 한다. 또한, 작성이 완료되었으므로 생성 페이지에서 invoices 페이지로 리다이렉트한다.

'use server';

// ...

export async function createInvoice(formData: FormData) {
  const { customerId, amount, status } = CreateInvoice.parse({
    customerId: formData.get('customerId'),
    amount: formData.get('amount'),
    status: formData.get('status'),
  });
  // ...
  revalidatePath('/dashboard/invoices');
  redirect('/dashboard/invoices');
}

10-4. Updating an invoice

invoice를 수정하기 위해서 개별 페이지를 만들어야 한다. id에 따라 보여지는 invoice 페이지가 다르므로 Dynamic Routes로 개별 페이지를 구현한다. invoices/[id]/edit/page.tsx 경로로 파일을 만든다.

만약 id가 1인 invoice를 수정한다면 경로는 dashboard/invoices/1/edit이 될 것이다.

id를 받아 업데이트하는 서버 액션을 만든다.

// ...
import { updateInvoice } from '@/app/lib/actions';

export default function EditInvoiceForm({
  invoice,
  customers,
}: {
  invoice: InvoiceForm;
  customers: CustomerField[];
}) {
  const updateInvoiceWithId = updateInvoice.bind(null, invoice.id);

  return (
    
      
    
  );
}

bind를 사용한 이유는 action에 id 인수를 담은 updateInvoice(invoice.id)를 사용할 수 없기 때문이다. 하지만 이렇게는 사용할 수 있더라. 이후 로직은 Create와 유사하다.

10-5. Deleting an invoice

Delete는 id를 받아 삭제 요청을 보내면 된다.

import { deleteInvoice } from '@/app/lib/actions';

// ...

export function DeleteInvoice({ id }: { id: string }) {
  const deleteInvoiceWithId = deleteInvoice.bind(null, id);

  return (
    
      
    
  );
}

[Next.js] 공식 문서만 보고 Next.js 익히기(3)

Sun, 03 Dec 2023 11:08:07 GMT

공식 문서 보기를 돌같이 하는 버릇을 고치자!

6. Fetching Data

Next.js는 라우트를 이용해 API 엔드포인트를 제공하여 서드 파티 프로그램이나 서버 없이도 데이터를 패칭할 수 있다. 스킵했지만, 앞선 장에서 Vercel이 제공하는 서비스를 이용해 postgres DB를 생성했는데, prisma같은 ORM을 통해 관계형 DB를 호출할 수 있다.

ORM이란? Object Relational Mapping의 약자로, 구현한 객체와 관계형 DB의 불일치를 자동으로 매핑한 SQL문을 생성해 호환가능하게 해주는 기술이다.

데이터 패치를 하기에 앞서, Next.js는 기본적으로 React Server Component를 사용하는데, 몇 가지 이점을 알려준다.

프로미스를 지원하여 useState나 useEffect, 데이터 패치 라이브러리, 추가 API 계층 없이 async/await을 사용하여 데이터를 가져올 수 있다.
서버에서 실행되기 때문에 비용이 많이드는 로직은 서버에서 실행하고, 결과만 클라이언트로 전송할 수 있다.

6-1. Fetching data for the dashboard overview page

제공해준 dashboard 페이지의 코드를 보자.

import { Card } from '@/app/ui/dashboard/cards';
import RevenueChart from '@/app/ui/dashboard/revenue-chart';
import LatestInvoices from '@/app/ui/dashboard/latest-invoices';
import { lusitana } from '@/app/ui/fonts';

export default async function Page() {
  return (
    
      
        Dashboard
      
      
        {/*  */}
        {/*  */}
        {/*  */}
        {/*  */}
      
      
        {/*  */}
        {/*  */}
      
    
  );
}

페이지 컴포넌트는 async function으로 되어 있다. 이는 await을 곧장 사용할 수 있음을 의미한다. 주석 처리된 컴포넌트들은 모두 데이터를 받는다. 데이터를 패치해 보자.

// ...
import { fetchRevenue } from '@/app/lib/data';

export default async function Page() {
  const revenue = await fetchRevenue();
  // ...
}

컴포넌트에서 await을 사용하는 게 매우 신기하다. ts 에러가 발생하지만 런타임에는 아무 지장없이 잘 실행된다.

여기서 두 가지 주의해야 할 사항이 있다고 한다.

데이터 요청이 의도치 않게 서로를 차단해 요청 폭포수를 만들고 있다.
다른 하나는 Next.js가 성능 개선을 위해 기본적으로 prerender하여 정적 렌더링을 하기 때문에 데이터 변화가 있어도 동적으로 반영되지 않는다는 점이다.

이 장에서는 1번을 살피고, 다음 장에서 2번을 살핀다.

6-2. What are request waterfalls?

waterfall은 이전 요청의 완료 여부에 따라 달라지는 일련의 네트워크 요청을 의미한다. 여기서는 앞선 데이터 패칭이 완료 되어야 다음 데이터 패칭이 이루어지는 것이다.

이전 패칭의 결과가 후행 패치에 영향을 미칠 경우에는 나쁘지 않은 패턴이다. 하지만 앞선 주의사항 대로 성능에 영향을 미칠 수 있다.

6-3. Parallel data fetching

여러 데이터 요청이 동시에 발생하는 경우 JS가 제공하는 Promise.all이나 Promise.allSettled를 사용하여 병행 처리할해 성능을 향상시킬 수 있다. 또한, 자바스크립트가 제공하는 함수를 사용하기 때문에 다른 프레임워크에서도 재사용 가능하다.

7. Static and Dynamic Rendering

이전 챕터에서 문제삼은 주의사항 2번을 해결하는 챕터이다. 정적 렌더링은 빌드나 재검증(revalidate) 중 데이터를 가져오고 렌더링하는 과정이다. 이 결과물을 CDN에 배포해 캐싱한다.

이러한 방식은 다음과 같은 이점이 있다.

더 빠른 웹사이트 : 미리 렌더링된 콘텐츠를 캐싱하여 배포하므로 전 세계 사용자가 웹사이트에 더 빠르고 안정적으로 액세스할 수 있다.
서버 부하 감소 : 콘텐츠가 캐시되므로 서버에서 각 사용자 요청에 대해 콘텐츠를 동적으로 생성할 필요가 없다.
SEO : 미리 렌더링된 콘텐츠는 페이지가 로드될 때 이미 콘텐츠를 사용할 수 있으므로 검색 엔진 크롤러가 색인을 생성하기가 더 쉽다. 이는 검색 엔진 순위 향상으로 이어질 수 있다.

따라서 정적 렌더링은 데이터 변화가 없거나 적은 블로그나 제품 페이지 등에 적합하다. 그러나 dashboard와 같이 데이터에 변화가 잦은 페이지에는 적합하지 않을 수 있다.

이와 반대되는 개념이 동적 렌더링(Dynamic Rendering)이다.

7-1. What is Dynamic Rendering?

동적 렌더링은 사용자가 페이지에 방문했을 때 렌더링하여 콘텐츠를 생성한다. 이점은 다음과 같다.

실시간 데이터 : 애플리케이션에서 실시간 또는 자주 업데이트되는 데이터를 표시할 수 있다. 데이터가 자주 변경되는 애플리케이션에 이상적이다.
사용자별 콘텐츠 : 대시보드나 사용자 프로필과 같은 개인화된 콘텐츠를 제공하고 사용자 상호 작용에 따라 데이터를 업데이트하는 것이 더 쉽다.
요청 시간 정보 : 동적 렌더링을 사용하면 쿠키나 URL 검색 매개변수와 같이 요청 시점에만 알 수 있는 정보에 액세스할 수 있다.

7-2. Using Dynamic Rendering

데이터 패치 함수 초입에 unstable_noStore를 불러와 적용한다.

// ...
import { unstable_noStore as noStore } from 'next/cache';

export async function fetchRevenue() {
  noStore();
  // ...fetch logic
}

export async function fetchLatestInvoices() {
  noStore();
  // ...fetch logic
}

export async function fetchCardData() {
  noStore();
  // ...fetch logic
}

export async function fetchFilteredInvoices(
  query: string,
  currentPage: number,
) {
  noStore();
  // ...fetch logic
}

export async function fetchInvoicesPages(query: string) {
  noStore();
  // ...fetch logic
}

export async function fetchFilteredCustomers(query: string) {
  noStore();
  // ...fetch logic
}

export async function fetchInvoiceById(query: string) {
  noStore();
  // ...fetch logic
}

unstable_noStore는 실험적인 API이므로 추후 변경될 수도 있다고 한다. 안정적인 API는 Route Segment Config의 export const dynamic = "force-dynamic"를 사용한다.

export const dynamic = 'force-dynamic';

export default function MyComponent() {}

동적 렌더링이 가져오는 문제는 느리게 도착하는 데이터에 의해 앱의 성능이 결정된다는 점이다. 이를 해결하는 과정을 다음 챕터에서 안내한다.

8. Streaming

느린 데이터 가져오기 환경을 개선하는 방법을 알려주는 장이다.

8-1. What is streaming?

스트리밍(streaming)은 데이터를 '작은 조각(chunk)'로 분할하여 서버에서 준비되는 대로 클라이언트 측에 보내는 전송 방식을 말한다. 느린 데이터 요청으로 인한 앱 전체가 차단되는 것을 방지하고, 전체 데이터 패칭이 완료되지 않아도 일부 페이지를 조작할 수 있도록 한다.

리액트 컴포넌트는 하나의 청크로 간주될 수 있기 때문에 스트리밍을 적용하기에 좋다. 페이지에서는 loading.tsx을, 컴포넌트에서는 를 사용하여 스트리밍을 적용할 수 있다.

8-2. Using loading.tsx

페이지 전체 로딩을 적용하는 방법은 매우 간단하다. 라우트 경로에 loading.tsx를 추가한다.

// app/dashboard/loading.tsx
export default function Loading() {
  return Loading...;
}

의도적으로 데이터 패치 중 하나를 느리게 만들면 로딩 화면이 보인다.

제공한 스켈레톤으로 로딩을 교체했는데, 작은 버그가 하나 있다. dashboard 바로 아래에 loading을 생성한 탓에 하위 라우트인 dashboard/invoices와 dashboard/customers에서도 로딩이 적용된다. dashboard에만 적용하려면 하위에 (overview) 폴더를 추가하고, page.tsx와 loading.tsx를 옮긴다.

🗂app/
  └─🗂dashboard/
    ├─layout.tsx
    ├─🗂(overview)
    │ ├─loading.tsx
    │ └─page.tsx
    ├─🗂invoices/
    └─🗂customers/

이렇게 경로 나누는 방식이 Route Groups이며, 괄호로 작성한 폴더를 경로에 포함시키지 않으면서 나눌 수 있다. 예를 들어, 여기서 사용한 loading.tsx는 (overview) 하위에 있는 page.tsx에만 적용된다.

8-3. Streaming a component

위의 방식이 전체 페이지 스트리밍에 해당한다면, 는 데이터가 필요한 특정 컴포넌트만 지연 로딩하는 방식이다. 지연 로딩할 부분을 로 감싸고 지연되는 동안 보여줄 fallback을 추가한다.

dashboard에서 하나의 요청을 의도적으로 지연시켜 전체 페이지에 로딩이 발생했다. 해당 요청을 제거하고, 해당 컴포넌트를 로 감싼다.

import RevenueChart from '@/app/ui/dashboard/revenue-chart';
+ import { fetchLatestInvoices, fetchCardData } from '@/app/lib/data';  // remove fetchRevenue
import { Suspense } from 'react';
import { RevenueChartSkeleton } from '@/app/ui/skeletons';

export default async function Page() {
-  const revenue = await fetchRevenue // delete this line
  // ...

  return (
    
      
        Dashboard
      
      
        {/* ...Cards */}
      
      
+        }>
+          
+        
        {/* ...*/}
      
    
  );
}

특정 컴포넌트의 요청이 끝날 때까지 전체 로딩하던 화면에서 특정 컴포넌트만 지연 로딩되는 화면으로 바뀌었다.

8-3. Deciding where to place your Suspense boundaries

Suspense의 경계는 원하는 사용자 경험, 콘텐츠 우선순위, 컴포넌트가 의존하는 데이터 패칭에 따라 달라진다. 정답은 없지만 일반적으로 데이터가 필요한 컴포넌트를 Suspense로 감싸는 게 낫고, 필요한 경우 전체 페이지를 스트리밍한다.

[Next.js] 공식 문서만 보고 Next.js 익히기(2)

Thu, 30 Nov 2023 01:12:52 GMT

공식 문서 보기를 돌같이 하는 버릇을 고치자!

3. Optimizing Fonts and Images

이 장에서는 next/font와 next/image 적용과 최적화 방법을 배운다.

3-1. Why optimize fonts?

기본 폰트가 아닌 사용자 정의 폰트는 외부에서 로드하는 시간이 필요하다. 그 과정에서 Cumulative Layout Shift(CLS) 점수를 높여 나쁜 사용자 경험을 제공할 수도 있다.

Cumulative Layout Shift란, 구글에서 레이아웃 변경을 측정하는 지표이다. 요소의 이동이나 변경이 많을수록 높은 점수가 측정된다.

Next에서는 next/font를 이용해 빌드 시점에 폰트를 다운로드하여 자동 최적화한다.

3-2. Adding a primary font

next/font/google에서 Inter 폰트를 가져온다.

// app/ui/fonts.ts
import { Inter } from 'next/font/google';

export const inter = Inter({ subsets: ['latin'] });

폰트를 layout의 body에 추가하여 기본 폰트로 설정한다.

import { inter } from '@/app/ui/fonts';

export default function RootLayout({
  children,
}: {
  children: React.ReactNode;
}) {
  return (
    
      {children}
    
  );
}

antialiased는 Tailwind 코드로, 폰트를 부드럽게 처리하는 클래스이다. 멋지라고 넣었다고 한다.

3-3. Why optimize images?

이미지 파일을 수동으로 지정할 경우 다양한 부분을 고려하기 어려워 진다.

다양한 화면 크기에서 이미지가 반응하는지 확인해야 한다.
다양한 디바이스에 맞는 이미지 크기를 지정해야 한다.
이미지 로드 시 레이아웃 이동을 방지해야 한다.
사용자 뷰포트 외부에 있는 이미지를 지연 로드해야 한다.

이런 포인트를 next/image 모듈의 컴포넌트를 이용해 자동으로 최적화한다.

이미지가 로드될 때 레이아웃이 자동으로 바뀌는 것을 방지
뷰포트가 작은 기기에 큰 이미지가 전송되지 않도록 이미지 크기 조정
기본적으로 이미지 지연 로딩(이미지가 뷰포트에 들어올 때 로드됨)
브라우저에서 지원하는 경우 WebP 및 AVIF와 같은 최신 형식의 이미지 제공

import Image from 'next/image';

export default function Page() {
  return (
    // ...
    
      
    
    //...
  );
}

이미지가 로드되는 동안 레이아웃이 변경되지 않도록 width와 height를 지정하고, 원본과 같은 비율로 설정하는 것이 좋다.

width와 height를 비율에 맞춰 자동으로 설정하려면 이미지를 import해 이미지 컴포넌트에 제공한다.

import Image from 'next/image';
import heroMobile from '../public/hero-mobile.png';

export default function Page() {
  return (
    // ...
    
      
    
    //...
  );
}

이미지나 폰트 최적화에 관한 자세한 정보는 Image Optimization과 Font Optimization를 참고한다.

4. Creating Layouts and Pages

새로운 페이지를 만드는 장이다. 파일 시스템 라우트를 사용하여 파일과 폴더의 역할과 layout을 이해하는 것이 주 목표이다.

4-1. Nested routing

파일 시스템 라우팅에서 폴더는 URL의 path에 따라 구분하는 역할을 한다. 최상위인 app은 root(/)를 의미하고, 하위 폴더들은 pathname을 의미한다. 즉, /로 구분되는 영역이다. 예를 들어, localhost / dashboard / invoices 경로라면, 🗂app/🗂dashboard/🗂invoices이다.

각각의 폴더는 layout.tsx과 page.tsx 파일을 갖는다. page.tsx는 라우트에 해당하는 view 컴포넌트를 내보내는 역할을 한다. 🗂app/🗂dashboard/page.tsx를 만들고 localhost:3000/dashboard에 접근하면 해당 컴포넌트가 렌더링된 화면을 볼 수 있다.

🗂app/🗂dashboard/sidebar.tsx라는 파일을 만들었을 때, /dashboard/sidebar로 접근할 수 있는 게 아닌가 하는 의문이 들었다. 하지만 Next.js에서는 page와 ui 컴포넌트, 테스트 파일 등이 공존 가능한 colocation을 허용한다. 오직 page.tsx 파일이 있어야 라우트로 접근할 수 있다.

4-2. layout

layout.tsx 파일은 여러 페이지에서 같은 레이아웃을 공유하는 역할이다. layout의 이점 중 하나는 다른 페이지 컴포넌트를 업데이트할 때 layout은 리렌더링을 하지 않는다는 것이다. partial rendering이라고 부른다고 한다.

나의 실행 환경에서는 페이지 이동마다 layout도 리렌더링되던데...게다가 SPA가 아닌 MPA처럼 동작한다. 뭔가 조치가 더 필요한 건가? 약간의 의문 추가.

🗂app/layout.tsx는 Root layout으로, 모든 페이지가 공유하는 필수 레이아웃이다. 여기에서 과 태그를 수정하거나 metadata를 추가할 수도 있다.

5. Navigating Between Pages

페이지 간의 이동을 다루는 장이다. 위에서 품었던 의문이 곧바로 해결되었다.

5.1 Link Component

dashboard의 하위 페이지 간 이동은 태그를 이용하고 있었다. 이동마다 전체 페이지가 새로고침되는 원인이었다. next/link의 컴포넌트로 대체하면 새로고침 없이 이동한다.

import Link from 'next/link';

export default function NavLinks() {
  return (
    <>
      {/* ... */}
      
        
        {link.name}
      
      {/* ... */}
    
  );
}

5.2 Automatic code-splitting and prefetching

Next.js는 자동으로 코드를 분할한다. 분할된 코드는 고립되었다는 의미이며, 이 페이지에서 에러가 발생해도 다른 페이지는 정상 동작한다. 또한, 컴포넌트가 동작할 때마다 백그라운드에서 라우트의 코드를 prefetch한다. 백그라운드에서 미리 로드된 목적지 페이지는 사용자가 클릭했을 때 거의 즉시 전환된다.

5.3 Pattern: Showing active links

일반적인 UI는 현재 페이지와 같은 링크를 활성화 상태로 보여준다. 그러기 위해서 현재 pathname을 알아야 한다. next/navigation의 usePathname을 사용해 pathname에 접근한다.

'use client';

import { usePathname } from 'next/navigation';

훅은 Client Component에서 사용하므로 최상단에 use client를 명시해야 한다.

[Next.js] 공식 문서만 보고 Next.js 익히기(1)

Sun, 26 Nov 2023 16:43:15 GMT

공식 문서 보기를 돌같이 하는 버릇을 고치자!

13버전을 익히기도 전에 14버전이 출시된 Next.js... 마지막으로 공부했던 버전이 12였기에 새로 공부해야 함을 느꼈다. 다행히 공식 문서가 매우매우 잘 되어 있었다. Learn Next 페이지를 이용하여 14버전을 익혀보려고 한다.

0. Introduction

대시보드 앱을 만드는 과정으로, 16장으로 이루어졌다. 모두 익히면 Next.js의 필수 기술을 갖추게 된다고 한다. 다음은 배울 내용이다.

Styling: Next.js에서 애플리케이션의 스타일을 지정하는 다양한 방법.
Optimizations: 이미지, 링크 및 글꼴을 최적화하는 방법.
Routing: 파일 시스템 라우팅을 사용하여 중첩 레이아웃과 페이지를 만드는 방법.
Data Fetching: Vercel에서 데이터베이스를 설정하는 방법과 가져오기 및 스트리밍에 대한 모범 사례.
Search and Pagination: URL 검색 매개변수를 사용하여 검색 및 페이지 매김을 구현하는 방법.
Mutating Data: React 서버 액션을 사용하여 데이터를 변경하고 Next.js 캐시를 재검증하는 방법.
Error Handling: 일반 오류와 404 찾을 수 없음 오류를 처리하는 방법.
Form Validation and Accessibility: 서버 측 양식 유효성 검사를 수행하는 방법과 접근성을 개선하기 위한 팁.
Authentication: NextAuth.js 및 미들웨어를 사용하여 애플리케이션에 인증을 추가하는 방법.
Metadata: 메타데이터를 추가하고 소셜 공유를 위해 애플리케이션을 준비하는 방법.

React와 자바스크립트에 대한 기본적인 이해가 있다고 가정하며 Node는 18.17.0 이상을 기준으로 한다.

1. Getting Started

Next의 설치는 npx create-next-app@latest로 하는데, 여기서는 제공하는 예제를 포함하여 설치한다.

npx create-next-app@latest nextjs-dashboard --use-npm --example "https://github.com/vercel/next-learn/tree/main/dashboard/starter-example"

예제의 app 디렉토리의 구성은 다음과 같다.

├─public
│
├─app
│   │  layout.tsx # 전체 레이아웃 (필수)
│   │  page.tsx # index 페이지 (필수)
│   │
│   ├─lib
│   │   data.ts # 데이터 패치
│   │   definitions.ts # 타입 정의
│   │   placeholder-data.js # 미리 생성한 mockup 데이터
│   │   utils.ts # 화폐 단위, 날짜 형식, 컬럼 설정, 페지네이션 생성 등
│   │
│   └─ui # UI를 구성하는 컴포넌트
│       │  acme-logo.tsx
│       │  button.tsx
│       │  global.css
│       │  login-form.tsx
│       │  search.tsx
│       │  skeletons.tsx
│       │
│       ├─customers
│       │      table.tsx
│       │
│       ├─dashboard
│       │      cards.tsx
│       │      latest-invoices.tsx
│       │      nav-links.tsx
│       │      revenue-chart.tsx
│       │      sidenav.tsx
│       │
│       └─invoices
│             breadcrumbs.tsx
│             buttons.tsx
│             create-form.tsx
│             edit-form.tsx
│             pagination.tsx
│             status.tsx
│             table.tsx
└─scripts
      seed.js # 데이터베이스를 채울 시딩

컴포넌트 이름과 내부의 이름이 깔끔해서 어렵게 고민할 필요가 없었다. 이게 네이밍 센스란 건가? 벌써 하나 배웠다.

npm run dev로 실행한 첫 화면이다.

2. CSS Styling

2장에서는 아무것도 꾸며지지 않은 홈페이지를 어떻게 스타일링하는가를 알려준다.

2-1. Global Styling

앱 전체에 공용으로 적용하는 스타일은 최상위 루트에서 호출하여 사용한다. Next에서는 app 디렉토리의 바로 아래에 있는 layout.tsx이 Root Layout이다.

RootLayout에서 global.css를 호출한다.

// layout.tsx
+ import '@/app/ui/global.css';

export default function RootLayout({
  children,
}: {
  children: React.ReactNode;
}) {
  return (
    
      {children}
    
  );
}

Next는 Tailwind CSS를 지원하기 때문에 global.css에는 Tailwind CSS의 기본 지시문을 포함하고 있다.

/* global.css*/
@tailwind base;
@tailwind components;
@tailwind utilities;

global.css를 적용한 화면은 처음과 달리 보기 편안하다.

2-2. Tailwind CSS

앞서 언급한 Tailwind CSS는 className으로 빠르고 쉽게 스타일을 적용하는 CSS Framework이다. Next에서 기본적으로 지원하며, create-next-app으로 세팅 시 사용 여부를 묻는다. yes를 선택하면 필요한 자원을 알아서 설치해준다.


  Log in

위 이미지에서 보이는 Log in 버튼의 코드이다. 개인적으로 제일 선호하는 스타일링 시스템이기도 하다. config 파일에서 커스텀 클래스를 만들 수도 있고, 수치가 적용되는 클래스명에 직접 설정할 수도 있다.

// tailwind.config.js

import type { Config } from 'tailwindcss';

const config: Config = {
  theme: {
    extend: {
      // custom color를 세팅한다
      colors: {
        blue: {
          400: '#2589FE',
          500: '#0070F3',
          600: '#2F6FEB',
        },
      },
    },
  },
};
export default config;

// temp.jsx
패딩 수치 직접 설정

2-3. CSS Modules

CSS Modules는 CSS의 범위를 컴포넌트 범위로 축소해 더 쉽게 스타일을 관리하고 충돌을 방지하는 이점을 제공한다. *.module.css로 생성한 후 import styles from "./temp.module.css"로 호출했다. className={styles.wrapper}으로 적용했다.

import styles from './temp.module.css';

function Temp() {
  return (
    
      Hello CSS Modules!
    
  );
}

선호하는 방식은 아니다. CSS 작성도 귀찮고, 파일도 늘어나고, 보기도 불편하기 때문이다. 아직 스타일 변화가 잦아 유지보수가 빡세게 필요한 무언가를 만들어 본 경험이 없어서 그럴 수도. 아무튼 지금은 패스.

2-4. clsx

clsx는 조건부로 클래스명을 입력할 때 사용할 수 있는 라이브러리이다.

import clsx from 'clsx';

export default function InvoiceStatus({ status }: { status: string }) {
  return (
    
    // ...
)}

value가 truthy일 경우 key로 받은 클래스명을 적용한다.

2-5. Other styling solutions

이 외에 CSS-in-JS 방식의 styled-components, styled-jsx, emotion 등이나 SASS가 있다.

[JS] JavaScript는 이상하다

Wed, 22 Nov 2023 18:13:10 GMT

JS는 자유도(?)가 워낙 높아 이상하다는 것을 알고 있었지만, 막상 JS is Weird를 풀어 보니 절반도 못 맞췄다. 그 충격을 정리한다.

스포일러 주의

문제와 답을 함께 적을 예정이라 스포일러가 될 수 있다. 스크롤을 내리기 전에 풀어보는 편이 좋다.

1. true + false (O)

answer : 1

다행히 처음 문제는 쉬웠다. true는 1로, false는 0으로 치환된다. 그러므로 답은 1이다.

2. [ , , , ].length (O)

answer : 3

배열의 콤마(,)는 빈 요소를 구분한다. 눈으로 보기에는 4칸이지만 길이가 3인 이유는 마지막 콤마가 후행 쉼표(Trailing commas)이기 때문이다. 새 요소나 매개변수, 속성 등을 추가하기 쉽도록 고안된 JS 고유 문법이라고 한다.

이걸 가지고 연산하는 사람은 없겠지만, 연산하는 순간 이상해진다.

[ , , , ] + [ , , ] // ",,,"
([,,,] + [,,,]).length // 4
[,,,,].length // 4

배열과 배열을 더하면 배열 요소와 콤마가 합쳐진 문자열이 되는데, 후행 쉼표는 생략된다. 음, 보기 싫은 광경이다.

3. [1, 2, 3] + [4, 5, 6] (O)

answer : "1,2,34,5,6"

위에서 설명한 바와 같다. 3과 4이 합쳐지는 게 보기 불편하다면 다음과 같은 방법이 있다고 알려준다.

[1, 2, 3] + [, 4, 5, 6];
[1, 2, 3, ""] + [4, 5, 6];

가장 좋은 방법은 + 연산자를 사용하지 않고 배열을 합치는 것이라고. (진짜 배열을 더하는 사람이 있긴 할까? 의아, 궁금)

[...[1, 2, 3], ...[4, 5, 6]];

4. 0.2 + 0.1 === 0.3 (O)

answer : false

워낙 유명한 문제라 맞췄다. JS의 부동소수점과 관련 있는데 stackoverflow에 자세한 답변이 있다.

5. 10,2 (X)

answer : 2

이 글을 쓰게 된 계기인데, ,가 어떻게 연산자인 거냐고! Comma operator라니... 정말 충격과 공포 그 자체였다. 이제라도 알아서 다행이다.

6. !!"" (O)

answer : false

빈 문자열은 falsy이고, boolean을 역전시키는 Logical NOT을 사용하면 true가 된다. 한 번 더 NOT을 하면 다시 역전되어 false가 된다.

7. +!![] (O)

answer : 1

빈 배열은 놀랍게도 truthy이다. 따라서 !!의 값은 true이고, +하면 숫자가 되므로 1이 나온다.

8. parseInt(0.0000005)

answer : 5

어, 음... 정수로 만들어주는 함수 아니었나? 설명을 보면 소수점 아래 7번째부터 달라지는 듯하다. String(0.0000005) 의 값은 5e-7인데, parseInt는 e-7을 스킵한다. Solving a Mystery Behavior of parseInt() in JavaScript

세상에 마상에...

9. true == "true" (X)

answer : false

1 == "1"은 true라며? 그래서 틀렸다. 1, "1", true는 number로 변환되지만, "true"는 NaN이 되기 때문이다. 1 == NaN은 false다.

10. 010 - 03 (X)

answer : 5

0은 자동 생략되어서 10 - 3인줄 알았는데 아니었다. 무려 010은 8진수였다! 앞에 0이 붙고 뒤가 7이하의 수라면 JS은 8진수로 세팅한다. 8이상은 10진수로. 이게 똑똑한 건지, 멍청한 건지 모르겠다. 으아아아아ㅏㅏㅏㅏㅏㅏㅏㅏㅏㅏ

11. "" - - "" (X)

answer : 0

이게 왜 연산이 되는 건데?! "" - - ""를 보기 쉽게 표현하면 다음과 같다.

+"" - -"";
+0 - -0;

근데 이건 에러다.

--""; // -> SyntaxError

12. null + 0 (X)

answer : 0

null의 타입이 object여서 NaN이 나올 줄 알았다. 지금 보니 + 연산을 숫자와 할 때는 number로 치환이 가능하냐에 따라 달라지는 듯하다, 라고 하기엔 "" + 1은 "1"인데. true = 1, false = 0, null = 0이라고 외우자.

13. 0/0 (X)

answer : NaN

하도 이상하게 당해서 이것도 이상하게 나오겠지 싶어 Infinity를 선택했지만 아니었다. 정신 나갈 것 같다. ㅋㅋㅋㅋㅋ

14. 1/0 > 10 ** 1000 (X)

answer : false

10 ** 1000은 유한한 정수여서 Infinity가 더 크다고 생각했다. 하지만 10의 1000승은 마찬가지로 Infinity였다.

15. true++ (X)

answer : SyntaxError

이것까지 증가되지는 않았다. 그래도 양심은 있네.

16. "" - 1 (X)

answer : -1

"" + 1"은 문자열이면서 - 연산자는 숫자다.

17. (null - 0) + "0" (X)

answer : "00"

NaN일 줄 알았는데, (null -0)은 0이고 문자열과 더해 "00"이 되었다. 이제 좀 보인다.

18. true + ("true" - 0) (O)

answer : NaN

("true" - 0)이 NaN이어서 정답을 맞췄다.

19. !5 + !5 (O)

answer : 0

false + false라고 생각하면 되니까 답은 0. 만약 !0 + !0이었다면 답은 2다.

20. [] + [] (O)

answer : ""

제일 앞에서 했던 것의 반복이었다.

21. 1 + 2 + "3" (O)

answer : "33"

number + string or string + number는 string을 반환한다. 앞의 숫자 연산 후 문자열을 더해 "33"이 되었다.

22. typeof NaN (O)

answer : number

처음 JS를 배울 때 stirng, object 혹은 NaN이라는 타입이라고 생각했지만, 이것은 숫자가 아님을 나타내는 number 타입(Not a Number)이었다. '잉?'했던 느낌을 잊을 수가 없다.

23. undefined + false (O)

answer : NaN

undefined는 undefined 타입이다. 연산이 안 되므로 NaN이 나온다.

24. "" && -0 (X)

answer : ""

빈 문자열은 falsy니까 false 아닌가? 네, 아닙니다. Logical AND 연산자는 if문이 아닌 경우 반환값이 Boolean이 아니다. 첫 번째 표현식이 true이면 두 번째 표현식을 반환하고, 아니라면 첫 번째 표현식을 반환한다.

React에서 0 && 로 조건부 렌더링했을 때 0이 나오는 경우가 이것 때문인가 보다. 0이 falsy이므로 첫 번재 표현식이 반환되는 것.

25. +!!NaN * "" - - [,] (Give up)

answer : 0

정신 나가서 포기했다. 지금 보니 0인 게 보인다. +!!NaN은 0이다. "" - - [,]는 "" - - ""이고, 이건 위에서 0임을 알았다. 그러므로 0 * 0 = 0이 된다.

결론

정신이 한 번 나갔지만, 정리하면서 정신줄 붙잡고 '나는 이런 코드 생각도 말아야지'라는 다짐을 하게 되었다. 호기심 해결되는 문제도 있어 도움이 되었다. JS는 많이 이상한 언어지만, 내가 배우고 사용하는 만큼 더 열심히 공부해야겠다. 언젠가 개발자가 되는 그날을 위하여!

[React, Vite] 공식 문서만 보고 Vite-React SSR 예제 살펴보기

Wed, 15 Nov 2023 12:57:49 GMT

공식 문서를 돌같이 보는 버릇을 고치자!

CRA나 Vite로 생성한 프로젝트는 CSR(Client Side Rendering)로 실행된다. CSR은 웹을 구성하는 모든 자원을 브라우저에서 다운로드해 실행하기 때문에 서버 부하를 최소화하고, 페이지 전환이나 웹 내의 상호작용이 빠르다는 장점이 있다. 또한, 템플릿이 제공되기 때문에 상대적으로 개발 효율성도 높은 편이다.

하지만 모든 자원을 한 번에 받는 만큼 초기 로딩 속도가 느릴 수밖에 없다. JS가 다운로드되어 실행되기 전까지 사용자는 빈 페이지를 봐야 한다. 여기서 SEO 문제가 유발된다. 렌더링되기 전까지 html은

단 하나만 가지고 있다. 때문에 검색 엔진 크롤러는 페이지에 대한 아무런 정보도 가지고 가지 못한다. (요즘 구글 크롤러는 JS까지 실행해서 긁어간다는데, 일반적인 내용은 아닌 듯하니 넘어가자.)

preview도 비었고, response의 div도 비었다.

검색 엔진에 노출되어 유입을 유도하는 입장에서 SEO는 중요한 문제이다. 검색 엔진 크롤러가 페이지의 정보를 잘 긁어가게 하기 위해서는 사이트에 방문했을 때 내용이 담긴 html을 보여줘야 한다. JS가 실행되기 전에 페이지 내용을 담은 자원을 호출하는 방식이 SSR(Server Side Rendering)이다. 서버에서 페이지의 골조를 만들어 보내주기 때문에 초기 로딩 속도가 빠르고 SEO 대응도 원활하다. 대신 CSR과 반대로 서버가 할 일이 많아 부하가 늘어나고, 페이지 전환 시 새로운 html을 생성하므로 전환 속도가 느릴 수 있다.

preview도, reponse의 div로 뭔가 들어있다.

어쨌든 SSR은 중요하기 때문에 내가 애용하는 Vite에서도 SSR을 지원한다. 스스로 구현하기에는 아직 잘 모르겠으니 Vite에서 제공하는 예제 코드를 살펴보자. React를 기준이다.

예제 코드는 다음 명령어로 설치할 수 있다. npm create vite-extra@latest 한국어 공식 문서 예제 코드 깃허브 : https://github.com/bluwy/create-vite-extra 영어 공식 문서 React 예제 코드 : https://github.com/vitejs/vite-plugin-react/tree/main/playground/ssr-react

Package.json

{
  "dependencies": {
    "compression": "^1.7.4",
    "express": "^4.18.2",
    "react": "^18.2.0",
    "react-dom": "^18.2.0",
    "sirv": "^2.0.3"
  },
  "devDependencies": {
    "@types/react": "^18.2.28",
    "@types/react-dom": "^18.2.13",
    "@vitejs/plugin-react": "^4.1.0",
    "cross-env": "^7.0.3",
    "vite": "^4.4.11"
  }
}

서버에서 렌더링을 해야 하기 때문에 서버 구성 패키지가 눈에 띈다. express는 노드 서버 생성을 위해서, compression은 production 단계에서 리소스를 압축하기 위해서, sirv는 정적 파일을 효율적으로 전달하기 위해 사용한다. cross-env는 실행 환경에 따라 동적으로 env를 변경하기 위해 사용한다.

스크립트도 신기했다.

{
  "scripts": {
    "dev": "node server",
    "build": "npm run build:client && npm run build:server",
    "build:client": "vite build --ssrManifest --outDir dist/client",
    "build:server": "vite build --ssr src/entry-server.jsx --outDir dist/server",
    "preview": "cross-env NODE_ENV=production node server"
  }
}

express를 실행해야 하므로 기존의 CSR 명령어와 다르게 vite가 아닌 node server로 대체되었다. build 역시 서버와 클라이언트로 나뉘었다.

build:client의 --ssrManifest는 모듈 ID와 관련된 청크 파일이나 에셋 파일에 대한 매핑이 포함된 파일이다. --outDir은 빌드 결과물이 생성될 디렉토리이다.

build:server는 --ssr을 붙여 SSR 빌드임을 명시하고 진입점을 지정한다. 마찬가지로 결과물은 --outDir로 지정한 디렉토리에 생성된다.

index.html





  
  
  
  Vite + React

일반 템플릿의 html과 별다를 바 없지만, 주석이 의아했다. 저건 왜 붙어 있는 거지? 의문점은 server.js를 보고 풀렸다. 하지만 맛있는 건 나중에 먹기로 하고, 진입점 파일부터 보도록 하자.

entry-client.jsx

import "./index.css";
import React from "react";
import ReactDOM from "react-dom/client";
import App from "./App";

ReactDOM.hydrateRoot(
  document.getElementById("root"),
  
    
  
);

React에서는 서버에서 사전에 만들어진 html 내부에 ReactDom을 그리기 위한 hydrateRoot 함수가 있다. React - hydrateRoot

서버에서 html을 만들어 보내면 React는 그 문서 위에 ReactDom을 붙여 정적인 파일을 축축(hydrate)하게 만든다. 아무런 이벤트가 없는 문서에 상호작용 가능한 이벤트를 달아주는 것이다.

entry-server.jsx

import React from "react";
import ReactDOMServer from "react-dom/server";
import App from "./App";

export function render() {
  const html = ReactDOMServer.renderToString(
    
      
    
  );
  return { html };
}

함수 명에서 알 수 있듯이, renderToString은 React 컴포넌트를 문자열로 변환한다. React - renderToString

hydrateRoot를 호출하면 서버에서 생성된 HTML을 상호작용하게 만든다.

server.js

가장 중요하게 보이는 server.js를 살펴보자. 여기서 조건부로 개발 환경과 프로덕션 환경을 나누어 서버를 실행한다.

Constants & Assets

import fs from "node:fs/promises";

// Constants
const isProduction = process.env.NODE_ENV === "production";
const port = process.env.PORT || 5173;
const base = process.env.BASE || "/";

// Cached production assets
const templateHtml = isProduction
  ? await fs.readFile("./dist/client/index.html", "utf-8")
  : "";
const ssrManifest = isProduction
  ? await fs.readFile("./dist/client/ssr-manifest.json", "utf-8")
  : undefined;

문자열 그대로다. 프로덕션인지 아닌지에 따라 개발 환경과 프로덕션 환경을 구분한다. 프로덕션일 때는 서버 요청마다 html과 ssrManifest를 읽지 않도록 fs 모듈을 이용해 미리 읽어온다. async 없이 사용되는 await은 Top-level Await이라는 새로 추가된 문법이다. TC39 - Top-level Await

Server

import express from "express";

// Create http server
const app = express();

// Add Vite or respective production middlewares
let vite;
if (!isProduction) {
  const { createServer } = await import("vite");
  vite = await createServer({
    server: { middlewareMode: true },
    appType: "custom",
    base,
  });
  app.use(vite.middlewares);
} else {
  const compression = (await import("compression")).default;
  const sirv = (await import("sirv")).default;
  app.use(compression());
  app.use(base, sirv("./dist/client", { extensions: [] }));
}

express로 서버를 생성한다. vite의 역할이 달라졌다. 여기에서 vite는 미들웨어 역할을 하며 프로덕션과 개발 환경을 분리하여 사용한다. appType을 'custom'으로 적는 이유는 vite 자체의 html 제공 로직을 비활성화하기 위함이다. Vite - 서버 측 렌더링:개발 서버 구성하기

프로덕션 환경에서는 동적으로 compression과 sirv를 호출해 미들웨어를 등록한다.

Serve HTML

// Serve HTML
app.use("*", async (req, res) => {
  try {
    const url = req.originalUrl.replace(base, "");

    let template;
    let render;
    if (!isProduction) {
      // Always read fresh template in development
      template = await fs.readFile("./index.html", "utf-8");
      template = await vite.transformIndexHtml(url, template);
      render = (await vite.ssrLoadModule("/src/entry-server.jsx")).render;
    } else {
      template = templateHtml;
      render = (await import("./dist/server/entry-server.js")).render;
    }

    const rendered = await render(url, ssrManifest);

    const html = template
      .replace(``, rendered.head ?? "")
      .replace(``, rendered.html ?? "");

    res.status(200).set({ "Content-Type": "text/html" }).end(html);
  } catch (e) {
    vite?.ssrFixStacktrace(e);
    console.log(e.stack);
    res.status(500).end(e.stack);
  }
});

조금씩 구분해서 보도록 하자.

const url = req.originalUrl.replace(base, "");

공식 문서에서는 req.originalUrl만 썼는데, 템플릿에서는 왜 replace를 했는지 모르겠다. 일종의 안전장치인가? 뭔가 base를 지워야 하는 상황이 있기 때문에 replace를 했을 것이다. 근데 지금은 모르겠다.

let template;
let render;
if (!isProduction) {
  // Always read fresh template in development
  template = await fs.readFile("./index.html", "utf-8");
  template = await vite.transformIndexHtml(url, template);
  render = (await vite.ssrLoadModule("/src/entry-server.jsx")).render;
}

fs.readFile로 index.html을 가져온다. vite.transformIndexHtml에서는 HMR(Hot Module Replacement)이 가능하도록 hook을 붙인다. vite.ssrLoadModule는 SSR 진입점을 서버에 알려주고, entry-server.jsx에서 export한 render 함수를 가져온다.

else {
  template = templateHtml;
  render = (await import("./dist/server/entry-server.js")).render;
}

프로덕션에서는 사전에 로드한 templateHtml을 그대로 사용하고, 빌드된 서버 측 render를 가져온다.

const rendered = await render(url, ssrManifest);

render에 url과 ssrManifest가 왜 들어가는지도 모르겠다. 내부에서 뭔가 처리를 하는 건가? React 공식 문서의 renderToString에도 별다른 설명이 없는 걸 보니 모종의 이유가 있는 듯한데 그걸 모르겠다. 으으, 답답. 일단 여기도 패스.

const html = template
                .replace(``, rendered.head ?? "")
                .replace(``, rendered.html ?? "");

개인적으로 여기가 가장 중요해 보였다. index.html에서 보았던 주석은 이곳에서 사용하기 위함이었다. 공식 문서 설명을 보면 주석은 React 코드가 주입될 placeholder였다! 예전에 원티드 프리온보딩 7월 강의에서 비슷한 무언가를 본 기억이 났다. Next.js의 SSR에서 B:0, S:0 등의 표시로 주입될 자리를 명시하고 요소를 갈아 끼운다는 점 말이다.

이렇게 자리를 정하고 갈아끼우기 때문에 서버와 클라이언트 간의 DOM 위치를 정확하게 맞춘다.

res.status(200).set({ "Content-Type": "text/html" }).end(html);

완성된 문서의 타입을 지정하고 보내면 SSR 작업이 완료된다.

결과

빌드 후 결과물 폴더 구조는 다음과 같다.

"preview": "cross-env NODE_ENV=production node server" 스크립트를 이용해 실행해 보면 CSR과 달리 문서가 채워진 채로 온다.

이렇게만 보면 그다지 어려워 보이지는 않는다. 하지만 응용해서 무언가를 만들면 미지의 에러에 빠지겠지? 새삼 SSR을 편하게 생성하도록 프레임워크를 내주신 여타 분들에게 감사를 전하고 싶어진다.

참고 Vite - 서버 측 렌더링(SSR) ECMAScript proposal: Top-level await create-vite-extra React - hydrateRoot React - renderToString

[JS] Currying과 Composition

Sun, 12 Nov 2023 14:21:31 GMT

함수형 프로그래밍은 함수를 1급 객체로 취급한다.

1급 객체는 표현식에 할당할 수 있다.

JS는 함수를 1급 객체로 취급하고, 변수에 할당하여 평가할 수 있다.

그러므로 JS는 함수형 프로그래밍과 잘 어울린다.

커링(Currying)과 컴포지션(Composition)은 함수형 프로그래밍의 핵심 개념에 속한다. 이 둘을 잘 활용하면 가독성과 재사용성이 높은 코드를 작성할 수 있다고 한다.

커링(Currying)

커링은 Haskell Curry에서 유래된 함수 개념으로, 여러 인자를 받는 함수를 단일 인자 함수로 변경하는 방식을 말한다. 커링 - 위키백과

세 개의 number를 받아 곱한 결과를 반환하는 함수를 예시로 들어 보자.

function multiple(a, b, c) {
  return a * b * c;
}

여기서 인자는 서로에게 영향을 끼친다. 만약 특정 상황에서 a는 2로 고정하고 b와 c만 바꾼다고할 때 코드 작성은 귀찮아질 것이다.

const multiA = multiple(2, 2, 2);
const multiB = multiple(2, 3, 3);
const multiC = multiple(2, 3, 4);

multiple을 커링으로 작성하면 코드가 심플해진다.

function multiple(a) {
  return function (b) {
    return function (c) {
      return a * b * c;
    }
  }
}

const fixTwo = multiple(2);
const twoTwo = fixTwo(2)(2);
const threeThree = fixTwo(3)(3);
const threeFour = fixTwo(3)(4);

재사용성도 높아진다.

// a는 2로 고정
const fixTwo = multiple(2);
// b를 3으로 고정
const addFixThree = fixTwo(3);
let result = addFixThree(4); // 24
result = addFixThree(5); // 30

// b를 4로 고정
const addFixFour = fixTwo(4);
result = addFixFour(4); // 32
result = addFixFour(5); // 40

ES6의 화살표 함수로 표현하면 다음과 같다.

const multiple = (a) => (b) => (c) => a * b * c;

컴포지션(Composition)

컴포지션은 두 개 이상의 함수를 결합해 하나의 함수를 생성하는 과정이다. 유튜브를 보다가 배운 내용으로 정리한다.

const user = {
  id: 1,
  firstName: "Real",
  lastName: "Bird"
}

genFullName(user);
genAddress(user);
removeNames(user);

result = {
  id: 1,
  fullName: "Real Bird",
  address: "Republic of Korea"
}

user 객체가 있고 각각의 함수를 거치면 result 객체가 되어야 한다. 함수를 하나씩 실행하거나 하나의 함수에서 처리할 수도 있지만, 그런 방식은 명령형에 가깝다. 커링을 이용한 컴포지션 함수를 만들면 선언형으로 처리할 수 있다.

const compose = (...fns) => (obj) => fns.reduce((c, fn) => fn(c), obj);

ES6+의 스프레드 문법으로 여러 개의 인자를 받는다. 그 후 커링으로 객체를 받고, reduce 함수를 이용해 이전 함수 실행 결과를 다음 함수의 인자로 주입한다.

const genFullName = (user) => {
  return {
    ...user,
    fullName:`${user.firstName} ${user.lastName}`
  }
}

const genAddress = (user) => {
  return {
    ...user,
    address: "Republic of Korea"
  }
}

const removeNames = (user) => {
  delete user.firstName;
  delete user.lastName;

  return user;
}

const result = compose(genFullName, genAddress, removeNames);

console.log(result(user));

/*
user {
  id: 1,
  fullName: "Real Bird",
  address: "Republic of Korea"
}
*/

ES5 문법으로 작성하기

위 코드는 ES6 문법을 주로 사용하여 작성했다. 참고한 영상에서 해당 코드를 ES5 문법으로 작성해 보라고 하여 한 번 작성해 봤다.

var user = {
  id: 1,
  firstName: "Real",
  lastName: "Bird"
}

function compose() {
  var fns = arguments;
  return function (obj) {
    var result;
    for (var i = 0; i < fns.length; i = i + 1){
      result = fns[i](obj);
    }
    return result;
  }
}

function genFullName(user) {
  user.fullName = user.firstName + " " + user.lastName;
  return user;
}

function genAddress(user) {
  user.address = "Republic of Korea";
  return user;
}

function removeNames(user) {
  delete user.firstName;
  delete user.lastName;

  return user;
}

var result = compose(genFullName, genAddress, removeNames);

console.log(result(user));

ES6 문법을 싹 걷어냈다.

const 대신 var, 화살표 함수(()=>{}) 대신 function을 사용했다.

스프레드(...fns) 문법도 사용할 수 없기 때문에 compose에서 받는 인자들은 arguments를 이용했다. 객체는 몽키 패치로 새 속성을 추가했다.

reduce는 es5 빌트인 메서드라 사용해도 괜찮지만, reduce를 사용하지 않는 조건이 있다고 쳤다. 나는 반복문을 돌려 fns의 함수들을 실행했다.

영상에서는 재귀를 이용해 compose를 구현하더라.

function compose() {
  var fns = arguments;
  return function rfn(obj, i) {
    i = i || 0;
    if (i < fns.length) {
      return rfn(fns[i](obj), i + 1);
    }
    return obj;
  }
}

결론

커링과 컴포지션에 대해 듣기만 했을 뿐, 무엇인지 전혀 알지 못했다. 우연한 계기로 유튜브 영상을 보고 아주 유용하고 중요한 개념 하나를 배웠다. 익숙해지도록 노력해야지.

참고 @시코 - React 이론 4강 - 함수형 프로그래밍의 백미, Currying과 Composition @시코 - React 이론 5강 - Currying, composition 풀이 및 첨언

[React] Media Stream Cleanup 하기(feat. react-webcam)

Wed, 08 Nov 2023 09:17:02 GMT

Media Capture and Streams API를 이용해 웹캠이나 모바일 카메라를 조작하는 기능을 가지고 여차저차 개발을 했다. 카메라를 켜는 것까지는 성공했지만, 이후가 문제를 발견했다.

캠을 동작하면 브라우저에는 카메라 켜짐 표시가 나타난다. 그리고 페이지를 벗어나면 표시가 꺼지기를 기대한다. 하지만 나의 문제는 그 표시가 꺼지지 않는다는 것이었다. 실질적으로 화면이 촬영되지 않는다고 해도 카메라 켜짐 표시가 계속 떠있는 건 찝찝했다.

분명 video 요소가 사라졌음에도 캠 동작 표시는 온전히 남아있다. 이걸 해결하고자 다분히 노력했다.

노력1. Cleanup Function에서 처리하기

cleanup function은 컴포넌트가 언마운트될 때 참조하거나 실행될 수 있는 코드를 정리하는 기능이다. useEffect에서 return 뒤에 함수를 작성하면 되고, 클래스 컴포넌트의componentWillUnmount와 같다.

그렇게 생각해서 useRef에 담은 video element를 비우는 작업을 cleanup에서 처리했다. 물론 실패했다.

노력2. Media Stream 분리

cleanup에서 캠 동작을 멈추는 것은 올바랐다. 문제는 내부 로직이 어떻게 동작하느냐였다. 하지만 어떻게 해야 할지 감이 안 잡혀 무지성으로 ChatGPT한테 질문했더니 지역 변수에 담아보라는 조언을 얻었다. 해서 useState를 이용해 stream을 담았고, 멈추는 동작을 할 때 state를 비웠다. 이렇게 분리하니 원하는대로 cleanup에서 캠이 멈추는 것처럼 보였다.

그러나 다시 재진입하면 이전 문제가 반복되었다. 도저히 모르겠어서 잠시 포기하는 시간을 가졌다.

노력3. react-webcam 참고하기

해결 방법을 찾아 이러저리 검색을 하다가 react-webcam 라이브러리를 써볼까 하는 고민에 빠졌다. 테스트용으로 설치해보니까 내가 겪은 문제는 아무것도 아니라는 듯 너무 잘 동작했기 때문이다. 그러나 단순히 카메라 화면만 보이면 되기에 스스로 구현해보고 싶은 욕심이 커서 라이브러리 사용은 포기했다. 대신 코드만 참고했다.

나에게 필요한 부분은 stream을 멈추는 부분이었다.

componentWillUnmount() {
  this.unmounted = true;
  this.stopAndCleanup();
}

react-webcam은 클래스 컴포넌트여서 componentWillUnmount로 cleanup했다. unmounted는 혹여나 언마운트되었을 때 media stream을 참조하게 되는 경우 해제하기 위함으로 보였다.

private stopAndCleanup() {
  const { state } = this;

  if (state.hasUserMedia) {
    Webcam.stopMediaStream(this.stream);

  // (...)
  }
}

media stream이 동작 중일 때 현재의 media stream을 받는 stopMediaStream을 실행한다. 여기서도 video의 srcObject와 media stream을 분리한 것을 확인할 수 있었다. 내 접근법 자체가 잘못된 건 아니었다.

private static stopMediaStream(stream: MediaStream | null) {
    if (stream) {
      if (stream.getVideoTracks && stream.getAudioTracks) {
        stream.getVideoTracks().map(track => {
          stream.removeTrack(track);
          track.stop();
        });
        stream.getAudioTracks().map(track => {
          stream.removeTrack(track);
          track.stop()
        });
      } else {
        ((stream as unknown) as MediaStreamTrack).stop();
      }
    }
  }

기본적은 stream 제거 코드다. media stream의 참조를 완전히 끊기 위해서 stop 뿐만 아니라 removeTrack까지 작성한 것으로 보인다.

보면서 의아했던 건 requestUserMediaId의 존재였다. mediaId가 왜 필요한 걸까? 바로 React.StrictMode 때문이었다.

리액트는 순수 함수로 이뤄지기 때문에 재실행해도 같은 UI를 렌더링해야 한다. 개발 단계에서는 React.StrictMode를 통해 이를 검증한다. 그러나 media stream은 외부 api이기 때문에 2번 실행했을 경우 같은 결과를 보장하지 않는다. video에 주입한 1번 media stream이 있고, 추후 실행된 2번 media stream이 있는 것이다. 이를 구분하기 위해서 렌더링에 영향이 없는 변수에 media stream 실행 때마다 requestUserMediaId를 증가시켜 구분하는 것이었다.

private requestUserMedia() {
  // ...
  this.requestUserMediaId++
  const myRequestUserMediaId = this.requestUserMediaId

  navigator.mediaDevices
    .getUserMedia(constraints)
    .then(stream => {
    if (this.unmounted || myRequestUserMediaId !== this.requestUserMediaId) {
      Webcam.stopMediaStream(stream);
    } else {
      this.handleUserMedia(null, stream);
    }
  })
    .catch(e => {
    this.handleUserMedia(e);
  });
  // ...
}

navigator.mediaDevices.getUserMedia는 requestUserMedia가 실행되는 시점에 생성된myRequestUserMediaId를 가지지만, requestUserMediaId는 외부에서 생성되었으므로 최신값을 계속 유지한다. 이후 비동기로 실행되며 이전에 실행되었던 media stream은 stopMediaStream의 단계를 거치게 된다. 이로 인해 react-webcam은 React.StrictMode에서도 원활하게 media stream이 제거된다.

노력4. 내 코드에 적용

media stream을 useState에 저장했던 과정은 렌더링에 영향을 주기도 하고, media stream에 대한 올바른 참조가 아니었다. 때문에 렌더링에 영향이 없으면서 참조가 될 수 있도록 useRef에 media stream을 저장했다.

export default function Webcam(){
  const webcamRef = useRef(null);
  const mediaStreamRef = useRef(null);

  const playStream = () => {
    navigator.mediaDevices.getUserMedia({video:true}).then(stream => {
      mediaStreamRef.current = stream;
      if (webcamRef.current) {
          webcamRef.current.srcObject = stream;
      }
    });
  }

  return (
    
    )
}

제거하는 작업은 다음과 같이 구현했다.

export default function Webcam(){
  // ...
  const mediaStreamRef = useRef(null);

  const playStream = () => {
    // ...
  }

  const stopStream = (stream:MediaStream|null) => {
    if (stream) {
      stream.getTracks().forEach(track => {
        stream.removeTrack(track);
        track.stop();
      });
    }
  }

  return //...
}

언마운트될 때 stopStream이 실행되도록 cleanup을 작성했다.

export default function Webcam(){
  const webcamRef = useRef(null);
  const mediaStreamRef = useRef(null);

  const playStream = () => {
     // ...
  }

  const stopStream = (stream:MediaStream|null) => {
    // ...
  }

    useEffect(() => {
      playStream();
    return ()=>{
      if (mediaStreamRef.current) {
      stopStream(mediaStreamRef.current);
      }
    }
  },[])

  return // ...
}

프로젝트에서는 StrictMode 대비를 몰라 적용하지 않았지만, 재현 코드에서는 한 번 적용해봤다.

export default function Webcam(){
  const webcamRef = useRef(null);
  const mediaStreamRef = useRef(null);
  const requestMediaId = useRef(0);

  const playStream = () => {
       requestMediaId.current++;
    const myRequestMediaId = requestMediaId.current;

    navigator.mediaDevices.getUserMedia({video:true}).then(stream => {
      if (myRequestMediaId !== requestMediaId.current) {
        stopStream(stream);
      } else {
          mediaStreamRef.current = stream;
        if (webcamRef.current) {
          webcamRef.current.srcObject = stream;
        }
      }
    });
  }

  const stopStream = (stream:MediaStream|null) => {
    // ...
  }

  useEffect(() => {
    // ...
  },[])

  return // ...
}

느낀점

포기하지 않고 계속 머릿속에 굴리다 보니 어찌어찌 해결을 위한 단초를 떠올렸다. 검색을 아무리 해도 내가 원하는 방법은 나오지 않아 정말 힘들었지만, 멋진 라이브러리 덕분이었다.

라이브러리의 코드도 뜯어보는 계기도 되었다. 처음으로 진지하게 하나하나 살펴봤다. 이전에도 다른 라이브러리 코드를 보긴 했지만, 너무 커서 내 머리가 못 따라가더라. 하지만 react-webcam은 컴포넌트 하나만 있는 작은 라이브러리여서 부담 없이 볼 수 있었다. 좋은 교보재였다.

또한, 외부 API를 사용할 때는 React.StrictMode를 염두에 둬야 한다는 것을 배웠다. 지우면 해결되지만, 해당 API를 사용할 때마다 지우고 다시 작성하고 할 수는 없으니까.

몇 개월 간 고민했던 부분인데 드디어 해결해 다행이다.

Demo

!codesandbox[webcam-test-4jvvys?fontsize=14&hidenavigation=1&theme=dark]

참고 React Webcam GitHub

[Zustand] 공식 문서만 보고 Zustand 적용해 보기

Mon, 30 Oct 2023 13:11:04 GMT

공식 문서를 돌같이 보는 버릇을 고치자!

0. 개요

그동안 내가 한 프로젝트는 상태관리 라이브러리를 사용하지 않았다. React가 제공하는 Context API와 useReducer를 조합하면 충분히 전역 상태관리가 되었기 때문이다. 규모가 매우매우 작기에 가능한 부분이었다. 하지만 언제까지고 모른 채로 지낼 수는 없었다. 게다가 지난 번에 Redux Toolkit을 사용해 보면서 라이브러리의 편리함을 절감했다. 해서 이참에 다양한 상태관리 라이브러리를 체험해 보고자 했다.

RTK에 이은 라이브러리는 Zustand이다. 대표적인 상태관리 라이브러리들 중 weekly downloads 3위이고, 개인적으로 채용 공고에서도 많이 봐왔기 때문이다. 문서도 깔끔하게 정리되어 있고, 러닝 커브도 낮은 게 마음에 들었다.

상태관리 라이브러리 순위 https://npmtrends.com/@reduxjs/toolkit-vs-jotai-vs-mobx-vs-recoil-vs-redux-vs-zustand

1. Zustand

Zustand는 상태이라는 뜻의 독일어이다. 공식 문서에 따르면, 작고 빠르며 확장 가능한 베어본 상태 관리 솔루션이다. Redux와 크게 차이나진 않지만, provider가 필요 없다는 점과 action이 없어도 상태 변경이 가능하다는 점이 다르다. 나머지는 마찬가지로 store를 생성하고, selector를 이용해 상태를 호출한다. Comparison

대표적으로 권장하는 패턴은 하나의 store를 두고, set/setState를 사용하여 상태를 변경하는 것이다. 혹은 Redux에 익숙하다면 그와 비슷한 패턴으로 만들어 사용할 수도 있다. Flux inspired practice

2. Create Store

TypeScript 환경에서 사용하므로 곧장 TypeScript Guide로 진입했다. state의 타입을 정의하고 create의 제네릭에 주입한다. 주의할 점은 create()가 아니라 create()()라는 점이다. 이렇게 커링(currying)으로 작성하는 이유는 microsoft/TypeScript#10571와 관련이 있다. 요약해 보면, 제네릭을 설정한 경우 T만 주입하면 에러가 발생한다. 불필요하더라도 선언한 제네릭은 적어야 한다. create()()는 이러한 문제를 해결하는 방법이다.

const userStore = create()(
  (set) => ({
    username: "",
    dispatch: (action) => set((state) => dispatchReducer(state, action)),
  })
);

이전에 useReducer를 사용했기에 initial state와 reducer를 사용한 패턴으로 store를 작성했다. 여기서 set은 zustand가 상태를 변경하는 함수이다.

export enum UserActionTypes {
  SET_USER = "SET_USER",
}

const dispatchReducer = (state: UserState, action: UserAction): UserState => {
  switch (action.type) {
    case UserActionTypes.SET_USER: {
      return { ...state, username: action.payload.username };
    }
    default: {
      throw new Error("Can not find action's type");
    }
  }
};

redecer를 작성하면서도 의구심이 들었다. state 단 하나 변경하는 것도 이렇게 장황한데 조금만 더 복잡해지면 어떨까? 이전에 사용했던 방법(context api + useReducer)과 무슨 차이가 있나? 보일러플레이트가 많지 않다는 zustand 취지에 맞는 건가? 그런 생각을 하면서 다른 서비스의 코드도 작성했으나, 예상대로 엄청 장황해지는 것을 느꼈다. 코드가 길어짐에 따라 느낌은 확신이 되어서 방식을 바꾸기로 했다.

3. Slice Pattern

익숙한 방식에서 벗어나 공식 문서가 추천하는 방식을 따랐다. RTK에서 봤던 것과 비슷했는데 하나의 store를 두고 상태마다 Slice를 만들어 병합하는 식이다. 물론 이러한 사실을 안 것은 프로젝트 빌드 이후의 일...(작성 후 수정해야지) Slices Pattern

const createUserSlice: SlicePattern = (set) => ({
  username: "",
  setUsername: (payload) =>
    set((state) => {
      state.username = payload;
    }),
});

일단 user에 대한 slice를 만들었다. 타입의 경우, 중복되는 코드가 있어 커스텀으로 재정의했다. 공식 문서에서 타입에 대해 참고했다. TypeScript Guide - Slices pattern

import { StateCreator } from "zustand";

declare module "zustand" {
  type SlicePattern = StateCreator<
    S & T,
    [["zustand/immer", never], ["zustand/devtools", never]],
    [],
    T
  >;
}

모든 slice에서 immer와 devtools 미들웨어를 사용한다. StateCreator는 다른 slice 타입과 합쳐진 유니온 타입과 해당 slice 타입을 받는데, 다른 slice 타입이 없는 경우 해당 slice 타입만 사용하도록 설정했다. 다른 slice 타입을 주입하면 유니온 타입이 된다.

4. with Middleware

4-1. devtools

import { devtools } from "zustand/middleware";
import { immer } from "zustand/middleware/immer";

const UserBoundStore = create()(
  devtools(immer((...a) => ({ ...createUserSlice(...a) })))
);

slice를 병합하는 store를 생성했다. 여기서 실수를 발견했다. boundStore는 여러 slice를 병합하는 곳이다. 나는 User와 Main Service의 store를 나눴다. 문제는 없지만, 디버깅이 힘들더라. devtools는 크롬 확장 프로그램인 Redux Devtools를 이용해 상태를 추적할 수 있게 해주는데, store가 다르면 상태가 호출되었을 때 해당 store만 추적된다.

예를 들어, 나처럼 userStore가 있고, mainStore가 있다면, user state를 호출했을 때는 username만 추적되고, main state 호출로 변경되면 main만 추적되는 식이다. 개발하고 있을 때는 이 생각이 왜 안 났나 몰라. 원활한 디버깅을 위해서라면 유일한 진실의 원천 원칙을 잘 지켜야겠다.

4-2. immer

immer를 사용하려면 별도로 설치해 종속성을 주입해야 한다. Immer middleware

npm install immer

immer 미들웨어를 사용하면 state 변경이 더 쉬워진다. immer가 상태의 불변성을 보장하는 만큼 새로운 상태를 갈아끼울 필요 없이 재할당하는 느낌으로 변경 가능하다.

setUsername: (payload) => set((state) => { state.username = payload; })

주의할 점은 immer 원칙을 지켜야 한다는 것이다. 그렇지 않으면 다음과 같은 에러가 발생한다.

[Immer] An immer producer returned a new value *and* modified its draft.
Either return a new value *or* modify the draft.

이것은 임시 객체를 수정하는 행동과 새 객체를 반환하는 행동을 동시에 했음을 의미한다. 위 두 행동을 동시에 하는 것은 유효하지 않으며, 새 객체를 반환 하거나 임시 객체 수정, 둘 중 하나만 허용된다. 여기서는 임시 객체를 수정했다.

5. Selector

state를 사용하려면 store에서 해당 state를 꺼내면 된다. Updating state

const firstName = usePersonStore((state) => state.firstName)

// of

const firstName = usePersonStore().firstName

기본적인 사용 방법이지만, 나는 좀 더 구분하기 위해 상태를 호출하는 훅과 변경 함수를 호출하는 훅을 따로 만들었다.

export const useUserState = () => UserBoundStore((state) => state.username);

export const useUserDispatch = () =>
  UserBoundStore((state) => state.setUsername);

useUserState는 상태만 반환하고, useUserDispatch는 변경 함수만 반환한다. 자동으로 셀렉터를 만들어주는 방법도 있고, 라이브러리도 있다고 한다. Auto Generating Selectors

6. 느낀점

main도 이렇게 수정했지만, 정리하면서 store 구성에 문제가 있었음을 인지했으니 작성을 마치는 즉시 수정해야겠다. 프로그램 동작에 문제는 없지만 찝찝하니까.

Context API + useReducer 대신 Zustand를 써 보면서 좋았던 점은

장황하게 적어 내려가던 reducer를 개별 함수로 줄임
불변성을 고려하며 새 객체를 일일이 만들지 않아도 됨
전역 상태 생성마다 필요한 곳을 감싸던 Context Provider를 지움
공식 문서가 깔끔하면서도 자세해서 빠르게 익힐 수 있음

반면, 불편했던 점은 비동기 호출이 RTK처럼 직관적이지 않았다는 점이다. 공식 문서에서는 보기 어려워 검색을 좀 해봤는데, 대부분 다른 라이브러리와 함께 사용하더라. 비동기 패칭과 관련해서 좀 더 시도해 봐야겠다.

7. Bound Store & Set Action Name

위에서 언급했던 실수를 수정했다. 나눠진 store를 하나로 합쳤고, devtools 미들웨어를 원활히 사용하기 위해 slice의 액션명을 설정했다.

const BoundStore = create()(
  devtools(
    immer((...a) => ({
      ...createUserSlice(...a),
      ...createBookInfoSlice(...a),
      ...createBookcaseSlice(...a),
    })),
    { name: "bip-bound-store" }
  )
);

type BoundSlice = UserSlice & BookcaseSlice & BookInfoSlice;

export default BoundStore;

각각의 slice에서는 devtools에서 액션을 쉽게 확인할 수 있도록 set의 이름을 지정했다. zustand/readme - Redux devtools

enum UserActions {
  SET_USERNAME = "user/SetUsername",
}

const createUserSlice: SlicePattern = (set) => ({
  username: "",
  setUsername: (payload) =>
    set(
      (state) => {
        state.username = payload;
      },
      false,
      UserActions.SET_USERNAME // action name
    ),
});

이전에는 Redux Devtools에서 액션이 anonymous로 표기되었으나 이제는 각각 변경에 맞는 액션명이 보인다.

만약 production 단계에서는 devtools를 숨기고 싶다면 devtools option 중 enable을 설정한다.

const BoundStore = create()(
  devtools(
    immer((...a) => ({
      ...createUserSlice(...a),
      ...createBookInfoSlice(...a),
      ...createBookcaseSlice(...a),
    })),
    { name: "bip-bound-store", enabled: !!import.meta.env.DEV }
  )
);

vite 환경에서 개발했기 때문에 import.meta.env.DEV로 개발 환경을 구분했다. 일반 node 환경이라면 process.env.NODE === "production" 등으로 구분할 수 있을 듯하다.

[React] 컴포넌트에서 제네릭 사용하기

Tue, 24 Oct 2023 16:34:46 GMT

타입 매개변수 제네릭 전달

타입을 구체적으로 명시하지 않고 TS의 추론에 맞긴다면, 타입 매개변수를 이용해 손쉽게 추론 가능하다.

const MyComponent = ({ a, b, c }: MyComponentProps) => {
  return (
    
      {a}
      {b}
      
       {Array.isArray(c) ? (
          c.map((item, idx) => (
            
              {JSON.stringify(item)}
            
          ))
        ) : (
          {JSON.stringify(c)}
        )}
      
    
  );
};

interface MyComponentProps {
  a: string;
  b: number;
  c: T;
}

export default MyComponent;

a와 b의 타입은 고정이지만, c는 어떤 타입이 들어와도 받을 수 있다.

Mapped Type

type Mappped = {
  [P in keyof T]: T[P];
};

interface MyComponentProps {
  a: string;
  b: number;
  c: Mappped;
}

{ [P in keyof T]: T[P] }는 Mapped Type이라고 불리는 형태이며, 이렇게 작성 시 위의 T를 그냥 사용한 것과 똑같은 결과를 나타낸다. c가 primitive 타입이라면 그 타입의 모든 속성을 props로 가지게 되고, object 타입이라면 내부 속성만 값으로 가지게 된다.

각각의 타입에 따라 위 이미지와 같은 속성을 얻게 된다.

객체만 전달

primitive나 배열이 아닌 객체 형태의 속성만 전달할 필요가 있을 수도 있다. TS의 유틸리티 타입 중 Record를 사용해 객체 타입만 받도록 지정하면 된다.

const MyComponent = >(
        { a, b, c }: MyComponentProps
  ) => {
  return (
    
      {/* ... */}
    
  );
};

interface MyComponentProps {
  a: string;
  b: number;
  c: T;
}

Record는 속성 key의 타입을 첫 번째 제네릭으로 받고, value의 타입을 두 번째 제네릭으로 받는다. 이렇게 T를 확장시키면 객체 이외의 c값은 오류를 발생한다.

function App() {
  const temp = {
    a: "A",
    child: [
      {
        b: "B",
        c: "C"
      }
    ]
  };
  return (
    
  {/* Type 'string' is not assignable to type 'Record'. */}
      
  {/* Type 'string[]' is not assignable to type 'Record'. */} 
      
  {/* Type '(string | number | true)[]' is not assignable to type 'Record'. */}
      
  {/* No Error */}      
      
    
  );
}

[SASS] SCSS 살펴보기

Wed, 18 Oct 2023 15:49:34 GMT

노마드코더 - CSS Layout 마스터클래스 강의를 정리한 내용입니다.

SCSS는 CSS에 다양한 편의 기능을 추가한 확장 버전으로, nesting, mixins, modules 등의 문법을 제공한다. 그러나 이 문법을 브라우저가 해석하지 못하기 때문에 전처리 과정이 필요하다. SCSS를 CSS로 SASS를 활요해 전처리한다.

Vite 환경에서는 npm add -D sass로 전처리기를 추가한다.

변수 사용

CSS에서는 변수를 선언할 때 :root 블록 안에 --를 prefix하여 선언한다. 변수의 사용은 var() 함수를 이용한다.

root: {
  --bgColor: red;
}

body {
  background-color: var(--bgColor);
}

SCSS에서는 $를 이용해 변수를 선언한다. CSS와 다르게 변수를 그대로 사용한다.

$bgColor: red;

body {
  background-color: $bgColor;
}

Nesting

어떤 태그의 자식 요소에만 스타일을 적용한다면, CSS에서는 태그 트리를 자세히 적어줘야 한다.

ul {
  list-style-type: none;
  padding: 0;
  display: flex;
  gap: 10px;
}

ul li {
  background-color: tomato;
  color: white;
  padding: 5px 10px;
  border-radius: 7px;
}

ul li a {
  text-decoration: none;
  color: white;
  text-transform: uppercase;
}

여기에 hover 상태에 따라 li의 opacity와 a의 color가 변한다고 하자.

ul li:hover {
  opacity: 0.8;
}

ul li:hover a {
  color: gray;
}

이런 식으로 일일이 설정해야 한다. SCSS에서는 Nesting 기능을 제공해 태그 안에 &를 이용하여 태그 안에 적을 수 있다.

ul {
  list-style-type: none;
  padding: 0;
  display: flex;
  gap: 10px;

  li {
    background-color: tomato;
    color: white;
    padding: 5px 10px;
    border-radius: 7px;
    a {
      text-decoration: none;
      color: white;
      text-transform: uppercase;
    }

    &:hover {
      opacity: 0.8;
      a {
        color: gray;
      }
    }
  }
}

Extend

@extend는 공통 로직을 확장하는 키워드이다.

스타일은 같고 배경만 다른 3개의 컴포넌트를 만든다면, 먼저 %를 이용해 공통 스타일을 작성한다. 컴포넌트마다 @extend %공통스타일을 확장하고, 개별적인 스타일을 덧입히면 된다.

%alert {
  margin: 10px;
  padding: 10px 20px;
  border-radius: 10px;
  border: 1px dashed black;
}

.success {
  @extend %alert;
  background-color: green;
}
.error {
  @extend %alert;
  background-color: tomato;
}
.warning {
  @extend %alert;
  background-color: yellow;
}

Mixins

@extend는 유용한 기능이지만, 반복되는 코드가 보인다. 이를 좀더 관리하기 편하도록 함수처럼 만들 수 있다. @mixin과 @include를 사용한다.

@mixin alert($bgColor, $borderColor) {
  background-color: $bgColor;
  margin: 10px;
  padding: 10px 20px;
  border-radius: 10px;
  border: 1px dashed $borderColor;
}

.success {
  @include alert(green, blue);
}
.error {
  @include alert(tomato, white);
}
.warning {
  @include alert(yellow, black);
}

@mixin으로 %alert을 alert()으로 변경해 반복되는 속성(background-color)을 인자로 받았다. 이를 사용하는 컴포넌트에서는 @include로 호출해 인자를 주입하면 된다.

만약 @include로 호출한 함수에 속성을 추가하고 싶다면 중괄호({})를 열고 안에 속성을 적는다. 그 후 @mixin에 @content를 추가하면 된다.

@mixin alert($bgColor, $borderColor) {
  /* ... */
  @content;
}

.success {
  @include alert(green, blue) {
    font-size: 12px;
  }
}
.error {
  @include alert(tomato, white) {
    text-decoration: underline;
  }
}
.warning {
  @include alert(yellow, black) {
    text-transform: uppercase;
  }
}

Responsive Mixins

@mixin을 이용해 반응형 속성을 쉽게 구현할 수 있다.

$breakpoint-sm: 480px;
$breakpoint-md: 768px;
$breakpoint-lg: 1024px;
$breakpoint-xl: 1200px;

@mixin smallDevice {
  @media screen and (min-width: $breakpoint-sm) {
    @content;
  }
}

@mixin mediumDevice {
  @media screen and (min-width: $breakpoint-md) {
    @content;
  }
}

@mixin largeDevice {
  @media screen and (min-width: $breakpoint-lg) {
    @content;
  }
}

@mixin xlDevice {
  @media screen and (min-width: $breakpoint-xl) {
    @content;
  }
}

mixin 안에 media querie를 설정한다.

body {
  @include smallDevice {
    background-color: blue;
  }

  @include mediumDevice {
    background-color: tomato;
  }

  @include largeDevice {
    background-color: purple;
  }

  @include xlDevice {
    background-color: brown;
  }
}

필요한 곳에서 @include를 호출하면 반응형으로 스타일링할 수 있다.

[BiP] 로그인 로직 변경 기록

Sun, 15 Oct 2023 19:53:03 GMT

프리온보딩 FE 챌린지 10월 - 로그인 기능 구현, 하나부터 열까지! 강의를 들으면서 내가 만든 개인 프로젝트의 로그인 로직이 계속 신경 쓰였다. 만들고 싶었던 기능에만 치중해 기본이면서도 가장 중요한 로그인을 대충 만들었기 때문이다. 얼마나 대충 만들었는지 보면 깜짝 놀라리라.

아무튼 강의에서 들은 내용을 참고해서 봐주기 힘든 로그인 과정을 그나마 볼 만한 모양새로 고친 과정을 기록해 보기로 한다.

유저 식별과 로그인 유지

로그인의 목적은 유저에게 서비스 이용 권한이 있는지 식별하고, 유저의 행위를 제어하고 관리하기 위함이다. 등록되지 않은 유저가 서비스의 CRUD 요청을 멋대로 해서는 안 되고, 권한이 없는 페이지에 접근해서도 안 된다.

식별된 유저라면 서비스를 계속 이용할 수 있도록 인증 상태를 유지해야 한다. 로그인하고 A서비스 이용하고, 로그인하고 B서비스 이용하는 식이라면... 누구도 이용하지 않는 서비스가 될 것이다.

나 역시 이러한 점을 고려해 로그인을 구현했다. 표면적으로는 말이다.

변경 전 로그인 로직

초기 로직을 한 눈에 보기 위해 시퀀스 다이어그램을 그려봤다.

엉망진창이지만 생애최초 다이어그램이니 넘어가자.

먼저 로그인 유지는 다음 과정을 따랐다.

서비스에 접속하면 로컬 스토리지에 저장한 토큰을 확인한다.
- 토큰이 없으면 로그인 페이지로 이동한다.
토큰이 있다면 쿼리 파라미터에 담아 서버의 /auth/check로 식별을 요청한다.
서버에서 토큰에 해당하는 유저를 확인한 후 유저 정보를 담은 응답을 보낸다.
- 유저 정보가 없다면 로그인 페이지로 이동한다.
이후 서비스는 로컬 스토리지에 저장된 토큰을 이용한다.

로그인 과정은 다음과 같다.

구글 로그인 버튼을 누르면 서버의 /auth/google/callback으로 이동하는 창을 연다.
서버에서 passport의 google oauth20 전략을 이용해 소셜 로그인을 시도한다.
- 유저의 email과 profile을 받아온다.
- 기존 유저가 있다면 유저 정보를 서버 세션에 담고, 없다면 생성 후 담는다.
처리가 끝나면 로그인 페이지로 리다이렉트한다.
로그인 페이지로 돌아오면 서버에 /auth/login 요청을 보내 세션에 담긴 유저 정보를 응답에 담아 클라이언트로 보낸다.
받은 응답이 올바르면 유저의 id(!!)를 로컬 스토리지에 토큰으로 저장하고 home으로 푸시한다.
- 아니라면 로그인 페이지에 남겨 둔다.

누군가 옆에서 봤다면 곧장 '으악!'했을 로직이다. 문제 되는 부분을 스스로 짚어 보자.

보안 문제

먼저 유저의 정보라고 할 수 있는 부분을 암호화도 하지 않은 채 로컬 스토리지에 저장한 것이 가장 큰 문제였다. 프로필에 담긴 속성 중 sub를 사용했다. 고유값이긴 하지만 숫자로만 되어 있어서 별로 중요하지 않다고 판단했기 때문이었다. 프로젝트 자체도 털릴 게 없었고.

하지만 이 자체가 위험한 생각이었다. 보안 측면에서 보면 그 내용이 뭐가 되었든 유저의 정보에 해당한다면 숨기는 게 맞았다. 애초에 uuid 등으로 id를 해시값으로 만들었다면 문제가 덜했겠지만, 아무튼 프론트엔드 개발만 생각해 서버쪽은 대충 구현했다.

세션 사용

로그인 유지를 위해서 초기에 세션 방식으로 구현했다. 잘못된 선택은 아니었지만, 그렇다고 특별한 이유가 있지도 않았다. 나아가 REST한 방식으로 API를 구현했다고 생각했는데, 따지고 보면 세션은 REST하지 않은 느낌이 들었다.

REST API의 원칙 중 하나는 클라이언트와 서버 간의 stateless이다. 클라이언트가 서버의 상태를 가지면 안 되고, 서버도 클라이언트의 상태를 가지고 있으면 안 된다. 그러나 세션 방식은 만료 기한이 있다손 치더라도 서버가 클라이언트의 정보를 가지고 있는 셈이다. 내 생각과 구현을 일치시키기 위해서 세션 방식을 쳐냈다.

불필요한 로그인 요청

변경할 방식을 이렇게 저렇게 생각하다 보니 login 요청도 말이 안 됐다. 페이지 랜딩 시 유저 정보를 검사하는 함수를 실행한다. 로그인 시도 후 페이지로 돌아오면 로그인 함수도 실행되고, 검사 함수도 실행된다. 어쩌다 이런 멍청한 코드를 짠 건지 의문이 드는 대목이었다. 지금도 멍청하지만, 예전에는 더했다. 이것도 고치기로 했다.

이 문제들에 중점을 두고 로직을 변경하기 시작했다.

변경 후 로그인 로직

변경한 로직의 시퀀스 다이어그램이다. 수정한 부분을 중점으로 보자.

JWT를 활용한 토큰 방식 사용

세션 방식을 버리고 refresh token과 access token을 사용하는 토큰 방식을 채용했다. 구글 로그인을 요청하면 성공 콜백함수에서 refresh token을 생성하여 응답 쿠키에 담아 보낸다. 이후 로그인 페이지로 redirection되고, 서버에 유저 정보를 체크하는 요청을 보내는 check 함수가 실행된다.

서버에서는 헤더의 Authorization에 담아 보낸 Bearer access token을 확인한다. access token이 유효하면 유저 정보와 기존 토큰을 응답한다. 만약 access token이 없거나 유효하지 않다면 쿠키에 담긴 refresh token을 검사한다. 유효하다면 새로운 access token을 발급하지만, 이것마저 유효하지 않다면 에러을 응답한다.

발급 받은 access token은 이전과 마찬가지로 로컬 스토리지에 저장했다. 차이점은 유저 식별 정보가 암호화되었다는 것과 토큰에 만료 기한이 있어 영구 보관이 되지 않는다는 점이다. 이러한 check 과정이 모든 페이지에서 실행되도록 했다. 덕분에 위에서 언급한 불필요한 로그인 요청을 제거할 수 있었다.

느낀점

코드는 크게 의미 있는 것 같지 않고, 너무 못생겨서 첨부하지 않았다. 코드 보다 로직을 이해하는 게 더 중요하기도 하고.

간단하게만 생각했던 로그인이 전혀 간단하지 않음을 깨달았다. 그나마 내 프로젝트 규모가 작아서 사용자 식별만 생각하면 되는 것이지, 다른 큰 서비스처럼 admin이 나뉘고, 다른 도메인과 연결하고 하다 보면 진짜 어마어마하게 복잡할 것이다.

또 서버 코드를 직접 변경하면서 어떤 식으로 요청을 주고 받는지 더 깊게 이해할 수 있었다. 이전에는 단순하게 클라이언트에서 요청을 보내면 서버에서 그 요청에 해당하는 응답만 해주면 된다고 생각했다. 그래서 변경 전 로직이 그 모양이었고. 이제는 내가 어떻게 요청을 보내야 서버에서 어떤 응답을 하는지 사전에 고민해 보고, 적절한 에러핸들링까지 포함한 코드를 작성할 수 있을 것 같다.

로그인 뿐만 아니라 본 서비스에 대한 요청과 처리도 이번에 배운점을 이용해서 더 나은 코드로 리팩토링해 봐야겠다. 로직과 코드가 일치하는 개발자를 목표로 하자.

[CSS] Grid

Sun, 08 Oct 2023 18:59:26 GMT

노마드코더 - CSS Layout 마스터클래스 강의를 정리한 내용입니다.

FlexBox가 1차원 형태로 레이아웃을 정의했다면, Grid는 2차원 형태로 레이아웃을 정의하는 기능이다. 행렬을 가지며 그와 관련된 속성으로 레이아웃을 수정할 수 있다.

부모 요소에서 설정해야 하며 display: grid로 선언한다.

Grid

Columns and Rows

열은 grid-template-columns로 설정하고, 행은 grid-template-rows로 설정한다. 단순히 개수만 적는 게 아니라 각 행열의 크기도 입력해야 한다.

예를 들어, 200px인 열 2개와 100px인 행 2개로 이뤄진 grid 컨테이너를 만든다면 다음 코드처럼 적는다.

.father {
  display: grid;
  grid-template-columns: 200px 200px;
  grid-template-rows: 100px 100px;
  gap: 10px;
}

여기서 gap은 FlexBox와 마찬가지로 column-gap과 row-gap으로 나눌 수도 있고, 한 줄로 단축할 수도 있다.

Grid Lines

gird 컨테이너를 생성하면 크롬의 개발자 도구에서 컨테이너 형태를 시각적으로 확인할 수 있다. 컨테이너 요소 옆에 grid 버튼을 활성화하면 된다.

다양한 숫자가 보이는데, 각각 grid의 자식요소가 차지할 공간을 의미한다. 예를 들어, child 1은 세로줄 1번부터 세로줄 2번까지 차지하고 있고, 가로로는 1번과 2번을 차지하고 있다. 즉, 자식요소가 시작되는 라인이 grid-###-start이고, 끝나는 라인이 grid-###-end인 셈이다(###에는 colum이나 row의 자리이다.).

grid-column-start는 자식 요소가 어느 세로 라인에서 시작할지 정한다. grid-colum-end는 자식 요소가 어느 세로 라인까지 가서 끝날지 정한다. row는 가로 라인에 영향을 끼친다.

만약 child 1을 두 개의 열 모두 차지하게 한다면 grid-column-start: 1; grid-column-end: 3;으로 입력한다.

.child:first-child {
  grid-column-start: 1;
  grid-column-end: 3;
}

단축 속성으로는 grid-column: 1 / 3을 입력하면 된다. row도 마찬가지다.

음수의 역할은 기준선을 거꾸로 뒤집었다고 생각하면 된다. -1은 grid 컨테이너의 맨 끝을 의미한다. grid-column: 1 / -1은 위에 작성한 것과 같다. 단, 열이 늘어났을 때 양수만 적은 코드는 레이아웃이 망가질 수 있지만, 음수로 끝을 정한 코드는 늘어난 열 끝까지 차지한다.

Line Names

숫자로 라인을 설정하다 보면 헷갈릴 위험이 크고 보기도 좋지 않다. 이런 점을 대비해 grid는 라인별로 명명하는 기능을 제공한다.

.father {
  display: grid;
  grid-template-columns: [apple] 100px [pure] 200px [cherry] 50px [orange];
  grid-template-rows: [sword] 200px [spear] 100px [bow];
  gap: 10px;
}

행열의 크기를 정한 단위 사이마다 대괄호([])를 이용해 라인 이름을 짓는다. 크롬 개발자 도구의 element 하위 탭인 Layout에서 Show line names로 변경하면 적용한 라인 이름을 볼 수 있다.

라인 표기가 숫자에서 명명한 이름으로 변경되었다.

grid-column 등의 설정은 숫자 대신 명명한 이름으로 적어 설정한다.

.child:first-child {
  grid-column: apple / cherry;
  grid-row: sword / bow;
}

Grid Template

fr(fraction)

grid의 영역을 지정하는 단위 중 fr이 있다. 비율로 공간의 영역을 정하는 단위이다.

body {
  height: 100vh;
  display: grid;
  grid-template-columns: 1fr 2fr 1fr 1fr;
  grid-template-rows: 1fr 1fr 1fr 1fr;
}

grid 컨테이너의 공간 중 열은 1:2:1:1 비율로 나누고, 행은 1:1:1:1 비율로 나눈 것을 의미한다. 화면을 키우거나 줄여도 2번째 열의 요소는 다른 요소보다 2배 크게 유지된다.

Grid Area

grid 컨테이너 내에 영역 이름을 짓고, 자식 요소에 어느 영역에 있어야 하는지 이름을 지정하여 레이아웃을 구성한다.

body {
  height: 100vh;
  display: grid;
  grid-template-columns: 1fr 1fr 1fr 1fr;
  grid-template-rows: 1fr 2fr 1fr;
  grid-template-areas:
    "header header header header"
    "content content content menu"
    "footer footer footer footer";
}

header는 4개의 열을 차지하며 첫 번째 행에 위치한다. content는 3개의 열과 두 번째 행에 위치하고, 같은 행 남은 열에는 menu가 위치한다. footer는 4개의 열과 마지막 행에 위치한다.

header {
  background-color: aqua;
  grid-area: header;
}

section {
  background-color: coral;
  grid-area: content;
}

aside {
  background-color: forestgreen;
  grid-area: menu;
}

footer {
  background-color: deeppink;
  grid-area: footer;
}

해당 영역에 위치할 요소에 grid-area를 이용해서 영역 이름을 부여한다.

정한 이름에 맞춰 해당 태그들이 위치한 것을 볼 수 있다.

grid-template

행열과 영역의 속성을 단축하여 grid-template을 쓸 수 있다.

body {
  grid-template:
    "header header header header" 1fr
    "content content content menu" 2fr
    "footer footer footer footer" 1fr / 1fr 1fr 1fr 1fr;
}

영역명 바로 옆에 있는 것은 row의 크기, 슬래시(/) 옆에 있는 것은 column의 크기를 가리킨다.

Span Keyword

명시적으로 요소의 끝지점을 입력하고 싶지 않을 때 span 키워드를 사용한다. span은 시작 라인부터 요소를 지정한 크기만큼 늘린다. grid-column: span 2라면 세로 1라인부터 2줄 늘어나 세로 3라인까지 요소가 늘어난다. 시작 라인을 바꾸면 변경된 시작점에서 span 크기만큼의 영역으로 늘어나게 된다.

Auto Columns and Rows

grid가 다룰 수 있는 행/열 보다 더 많은 content가 추가될 때, 이후에 생성되는 요소의 grid 크기를 자동으로 맞출 수 있다.

grid-auto-rows는 새 요소의 row 크기를 자동으로 맞춘다. grid-auto-columns는 새 요소의 column 크기를 자동으로 맞춘다. grid-auto-flow은 grid가 row/column 중 어느 방향으로 적용될지 설정한다. 기본값은 row이다.

.father {
  display: grid;
  min-height: 50vh;
  gap: 10px;
  grid-template-columns: repeat(2, 1fr);
  grid-template-rows: repeat(2, 1fr);
  grid-auto-rows: 1fr;
  grid-auto-columns: 1fr;
  grid-auto-flow: column;
}

Align and Justify Items

grid 셀 내에서 자식 요소의 위치를 지정할 때 align-items와 justify-items을 사용한다. 두 속성을 하나로 축약한 단축 속성으로 place-items가 있다. 특정 자식 요소의 위치를 지정할 때는 align-self와 justify-self를 사용한다. place-items로 축약하여 사용할 수 있다.

align-items : 셀 내 요소의 수직 위치를 옮긴다. start, center, end 그리고 stretch가 있다. stretch의 경우 자식 요소가 높이나 너비를 가지지 않아야 동작한다.
justify-items : 셀 내 요소의 수평 위치를 옮긴다. 속성값은 위와 동일하다.
place-items: 위 두 속성의 단축 속성으로, 첫 번째 값으로 align-items 값이 오고, 두 번째 값으로 justify-items 값이 온다. 같을 경우 하나로 합칠 수 있다.
align-self, justify-self, place-self : 위와 똑같이 동작하지만, 특정 자식 요소에 적용한다는 차이가 있다.

Align and Justify Content

grid의 모든 셀을 하나로 취급하면 content가 된다. content의 위치를 지정하는 속성이 align-content와 justify-content이며, 단축 속성으로 place-content가 있다. 주의 사항은 grid 컨테이너에 content를 옮길 공간이 있어야 한다는 것이다. 만약 1fr로 설정해 빈 공간이 없다면 해당 속성은 동작하지 않는다. 값은 flex에서의 justify-content 속성과 같다.

align-content : content의 수직 위치를 옮긴다.
justify-content : content의 수평 위치를 옮긴다.
place-content : 위 두 속성의 단축 속성으로, 첫 번째 값은 align-content, 두 번째 값은 justify-content이다.

Auto Sizing and Minmax

grid 셀 내의 내용물 사이즈에 따라 row/column의 크기를 조절할 수 있는 값이 있다.

max-content : 자식 요소의 content가 필요한 만큼 크기를 할당한다.
min-content : 자식 요소의 content가 가질 수 있는 최소 크기를 할당한다.
minmax(minimum, maximum) : minimum 값보다 작아지지 않고 maximum 값보다 커지지 않는 크기를 할당한다.

Auto Fill and Auto Fit

auto-fill과 auto-fit은 정해진 row/column 크기에 따라 자동으로 grid의 셀 개수를 설정해주는 속성이다.

auto-fill

.father {
  display: grid;
  min-height: 50vh;
  gap: 10px;
  grid-template-columns: repeat(auto-fill, minmax(200px, 1fr));
}

auto-fill의 경우, 화면이 줄어들면서 셀의 크기가 200px보다 작아지면 모든 셀의 열 크기가 1fr에 맞춰지도록 열의 개수를 줄인다. 단, 화면의 크기가 늘어났을 때 요소가 담기지 않은 셀이라도 1fr을 충족한다면 열의 개수를 채운다.

auto-fit

.father {
  display: grid;
  min-height: 50vh;
  gap: 10px;
  grid-template-columns: repeat(auto-fit, minmax(200px, 1fr));
}

auto-fit도 마찬가지로 동작하지만, 늘어났을 때의 반응이 다르다. 빈 공간이 1fr을 충족하더라도 무시하고 요소들의 크기를 빈 공간과 합쳐 1fr을 유지한다.

GRID GARDEN

grid 속성을 게임으로 익힐 수 있는 사이트 https://cssgridgarden.com/#ko

[RTK] 공식 문서만 보고 Redux Toolkit 적용해 보기(2)

Sat, 07 Oct 2023 16:12:33 GMT

공식 문서를 돌같이 보는 버릇을 고치자!

[RTK] 공식 문서만 보고 Redux Toolkit 적용해 보기(1)에 이어 작성하는 글이다.

5) todoReducer

todo의 로직도 auth와 큰 차이는 없다. 다만, CRUD 요청이 모두 비동기로 발생해 createAsyncThunk를 4번 사용했다. extraReducers에서도 콜백 함수의 builder를 4번 호출했다. .addCase로 연결하여 호출할 수도 있지만, 개인적으로 가독성이 떨어져 api 호출별로 builder.addCase를 나눠 작성했다.

extraReducers: (builder) => {
  // get todo list
  builder
    .addCase(fetchTodoList.pending, (state) => {
    state.isLoading = true;
  })
    .addCase(fetchTodoList.fulfilled, (state, action) => {
    state.isLoading = false;
    state.todoList = action.payload;
  })
    .addCase(fetchTodoList.rejected, (state) => {
    state.isLoading = false;
  });
  // create todo
  builder
    .addCase(fetchCreateTodo.pending, (state) => {
    state.isLoading = true;
  })
    .addCase(fetchCreateTodo.fulfilled, (state, action) => {
    state.isLoading = false;
    state.todoList.todos = [
      ...state.todoList.todos,
      action.payload.newToDoData,
    ];
  })
    .addCase(fetchCreateTodo.rejected, (state) => {
    state.isLoading = false;
  });
  // update todo
  builder
    .addCase(fetchUpdateTodo.pending, (state) => {
    state.isLoading = true;
  })
    .addCase(fetchUpdateTodo.fulfilled, (state, action) => {
    state.isLoading = false;
    state.todoList.todos = state.todoList.todos
      .map((todo) => todo.id === action.payload.updateTodo.id
           ? action.payload.updateTodo
           : todo
          );
  })
    .addCase(fetchUpdateTodo.rejected, (state) => {
    state.isLoading = false;
  });
  // delete todo
  builder
    .addCase(fetchDeleteTodo.pending, (state) => {
    state.isLoading = true;
  })
    .addCase(fetchDeleteTodo.fulfilled, (state, action) => {
    state.isLoading = false;
    state.todoList.todos = state.todoList.todos.filter(
      (todo) => todo.id !== action.payload.id
    );
  })
    .addCase(fetchDeleteTodo.rejected, (state) => {
    state.isLoading = false;
  });
},

주석으로 구분하긴 했지만, 그래도 보기가 좋지 않았다. 호출하는 함수만 다른 같은 로직이 수두룩 빽빽했기 때문이다. 이걸 어떻게 해결해야 하나 진짜 오래 고민했다. 그러다 참지 못하고 검색 찬스를 사용하고 말았다...!

RTK extrareducers builder combine을 검색하니 가장 위에 나와 비슷한 고민을 한 사람의 스택오버플로 질문이 있었다. 이 사람도 에러 로직이 같은데 어떻게 DRY하게 만드냐고 질문했다. 그 중 addMatcher를 사용한 답변을 참고했다.

공식 문서를 살펴 보니 addMatcher는 들어오는 작업을 action.type 속성 대신 자체 필터 함수와 일치시킬 수 있는 메서드이다.(역시 공식 문서는 답을 알고 있다, 두둥!)

첫 번째 인자로 matcher 함수를 받고, 두 번째 인자로 reducer를 받는다.

내게 필요한 과정은 pending일 때 isLoading = true로, fulfilled or rejected일 때는 isLoading = false로 변화시키는 것이다.

enum AsyncThunkTypes {
  pending = "pending",
  fulfilled = "fulfilled",
  rejected = "rejected",
}

const todoReducer = createSlice({
  // (...)
  extraReducers: (builder) => {
    // ...builder.addCase(...)

    builder
      .addMatcher(
      (action: PayloadAction) => action.type.endsWith(AsyncThunkTypes.pending),
      (state) => {
        state.isLoading = true;
      }
    )
      .addMatcher(
      (action: PayloadAction) =>
      action.type.endsWith(AsyncThunkTypes.fulfilled || AsyncThunkTypes.rejected),
      (state) => {
        state.isLoading = false;
      }
    );
  },
}

pending일 때의 addMatcher와 fulfilled 또는 rejected일 때의 addMatcher로 나눠 적용했다. 어쨌든 반복되는 부분을 줄여 만족했다.

6) 커스텀 훅 내용 대체

auth 때와 마찬가지로 todo도 useTodoList 커스텀 훅의 내용을 수정했다.

function useTodoList() {
  const { createTodo, getTodos, updateTodo, deleteTodo } = useToDoContext();
  const [todoList, setTodoList] = useState([]);
  const { state, loading, onFetching } = useFetch(getTodos);

  useEffect(() => {
    if (state?.ok) {
      setTodoList(state.todos);
      }
  }, [loading, state]);
  return { ... }
}

상태 관리와 별개로 useFetch 커스텀 훅으로 받아온 데이터를 다시 useState에 저장하는 쓸데없는 코드와 context를 제거했다.

function useTodoList() {
  const {
    todoList: { todos: todoList },
    isLoading: loading,
  } = useAppSelector(selectTodoState);
  const dispatch = useAppDispatch();

  useEffect(() => {
    dispatch(fetchTodoList());
  }, [dispatch]);
  return { ... }
}

배운점

Redux를 적용하고자 공식 문서를 보면서 열심히 달렸다. 충격적인 사실은 내가 본 것은 Redux 공식 문서였고, 내가 사용한 Redux Toolkit의 공식 문서는 따로 있었다는 사실이다! 어쩐지 API를 아무리 봐도 스펙 설명이 없더라니... 조금 더 꼼꼼히 살펴야겠다. - Redux Toolkit Docs
RTK를 처음 사용해봤지만, 개발하는데 필요한 정보는 공식 문서에 다 있었다. 평소 라이브러리를 사용할 때 강의나 서적으로 접해 써 보고, 에러가 발생하면 구글링부터 했다. 그러나 이번에 공식 문서만 보면서 강의 및 구글링의 유혹을 떨쳐냈고, 목표한 바를 구현했다. 중간에 참지 못하고 검색했지만, 그 문제의 해결책 역시 이미 공식 문서에 있었다. 앞으로는 공식 문서로 먼저 공부해야겠다.
개인적으로 상태 관리 라이브러리를 사용하니 로직을 보기 편했다. 중요한 수정은 reducer만 건들면 되니까. 적절한 라이브러리의 사용은 삶의 질을 향상시키는 것 같다.
아쉬운 점은 여전히 보는 게 익숙하지 않아 전체를 살피지는 못했다는 점이다. 분명 더 나은 코드를 작성할 수 있고, 더 좋은 기능이 있을 텐데. 앞으로도 차차 살피면서 익혀야 할 문제다.

[RTK] 공식 문서만 보고 Redux Toolkit 적용해 보기(1)

Fri, 06 Oct 2023 21:22:32 GMT

공식 문서를 돌같이 보는 버릇을 고치자!

FE를 꿈꾸면서 상태 관리 라이브러리를 등한시했다. 프로젝트라고 해봤자 개인 프로젝트이고 규모가 토이 수준이다 보니 '굳이?'라는 생각을 많이 했다. React로 개발하니 Context API와 useReducer면 충분했으니까. 하지만 채용 공고에서 상태 관리를 자주 언급되다 보니 익히지 않을 수는 없었다.

그 와중에 나는 공식 문서를 보는데 매우 서툴렀다. 이런 부분도 고치는 의도에서 공식 문서만 보고 토이 프로젝트에 적용해 보는 연습을 계획했다.

제일 처음 고른 공식 문서는 Redux이다. 상태 관리도 익히면서 공식 문서도 읽을 수 있기 때문에 선택했다.

소재로 사용한 토이 프로젝트는 ToDo App으로, 예~전에 원티드 프리온보딩 인턴십 프론트엔드 11차에서 선발 과제로 했던 프로젝트를 사용했다.

Redux

Redux는 자바스크립트 앱을 위한 예측 가능한 상태 컨테이너입니다. - Redux 시작하기

공식 문서의 한 줄처럼 JavaScript 환경이라면 어디에서든 사용할 수 있는 상태 관리 라이브러리이다.

상태를 모아두는 하나의 store를 컨테이너처럼 두고, 필요한 곳에서 불러와 사용한다(진실은 하나의 근원). 이때, 상태는 불변성을 유지하는 객체이며, 변화는 action이라는 트리거를 통해 동작한다(상태는 읽기 전용). 트리거되는 동작의 조건은 순수 함수인 reducer에서 지정한다(변화는 순수 함수로 작성). - 3가지 원칙

Redux는 언제 사용할까?

공식 문서에서 Redux를 추천하는 경우는 다음과 같다.

앱의 여러 위치에서 필요한 대량의 애플리케이션 상태가 있는 경우

앱 상태가 자주 업데이트되는 경우

해당 상태를 업데이트하는 로직이 복잡한 경우

앱에 중대형 코드베이스가 있고 많은 사람이 작업하는 경우

시간이 지남에 따라 해당 상태가 어떻게 업데이트되는지 확인해야 하는 경우 - FAQ - General

이 설명을 보면 주로 규모가 큰 프로젝트에서 사용하는 라이브러리라는 생각이 든다. 나는 이런 경우가 없었기에 강의나 서적에서 배웠어도 고려를 안 했다. 댄 아브라모브도 "React에서 문제가 생길 때까지 Redux를 사용하지 말아라"라고 했다니까.

따라서 내 토이 프로젝트에 Redux를 적용하는 것은 이론상 부적절한 부분이다. 그러나 어쩌겠는가, 배우려면 어디엔가는 적용해야 익히지. 나는 그런 마음으로 사용했다.

RTK 적용하기

강의나 서적에서 Redux + Redux-Thunk 조합이나 Redux + Redux-Saga 조합을 주로 배웠다. 그래서 나도 이렇게 써봐야 하나 고민했는데, 마침 공식 문서에 이런 문장이 있었다.

Redux Toolkit은 Redux 로직을 작성하기 위해 저희가 공식적으로 추천하는 방법입니다. RTK는 Redux 앱을 만들기에 필수적으로 여기는 패키지와 함수들을 포함합니다. 대부분의 Redux 작업을 단순화하고, 흔한 실수를 방지하며, Redux 앱을 만들기 쉽게 해주는 모범 사례를 통해 만들어졌습니다. - Redux 시작하기

무려 공식적으로 추천하는 방법이며 모범 사례를 통해 만들어졌다고 한다. 못 참는 단어의 조합이었다.

0) 설치

가이드에 따라 RTK와 React-Redux를 설치했다. - Quick Start

npm install @reduxjs/toolkit react-redux

천천히 살펴 보니 기본 사용법은 배운 것과 큰 차이가 없었다.

1) store 만들기

// store
import { configureStore } from "@reduxjs/toolkit";

const store = configureStore({
  reducer: {},
});

export default store;

상태 컨테이너로 사용할 store를 만들고 export하고, 최상위 트리에서 Provider에 정의한 store를 추가한다.

// index.tsx
import React from "react";
import ReactDOM from "react-dom/client";
import "./index.css";
import { RouterProvider } from "react-router-dom";
import router from "./Router";
import { HelmetProvider } from "react-helmet-async";

// Redux를 사용하기 위한 store와 Provider 추가
import { Provider } from "react-redux";
import store from "./store";

const root = ReactDOM.createRoot(
  document.getElementById("root") as HTMLElement
);

root.render(
  
    
      
        
      
    
  
);

2) 탐색하기

처음 작성하려니 어디서부터 시작해야 할지 막막했다. 일반 Redux와 다르게 createSlice라는 함수를 사용하여 reducer를 생성했기 때문이다. 그래서 조금 천천히 뜯어봤다. - Quick Start

import { createSlice } from '@reduxjs/toolkit'

export const counterSlice = createSlice({
  // store에 저장될 상태의 이름표
  name: 'counter',
  // 초기 상태 값
  initialState: {
    value: 0
  },
  // 상태를 변경하는 reducer들
  reducers: {
    increment: state => {
      state.value += 1
    },
    decrement: state => {
      state.value -= 1
    },
    incrementByAmount: (state, action) => {
      state.value += action.payload
    }
  }
})

// disaptch로 사용할 트리거들
export const { increment, decrement, incrementByAmount } = counterSlice.actions

export default counterSlice.reducer

여기서 눈에 띈 점은 state.value += 1처럼 상태를 직접 변경하는 듯 보이는 코드였다. '상태는 읽기 전용 아니었나?'라고 생각했으나

createSlice는 Immer 라이브러리를 사용하는 리듀서를 작성할 수 있게 해줍니다. 이를 통해 state.value = 123과 같은 "변형 (mutating)" JS 문법을 spreads 없이도 불변성을 유지하며 업데이트할 수 있습니다. - Redux Toolkit은 무얼 하나요?

위 문장을 통해 이유를 알 수 있었다. immer 라이브러리는 객체를 불변성으로 만들어주는 역할을 하는데, draft를 통해 draft += 1과 같이 직접 수정하는 것처럼 작성하여 새 상태를 반환해주는 기능을 제공한다. 뭔가 보기에는 불변성을 위배하는 것 같아 찝찝하지만, 근거도 명확하고 신경 쓸게 덜어져 확실히 편하기는 했다.

여기에 더해서, TypeScript를 필수로 사용하므로 TS 예제도 함께 살펴 봤다. RTK TypeScript Quick Start - Define Root State and Dispatch Types

import { configureStore } from '@reduxjs/toolkit'
// ...

const store = configureStore({
  reducer: {
    posts: postsReducer,
    comments: commentsReducer,
    users: usersReducer
  }
})

// 스토어 자체에서 'RootState' 및 'AppDispatch' 유형을 추론합니다.
export type RootState = ReturnType
// Inferred type: {posts: PostsState, comments: CommentsState, users: UsersState}
export type AppDispatch = typeof store.dispatch

다른 장소에서 state가 어떤 요소들과 트리거를 지녔는지 알기 위해 RootState와 Dispatch 타입을 정의한다. store.getState()는 Redux에서 store에 저장된 상태를 반환해주는 함수로, ReturnType은 그 함수의 반환 값 타입을 RootState의 타입으로 지정함을 의미한다. 가령, state:RootState라면 그 안에는 posts, comments, users가 담겨 있다.

TS 환경에서는 useSelector나 useDispatch 훅을 새로 정의해야 한다.

import { TypedUseSelectorHook, useDispatch, useSelector } from 'react-redux'
import type { RootState, AppDispatch } from './store'

export const useAppSelector: TypedUseSelectorHook = useSelector
export const useAppDispatch: () => AppDispatch = useDispatch

이렇게 정의하는 데에는 특별한 이유가 있다고 한다. - RTK TypeScript Quick Start - Define Typed Hooks

useSelector의 경우 매번 입력할 필요가 없습니다(state: RootState).

useDispatch의 경우 기본 Dispatch 유형은 thunks에 대해 알지 못합니다. thunks를 올바르게 dispatch하려면 store에서 thunk middleware 유형이 포함된 특정 사용자 정의 AppDispatch 유형을 사용하고 이를 useDispatch와 함께 사용해야 합니다. 미리 입력된 useDispatch 훅을 추가하면 필요한 곳에 AppDispatch를 가져오는 것을 잊어버리지 않게 됩니다.

reducer부분에서도 타입이 필요해진다. initialState는 물론, 매개변수인 action의 타입도 지정해줘야 한다. - RTK TypeScript Quick Start - Define Slice State and Action Types

import { createSlice, PayloadAction } from '@reduxjs/toolkit'
import type { RootState } from '../../app/store'

interface CounterState {
  value: number
}

const initialState: CounterState = {
  value: 0
}

export const counterSlice = createSlice({
  name: 'counter',
  initialState,
     // ...
    incrementByAmount: (state, action: PayloadAction) => {
      state.value += action.payload
    }
  }
})

// export actions...

export const selectCount = (state: RootState) => state.counter.value

export default counterSlice.reducer

이러면 얼추 준비가 끝난 것 같으니 프로젝트에 적용해 보기로 했다.

3) authReducer

내 프로젝트에서 상태를 사용하는 곳은 두 곳이었다. 로그인을 담당하는 auth와 ToDo 서비스를 담당하는 todo. 그 중 auth가 간단해 보였기에 먼저 적용해봤다.

import {
  createAsyncThunk,
  createSlice,
  type PayloadAction,
} from "@reduxjs/toolkit";
import { RootState } from "../store";

// 초깃값 설정
const initialState: AuthSliceState = {
  response: { ok: false, message: "" },
  isLoading: false,
  validation: {
    emailError: "",
    passwordError: "",
  },
};

export const authReducer = createSlice({
  name: "auth",
  initialState,
  reducers: {
    // 필요에 따라 상태를 초기화하기 위한 로직을 짰다.
    // all일 경우에는 전체 초깃값으로 변경하고,
    // 아니라면 payload로 받은 속석만 초기화한다.
    initialize: (
      state,
      action: PayloadAction
    ) => {
      if (action.payload === "all") {
        state = initialState;
        return state;
      }
      const newState = {
        ...state,
        [action.payload]: initialState[action.payload],
      };
      return newState;
    },
  },
});

export const { initialize, validate } = authReducer.actions;

export default authReducer.reducer;

문제는 비동기 통신이었다. 자연스럽게 reducer내부에서 async/await을 휘갈기니 에러가 발생했다. actions의 반환 값은 Promise 타입이 아니기 때문에 당연한 결과였다. 그래서 다시 고민에 빠졌다.

어디를 참고해야 하나 방황하다가 Redux 핵심, Part 5: Async Logic and Data Fetching - Fetching Data with createAsyncThunk를 발견하고 머리가 맑아졌다.

createAsyncThunk는 action type과 Promise를 반환하는 콜백함수를 인자로 받는 함수다. 여기서 반환하는 값이 state로 담긴다.

export const fetchSignin = createAsyncThunk(
  "auth/fetchSignin",
  async (body: RequestBodyType, { rejectWithValue }) => {
    try {
      const response = await authService.signin(body);
      return response;
    } catch (e) {
      return rejectWithValue(e);
    }
  }
);

로그인하는 로직만 가져왔다. rejectWithValue는 api 요청이 거부되었을 때 결과를 반환한다. 에러 핸들링을 위한 처리는 아니었고, 무슨 이유로 요청이 실패해서 확인차 넣었다. 물론 넣은 김에 에러 핸들링이 되어서 남겨 두었다.

이렇게 fetch한 데이터는 일반 reducer로는 컨트롤할 수 없고, extraReducer를 사용해야 한다. - Redux 핵심, Part 5: Async Logic and Data Fetching - Reducers and Loading Actions

export const authReducer = createSlice({
  name: "auth",
  initialState,
  reducers: { ... },

  extraReducers: (builder) => {
    builder
      .addCase(fetchSignin.pending, (state) => {
        state.isLoading = true;
      })
      .addCase(fetchSignin.fulfilled, (state, action) => {
        state.isLoading = false;
        state.response = action.payload;
      })
      .addCase(fetchSignin.rejected, (state) => {
        state.isLoading = false;
      });
  },
});

extraReducers의 builder는 외부에서 작성된 함수의 액션을 실행하여 응답에 대한 상황과 상태를 반환한다. addCase를 통해 여러 상황을 구성할 수 있으며, createAsyncThunk로 만든 함수에 있는 pending, fulfilled, rejected를 이용하여 fetch 로딩 상태나 거부 상태를 손쉽게 설정할 수 있다. 이 부분은 참 매력적이었다. 따로 고민 안 해도 패치 시작 부분과 종료, 거부 부분을 설정할 수 있으니 말이다.

// store/index.ts
const store = configureStore({
  reducer: {
    auth: authReducer,
  },
});

export default store;

// reducer/auth.ts
export const selectAuthState = (state: RootState) => state.auth;

이렇게 설정한 리듀서를 store에 등록한다. 그리고 select를 등록해두면 사전에 정의한 useAppSelector를 사용할 때 selectAuthState를 매개 변수로 주입해 바로 사용할 수 있다.

4) 커스텀 훅 내용 대체

적용한 Redux를 실제로 사용해 기존에 작성한 useSignin이라는 커스텀 훅의 내용을 수정했다. 기존 코드가 아주 더러웠으므로 변한 부분만 짚어 보려고 한다.

// 이전 코드
function useSignin() {
  const { signin } = useSigninContext();
  const { state, onFetching, loading, error } = useFetch<{
    ok: boolean;
    message?: string;
  }>(() => signin({ email, password }), true );

  const onCompleteSignin = (e: FormEvent) => {
    e.preventDefault();
    onFetching();
  };
  return { ... }
}

// 현재 코드
function useSignin() {
  const { response, isLoading } = useAppSelector(selectAuthState);
  const dispatch = useAppDispatch();

  const onCompleteSignin = (e: FormEvent) => {
    e.preventDefault();
    dispatch(fetchSignin({ email, password }));
  };
  return { ... }
}

이전에는 class 객체를 만들어 context로 보낸 다음 메서드를 가져와 사용했고, useFetch라는 커스텀 훅을 만들어 패치한 데이터를 useState에 담아 그것을 반환하여 가져다 썼다. 로직이 반복되어 나름 효율을 추구한다며 만들었지만, 보기에 좋지는 않았다. 또한, 렌더링 시 실행될 로직과 핸들링할 로직을 분리하느라 트리거로 true를 사용했더랬다. true가 있으면 useEffect를 중단하고 onFetching으로 핸들링하는 식이었다.

수정한 코드는 기능 면에서 똑같지만 훨씬 간결하고 직관적이다. 트리거도 dispatch를 통해 내가 핸들링할 수 있다.

지면이 길어져 ToDo 파트는 다음에 이어서 작성해야겠다. 이 글과 큰 차이는 없지만 정리에 의의가 있는 거니까.

[CSS] Flex Box

Mon, 25 Sep 2023 11:15:05 GMT

노마드코더 - CSS Layout 마스터클래스 강의를 정리한 내용입니다.

before FlexBox

FlexBox 등장 이전에는 요소가 가지는 기본 특성을 이용해 화면을 구성했다.

block 속성을 가진 요소는 width와 height를 가지며 화면의 한 줄을 전부 차지하고 다른 요소가 옆으로 오는 것을 막는다.

반면에, inline은 width와 height 속성을 가지지 않으면서 해당 줄(line) 안(in)에 속한다.

block 요소를 가지면서 inline으로 정렬하고 싶다면 display: inline-block을 선언한다.

.box {
  width: 200px;
  height: 200px;
  background-color: tomato;
  display: inline-block;
}

.box:first-child {
  margin-left: 300px; /* 350px, 310px, 315px ...*/
}

.box:last-child {
  margin-right: 300px; /* 350px, 310px, 315px ...*/
}

화면 정렬에 대한 요구사항이 들어왔다면 위처럼 하나씩 계산해 정렬한다.

float을 통해 요소의 정렬을 조금 더 쉽게 할 수 있다. 그러나 세세한 설정은 수동으로 조작해야 한다.

.box:first-child {
  float: left;
}

.box:last-child {
  float: right;
}

.box:nth-child(2) {
  margin: 0 50%; /* 25%, 13%, 10% ...*/
}

하나하나 조정해야 하는 방식은 명령형이며, 이러한 방법은 번거롭고 어렵다. 다양한 화면 크기가 등장하면서 이 어려움은 더욱 심화되었다.

요구사항이 다양해지면서 그렇게 되어야 한다라고 브라우저에게 알려주면 알아서 계산해주는 방식인 선언형이 등장했다.

예를 들어, text-align 속성은 브라우저에게 항상 문자열은 이렇게 정렬되어야 한다를 선언하고, 이후 작성된 문자열은 모두 해당 속성에 맞게 알아서 정렬된다.

선언형으로 화면 구성을 그려주는 것이 FlexBox이다.

FlexBox

FlexBox는 inline-block이나 float과 다르게 자식 요소에 관심이 없다. 부모 요소에 작성하면 그대로 자식 요소를 정렬한다. 단, 바로 아래 있는 직속 자식이어야 만한다.

.father {
  display: flex;
  justify-content: space-between;
}

.box {
  width: 200px;
  height: 200px;
  background-color: tomato;
}

예시로, justify-content: space-between를 선언하면 margin을 계산할 필요없이 첫 번째와 마지막 box는 양 끝에, 두 번째 box는 가운데로 정렬한다.

FlexBox Properties

FlexBox의 속성은 전부 부모 요소에서 작성한다.

gap

자식 요소마다 margin을 부여하고 싶다면 gap 속성을 사용한다.

.father {
  display: flex;
  gap: 10px;
}

gap은 row-gap과 column-gap을 합친 속성이다. 한 줄로 행열 margin을 설정하고 싶다면 gap: row-gap column-gap 순서로 작성한다.

flex-direction

자식 요소 정렬 방향을 정하는 속성은 flex-direction이며, 기본값은 row이다. 세로로 정렬할 시에는 column으로 작성한다. 또한, 정렬되는 자식 요소의 순서를 뒤집을 때는 -reverse 접미사를 더한다.

.father {
  display: flex;
  gap: 10px;
  flex-direction: column; /* default: row*/
  /* row-reverse, column-reverse */
}

justify-content(주축) and align-items(교차축)

flex-direction이 정하는 방향은 매우 중요하다. FlexBox를 정의하는 두 개의 축이 있기 때문이다. Main Axis(주축)와 Cross Axis(교차축)이다.

Main Axis(주축)는 방향이 row일 때는 가로선(왼쪽➡오른쪽)이 되고, column일 때는 세로선(위쪽➡아래쪽)이 된다. Cross Axis(교차축)은 그와 반대, 즉 row일 때는 세로선이, column일 때는 가로선이 된다. -reverse는 반대 방향으로 동작한다.

Main Axis(주축)의 요소 이동은 justify-content 속성을 사용한다.

Cross Axis(교차축)의 요소 이동은 align-items 속성을 사용한다.

`flex-direction`이 `row`인 경우

`flex-direction`이 `column`인 경우

flex-wrap

flex 컨테이너가 한 줄인지, 여러 줄인지 정한다.

기본값은 nowrap으로, 자식 요소를 전부 한 줄에 압축해 넣는다. 자식 요소의 기본 크기는 무시된다.

wrap인 경우, 컨테이너를 넘치는 자식 요소의 경우 다음 줄로 내린다.

-reverse suffix를 가지고 있다.

flex-flow

flex-direction과 flex-wrap을 합쳐 놓은 단축 속성이다. flex-flow: row wrap 형태로 사용한다.

align-content

컨테이너가 여러 줄(flex-wrap: wrap)일 때 요소들을 줄에 맞춰 정렬한다.

.father {
  display: flex;
  height: 100vh;
  width: 100%;
  gap: 10px;
  justify-content: center;
  align-items: flex-start;
  flex-flow: row wrap;
}

가령, 이렇게 작성하면 첫 번째 줄과 두 번째 줄 사이에 빈 공간이 생긴다. 이 간격은 align-content를 사용해 줄일 수 있다.

.father {
  /* ... */
  align-content: center;
}

교차축의 가운데를 기준으로 모든 라인이 정렬된다.

order

자식 요소에 부여하는 속성으로, flex 컨테이너 내부에서 자식 요소의 순서를 결정한다.

순서는 상대적으로 정해지며, 기본값은 0이다.

.box:nth-child(3) {
  order: 1;
  background-color: blueviolet;
}

.box:nth-child(6) {
  order: 2;
  background-color: aqua;
}

이렇게 작성할 경우 box 3은 끝에서 2번째로, box 6은 맨끝으로 이동한다. 나머지 box의 order가 0이기 때문이다.

align-self

자식 요소에 부여하는 속성으로, 요소에 개별적으로 align-items 속성을 적용한다.

.father {
  display: flex;
  height: 100vh;
  width: 100%;
  gap: 10px;
  justify-content: center;
  align-items: center;
  flex-flow: row wrap;
}

.box {
  width: 200px;
  height: 200px;
  background-color: tomato;
}

.box:first-child {
  background-color: blueviolet;
  align-self: flex-start;
}

.box:last-child {
  background-color: aqua;
  align-self: flex-end;
}

flex-grow

자식 요소에서 설정하며, 값을 직접 설정하지 않고 flex 컨테이너의 크기만큼 늘리는 속성이다. 기본값은 0이고 단위는 비율로 사용한다. flex-grow: 1이라면 flex 컨테이너의 공간 최대 크기만큼 늘어난다.

.box:first-child {
  background-color: blueviolet;
  flex-grow: 1;
}

.box:last-child {
  background-color: aqua;
  flex-grow: 1;
}

두 개의 박스가 1:1 비율로 컨테이너의 공간만큼 늘어난다.

flex-shrink

자식 요소에서 설정하며, 값을 직접 설정하지 않고 flex 컨테이너의 비율에 맞춰 줄이는 속성이다. 기본값은 1이다.

.box:first-child {
  background-color: blueviolet;
  flex-shrink: 3;
}

.box:nth-child(2) {
  background-color: teal;
  flex-shrink: 0;
}

.box:last-child {
  background-color: aqua;
  flex-shrink: 1;
}

box 2는 화면 크기가 줄어도 크기가 그대로인 반면, box 1과 box 3은 크기가 줄어든다.

flex-basis

자식 요소에서 설정하며, flex-grow와 flex-shrink의 초기값을 설정하는 속성이다. flex-basis: 500px로 설정하면 크기가 500을 넘어가는 시점에서 grow되거나 shrink된다.

.box:first-child {
  background-color: blueviolet;
  flex-grow: 1;
  flex-shrink: 0;
  flex-basis: 500px;
}

위 코드에서 box 1은 화면이 아무리 작아져도 500px 아래로는 줄어들지 않는다.

flex

위의 세 속성, flex-grow, flex-shrink, flex-basis를 하나로 합친 단축 속성이다. flex: grow shrink basis 순서로 적는다.

.box:first-child {
  background-color: blueviolet;
  flex: 1 0 500px;
}

Flexbox Froggy Game

FlexBox를 게임으로 연습할 수 있는 사이트이다.

https://flexboxfroggy.com/#ko

[React] 빌드 용량 최적화하기(feat. Vite)

Sun, 20 Aug 2023 07:03:47 GMT

얼마 전에 본 면접에서 SPA(Single Page Application)의 단점을 어떻게 해결하느냐에 대한 질문을 받았다. "코드 스플리팅을 통해 파일을 여러 개로 분산하여 로드한다"라고 답했으나, 양심의 가책을 느꼈다. 내 프로젝트에서는 코드를 나눴어도 index.js의 용량이 어마어마했기 때문이다.

lazy를 사용하여 컴포넌트 코드는 스플리팅했지만, 중심이 되는 파일의 용량은 매우 컸다. 뭐 이리 뚱뚱한가 봤더니 사용한 라이브러리가 모두 index에 담겨 있었다. 고민했지만 답은 경고 문구에 있었다.

Use build.rollupOptions.output.manualChunks to improve chunking: https://rollupjs.org/configuration-options/#output-manualchunks

vite에서 빌드 도구로 사용하는 rollup의 수동 스플릿 방법을 안내한다. 공통으로 사용하는 모듈을 분리하는 역할이다. 사용법을 익히기 위해 간단한 프로젝트를 만들어봤다.

setting

npm create vite@latest를 실행하고 React-js 환경으로 설정했다. 페이지를 스플리팅하기 위해 react-router-dom도 함께 설치했다.

/src
  ┣─ App.jsx
  ├─ About.jsx
  └─ main.jsx

대충 이렇게 파일을 만들고 라우트를 작성했다.

import React, { Suspense, lazy } from "react";
import ReactDOM from "react-dom/client";
import "./index.css";
import { BrowserRouter, Routes, Route, Link } from "react-router-dom";
import App from "./App";
import About from "./About";

ReactDOM.createRoot(document.getElementById("root")).render(
  
    
      
        {/* 대충 네비게이션 */}
      
      
        {/* 대충 라우트 */}
      
    
  
);

기본적인 방식으로 컴포넌트를 라우트에 등록했다. 이 상태로 여과 없이 빌드해 보자.

초기 빌드

빌드 로그를 보면 파일 세 개만 생겼다. 내가 사용한 모듈과 컴포넌트는 모두 index.js에 들어있을 터이다.

빌드한 파일을 실행해 보면 빌드된 단 하나의 index.js만 로드한다. 큰 프로젝트가 이렇게 로드된다고 생각해 보자. SPA의 단점인 초기 로딩 속도 느림이 아주 도드라질 것이다.

lazy 사용 빌드

이번에는 React.lazy를 사용해서 스플리팅 후 빌드해보자.

const App = lazy(() => import("./App"));
const About = lazy(() => import("./About"));

ReactDOM.createRoot(document.getElementById("root")).render(
  
    
      
        {/* 대충 네비게이션 */}
      
      
        {/* 대충 라우트 */}
      
    
  
);

의도한 대로 App과 About 컴포넌트는 코드가 분리되어 새로운 파일로 생성되었다. 여기까지가 내가 생각한 코드 스플리팅이었는데, 아무리 봐도 저 index.js의 크기가 납득되지 않았다. 겨우 0.11kb 분리하고 스플리팅이라니. 그렇기 때문에 위에서 언급한 rollupOptions를 추가한 것이다.

manualChunks 빌드

rollupOptions는 vite.config.js에서 build 속성에 추가하여 설정한다.

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

// https://vitejs.dev/config/
export default defineConfig({
  plugins: [react()],
  build: {
    rollupOptions: {
      output: {
        manualChunks: (id) => {
          if (id.includes("node_modules")) {
            return `vendor`;
          }
        },
      },
    },
  },
});

manualChunks에 추입하는 id에 뭐가 들었나 궁금해 콘솔을 찍어봤더니 사용한 모듈의 경로가 쭉 나왔다. 이 상태로 빌드하면 node_modules에서 사용한 코드가 vendor.js 에 모두 모인다. index.js는 가벼워지겠지만, vendor가 무거워진다. 라이브러리가 무거운 거야 어쩔 수 없지마는, 조절할 수 있다면 최대한 줄여보는 게 좋겠다 싶었다.

일단 id에 찍힌 모듈 모양은 이렇다.

D:/work-space/test-build/node_modules/react-dom/index.js?commonjs-module
D:/work-space/test-build/node_modules/react-dom/cjs/react-dom.production.min.js?commonjs-proxy
D:/work-space/test-build/node_modules/react-dom/cjs/react-dom.production.min.js?commonjs-exports
...
D:/work-space/test-build/node_modules/scheduler/cjs/scheduler.production.min.js?commonjs-exports

필요한 부분은 node_modules 뒷부분의 모듈명이다. 이것만 잘라낸다.

const module = id.split("node_modules/").pop().split("/")[0];

/*
...
react
react
react
react-dom
scheduler
scheduler
*/

vendor/${module}을 반환값으로 설정하면 vendor 디렉토리에 모듈별로 파일이 생긴다.

빌드 파일로 앱을 실행해 보면 차이점이 확연히 드러난다.

결과

이런 방법으로 내 프로젝트의 빌드 용량을 최적화하여 690KB에 육박하던 index.js 크기를 약 30KB로 줄였다.

찾은 방법으로 코드를 나누긴 했지만 맞는 방법인지는 모르겠다. 더 나은 방법은 더 찾아봐야겠지만, 소기의 목적은 달성했다. 공부하다 보면 더 나은 방법이 떠오를지도 모르겠다.

참고 rollup - Configuration Options#output-manualChunks

[JS] Context에 전달된 인스턴스 bind한 이유

Tue, 15 Aug 2023 09:14:30 GMT

약 한 달 전, 원티드에서 진행한 프리온보딩 프론트엔드 인턴십 7월의 과제를 진행하면서 팀원의 코드 리뷰를 받은 일이 있었다.

당시 멘토의 코드를 참고해 작성한 터라 왜 그렇게 했는지 이유를 몰랐다. 그냥 '아, 아무 생각 없이 작성했구나' 하고 넘겼다. 그럼에도 한 달 내내 이 궁금증이 가시지 않아 드디어 찾아보게 되었다.

1. TypeError: Cannot read properties of undefined

일단 어떤 문제가 발생하는지 궁금해서 issues를 불러오는 메서드의 bind를 제거했다.

TypeError: Cannot read properties of undefined (reading 'httpClient')

context에서 props로 받은 issuesInstance는 httpClient를 인자로 받아 this.httpClient에 할당한 후 fetch 메서드를 실행한다. 그러므로 여기서 httpClient 속성을 읽지 못하는 것은 this에 해당 속성이 없음을 말한다.

2. 재현

프로젝트를 일일이 뜯어가며 재현하기는 어려워서 간단한 재현 코드를 작성했다.

class TempClass {
  constructor() {
    this.one = 1;
    this.two = 2;
  }

  sum() {
    return this.one + this.two;
  }
}

const tempClass = new TempClass();

const abc = (tempClass) => {
  const x = tempClass.sum.bind(tempClass);
  return x;
};

console.log(abc(tempClass)()); // 3

정상적으로 TempClass를 bind한 abc 함수는 기댓값인 3을 반환한다. 여기서 bind를 지우면 위의 에러가 재현된다.

const tempClass = new TempClass();

const abc = (tempClass) => {
  const x = tempClass.sum;
  return x;
};

console.log(abc(tempClass)());
// TypeError: Cannot read properties of undefined (reading 'one')

sum 메서드의 this를 찍어 보면 undefined가 나온다. 인스턴스를 제대로 전달한 것 같은데 왜 에러가 발생하는 것일까? 문제의 원인은 JavaScript의 this 호출 방식에 있었다.

3. this

여타 객체 지향 언어에서 this는 클래스로 생성한 객체를 가리키지만, JS의 경우는 조금 다르다고 한다. 실행 컨텍스트가 생성될 때 this가 생성되기 때문에 함수 호출 방식에 따라 가리키는 방향이 달라진다.

3-1. 전역에서의 this

전역에서 this는 당연히 전역 객체를 가리킨다. 브라우저라면 window, 노드라면 global이다. 전역 변수로 선언한 x가 있다면 이는 window.x와 this.x가 동일한 참조를 가진다. 자바스크립트 엔진이 전역 변수 x를 전역 객체에 할당하고, this는 그 전역 객체를 가리키기 때문이다.

const x = 1;
window.x // 1
this.x // 1

3-2. 메서드에서의 this

메서드는 객체의 속성으로 할당하고 객체의 메서드로서 호출하는 함수를 말한다.

const obj = {
  x: 1,
  method: function () {
    return console.log(this);
  },
};

obj.method();

// { x: 1, method: [Function: method] }

메서드의 this는 점 앞의 객체를 가리킨다.

3-3. 함수에서의 this

일반 함수로 호출하는 경우에는 this가 지정되지 않고 전역 객체를 가리킨다.

function checkThis(text) {
  return console.log(text, " ", this);
}

checkThis("common func"); // common func   Window {window: Window, …}

이처럼 일반 함수에서 this 호출은 전역 객체가 바인딩되므로 주의해야 한다. method로서 선언하였다 하더라도 호출 자체를 일반 함수로 한다면 this는 객체를 가리키지 않는다.

3-4. 콜백 함수에서의 this

콜백 함수에서도 마찬가지로 일반 함수로 호출된 경우 this는 전역 객체를 가리킨다. 반면, 어떤 객체의 메서드 내에서 실행된다면 this는 해당 객체를 가리킨다.

setTimeout(func("callback func"), 300);
// callback func   Window {window: Window, …}

[1, 2, 3, 4, 5].forEach(func);
/*
1 ' ' Window {window: Window, …}
2 ' ' Window {window: Window, …}
3 ' ' Window {window: Window, …}
4 ' ' Window {window: Window, …}
5 ' ' Window {window: Window, …}
*/

document.body.innerHTML += ``;
document.body.querySelector("#a").addEventListener("click", function (e) {
  console.log(this);
});
//

3-5. 생성자 함수에서의 this

생성자 함수는 new 키워드를 통해 호출한 함수로, 새로운 인스턴스를 생성하며 this는 자기자신을 가리킨다.

new checkThis("me"); // me   checkThis {}

4. 메서드에서 일반 함수로

대강 this를 살펴봤으니 재현 코드의 문제점으로 돌아가 보자.

const tempClass = new TempClass();

const abc = (tempClass) => {
  const x = tempClass.sum;
  return x;
};

console.log(abc(tempClass)());
// TypeError: Cannot read properties of undefined (reading 'one')

오류가 발생한 이유는 메서드에서 일반 함수로 변경되었기 때문이다. abc 내부의 x는 tempClass.sum 참조만 하고 실행하지 않았기 때문에 TempClass에 대한 인스턴스와 관련된 실행 컨텍스트가 생성되지 않는다. 오히려 일반 함수 실행 컨텍스트가 생성되어 TempClass와의 연관성이 사라진다. 그렇기에 x로부터 실행되는 sum 메소드의 this는 아무것도 가리키지 않는 undefined가 된다. 따라서 명시적인 바인딩을 통해 this가 가리켜야 할 인스턴스를 알려주면 문제없이 실행된다.

class TempClass {
  constructor() {
    this.one = 1;
    this.two = 2;
  }

  sum() {
    console.log(this); // TempClass {one: 1, two: 2}
    return this.one + this.two;
  }
}

const tempClass = new TempClass();

const abc = (tempClass) => {
  const x = tempClass.sum.bind(tempClass);
  return x;
};

console.log(abc(tempClass)()); // 3

5. 결론

React의 Context API에서 인스턴스의 여러 메서드를 할당하고 명시적으로 바인딩한 이유를 다시 살펴봤다. 과제 코드에서는 필요한 곳에서 메서드를 실행하기 위해 참조만 변수에 할당했다. 그렇기 때문에 인스턴스와 연관성이 사라졌고 this는 갈 곳을 잃어 에러를 뱉어냈다. 아마 Context 내에서 메서드를 모두 실행한 후 결과만 value로 넘기는 식이었다면 명시적 바인드가 필요없었을 것이다.

참 this는 어렵다.

참고 코어 자바스크립트 - this ChatGPT

[TIL 21] - [React] 라이브러리 없이 SPA 구현 리팩토링

Sat, 08 Jul 2023 16:59:20 GMT

프리온보딩 챌린지 FE 7월 과제로 라이브러리 없이 SPA 라우터를 구현했다. 잘 동작하길래 만족했더니 함정이 숨어 있었다. 과제에서 제시한 대로만 구현하면 불필요한 마운트가 생긴다.

구현하면서 현재 Root에 있다면 렌더링하지 않은 About 라우트는 나타나지 않기를 기대했다. 숨겨진 진실(?)을 확인하니 많이 당황스러웠다.

피드백 내용과 제공해준 블로그 내용을 바탕으로 코드를 수정했다.

1. `Route` 내에서 렌더링 로직 실행

현재 url의 pathname과 요청한 path가 같으면 컴포넌트가 렌더링된다. 이 로직은 Route에서 실행되었다.

const Route = ({ path, component }: RouteProps) => {
  const pathname = useRouterState();
  const setPathname = useRouterDispatch();
  const [isCurrentPath, setIsCurrentPath] = useState(false);

  useEffect(() => {
    setIsCurrentPath(path === pathname ? true : false);

    const handlePopstate = () => {
      setPathname(window.location.pathname);
      return;
    };

    window.addEventListener("popstate", handlePopstate);

    return () => window.removeEventListener("popstate", handlePopstate);
  }, [pathname]);

  return isCurrentPath ? component : null;
};

얼핏 보면 현재 경로와 같을 때 component를 반환하고, 아닐 경우 null을 반환하니 잘 동작할 것 같다. 그러나 이는 Route의 하위 컴포넌트를 결정하는 것이고, 어쨌든 null도 객체이니 Route는 존재하는 컴포넌트로 마운트된다.

게다가 useEffect까지 사용하여 렌더링되라고 주문을 외웠으니 남지 않기를 바라는 게 욕심이었다.

내가 바라는 결과는 현재 경로의 Route를 제외한 나머지는 마운트하지 않는 것이다. 일단 로직부터 제거했다.

interface RouteProps {
  path: string;
  component: ReactElement;
}

const Route = (props: RouteProps) => {
  return <>{props.component};
};

이제 Route는 렌더링 페이지 컴포넌트를 담는 깡통이 되었다.

2. 제거한 로직 위치 변경

경로 처리 로직은 필요하니 어딘가에 넣어야 하는데 처음에는 routeContext인 Routes에서 처리하려고 했다. 실제로 코드를 작성해 실행해 봐도 아무런 탈 없이 잘 굴러갔다. 그러나 pathname의 상태관리를 위해 작성한 context에서 모든 로직을 처리해도 되나? 하는 의문점이 생겼다. 최근 관심사 분리에 대해 들었기 때문이었다. 선행한 분의 블로그에도 그런 이유로 처리 로직을 분리했다고 한다.

여기서 Router와 Route로 구현하라고 했었구나, 하는 작은 깨달음을 얻었다. 나는 그게 그거려니 생각해 대충 Routes와 Route로 나눴었다. 그러니 다시 중간 매개체를 고려해야 하는 문제가 발생했다.

routeContext는 Router로 수정하고, 로직을 담당하는 Routes를 새로 생성했다.

처리 방안을 모색했던 컴포넌트와 path를 검증하는 로직을 Routes에서 처리했다.

const Routes = ({ children }: RoutesProps) => {
  const pathname = useRouterState();
  const setPathname = useRouterDispatch();

  /* 추가 */
  const isCurrentPathComponent = (
    component: ReactElement<{ path: string }>
  ) => {
    return pathname === component.props.path;
  };
  /* **** */
  useEffect(() => {
    const handlePopstate = () => {
      setPathname(window.location.pathname);
      return;
    };

    window.addEventListener("popstate", handlePopstate);

    return () => window.removeEventListener("popstate", handlePopstate);
  }, [pathname]);

  return <>{children.find(isCurrentPathComponent) ?? };
};

children에서 url pathname과 컴포넌트의 path가 일치하는지 검증하는 함수 isCurrentPathComponent를 추가했다. 반환하는 컴포넌트는 children을 순회하면서 true인 값인 하위 Route만 렌더링한다. 추가로 잘못된 페이지 접근도 처리했다.

3. Route가 하나인 경우 처리

그러나 한 가지 미스가 또 있었다. 항상 Route가 여러 개 들어올 거라는 확신이었다. children의 타입을 ReactElemental[]로 선언했는데, 모종의 이유로 Route를 하나만 입력하면 에러가 발생한다. children이 배열인지 확인하고, 아닐 경우 배열로 바꿔주는 코드를 추가했다.

const childrenArray = Array.isArray(children) ? children : [children];

이제 불필요한 Route를 마운트하지 않으면서 원하는 대로 동작한다.

4. isValidElement ?

React에서 제공해주는 함수 중 isValidElement는 값이 React 엘리먼트인지 확인하여 boolean을 반환한다.

isValidElement isValidElement checks whether a value is a React element. isValidElement는 값이 React 엘리먼트인지 확인합니다.

선행하신 분의 글에 나와 있어서 이걸 왜 사용했나 고민했다. 없어도 잘 굴러가던데……. React 엘리먼트가 아닌 것이 들어오는 경우도 있나?

나의 경우 타입 선언 자체를 ReactElement로 선언하여 아무런 문제가 없는데, 만약 ReactNode로 선언한 경우 검증이 필요할 수 있다.

const isCurrentPathComponent = (component: ReactNode) => {
  if (!isValidElement(component)) {
    return false;
  }
  return pathname === component.props.path;
};

ReactNode는 다양한 속성으로 이루어져 있다.

type ReactNode =
  | ReactElement
  | string
  | number
  | Iterable
  | ReactPortal
  | boolean
  | null
  | undefined;

만약 isValidElement를 통과하지 못하면 저 중 어떠한 속성인지 TypeScript는 알지 못한다. 통과하면 저 속성 중 ReactElement이므로 props에 접근할 수 있다.

지금처럼 간단하고 확실한 경우에는 직접 타입과 제네릭을 선언해도 되지만, 더 복잡한 경우에는 아주 유용한 함수일 것 같다.

참고 React Router를 직접 만들어보는 과정