글 업로드 할 때 이미지 프리뷰를 보여주기위해서는 URL.createObjectURL vs FileReader.readAsDataURL 두 가지 방법을 활용할 수 있다. 이걸 비교해 보고자 한다

1. 비교하기

1-1. 데이터 형식

• URL.createObjectURL: 브라우저 메모리 내 객체를 참조하는 임시 blob URL 생성 ex) blob:https://example.com/550e8400...
  • 이 URL은 현재 브라우저 탭/세션 내에서만 유효, 새로고침하거나 탭 닫으면 사라짐
  • 장점: base64 변환이 필요 없어서 빠르고 메모리 효율적.
  • 단점: 외부 저장 불가. 서버로 보내거나 LocalStorage에 그대로 보관할 수 없음. (서버에 보내려면 원본 Blob/File을 직접 FormData로 append해서 보내야 함)
    • 주의: 사용 끝나면 URL.revokeObjectURL(url)로 직접 해제 필요(이후 예제 참고)
• FileReader.readAsDataURL: 파일 내용을 base64 문자열로 변환해 "data:..." 형식으로 생성 ex) data:image/jpeg;base64,/9j/4AAQSkZJRgAB...
  • 장점: 브라우저의 메모리 외부에서도 사용 가능. ⇒ 로컬 스토리지에 저장, 서버 전송, 다른 컨텍스트(다른 탭, 다른 브라우저)에서도 그대로 사용 가능
  • 단점: base64 인코딩이라 용량이 33% 정도 커지고 메모리 소모도 큼.

1-2. 시간

• URL.createObjectURL: 동기적으로 실행(즉시 실행)
• FileReader.readAsDataURL은 비동기적으로 실행(시간이 조금 지체된 후 실행)

1-3. 메모리

• URL.createObjectURL : 직접 revokeObjectURL로 해제 필요(또는 문서 종료 시 해제)
• FileReader.readAsDataURL : 결과가 긴 문자열이라(base64) Blob URL(createObjectURL)에 비해 메모리를 많이 잡아먹지만, 사용하지 않으면 자동으로 가비지 컬렉터에 의해 자동 제거

1-4. 지원

• 두 방식 모두 IE10+ 및 모던 브라우저 OK.

1-5. 결론

• 미리보기(Preview) 용도라면 createObjectURL이 가볍고 빠름. 단, 사용하지 않을 때 일일이 revokeObjectURL로 release시켜주어야 하는 번거로움이 있다.
• Base64(data URL) 은 “문자열이 필요할 때” 쓰면 좋음. (예: LocalStorage 임시 저장/복사-붙여넣기/서버가 Base64만 받을 때)
• 이미지 크기 커질수록 손해(33%↑)* 이고, 인코딩 CPU/메모리 비용도 들기 때문에 createObjectURL을 권장한다고 함. gpt왈

2. 예제 코드

URL.createObjectURL, URL.revokeObjectURL

import { useEffect, useRef, useState } from "react";

export default function ImagePreview() {
  const [previewUrl, setPreviewUrl] = useState<string | null>(null);

  const handleChangeImage = (e: React.ChangeEvent<HTMLInputElement>) => {
    const file = e.target.files?.[0];
    if (!file) return;

    // 새 URL 만들기 전에 이전 URL 해제
    setPreviewUrl((prev) => {
      if (prev) URL.revokeObjectURL(prev);
      return URL.createObjectURL(file);
    });
  };

  // 컴포넌트 언마운트 시 마지막 URL 해제
  useEffect(() => {
    return () => {
      if (previewUrl) URL.revokeObjectURL(previewUrl);
    };
  }, [previewUrl]);

  return (
    <>
      <input type="file" accept="image/*" onChange={handleChangeImage} />
      {previewUrl && (
        <img
          src={previewUrl}
          alt="preview"
          // 이미 로딩이 끝났다면 바로 해제하는 패턴도 가능(선택)
          onLoad={() => {
            // URL.revokeObjectURL(previewUrl); // 선택사항
          }}
        />
      )}
    </>
  );
}

FileReader.readAsDataURL

import { useState } from "react";

export default function ImagePreviewBase64() {
  const [previewDataUrl, setPreviewDataUrl] = useState<string | null>(null);

  const handleChangeImage = (e: React.ChangeEvent<HTMLInputElement>) => {
    const file = e.target.files?.[0];
    if (!file) return;

    const reader = new FileReader(); //파일 리더 객체 지정
    reader.readAsDataURL(file);//파일 객체를 읽어서 이해 가능한 문자열로 변경
    reader.onload = () => {
      // onload 시점에만 result가 채워짐(비동기)
      setPreviewDataUrl(reader.result as string);
    };
  };

  return (
    <>
      <input type="file" accept="image/*" onChange={handleChangeImage} />
      {previewDataUrl && <img src={previewDataUrl} alt="preview" />}
    </>
  );
}

개념

브라우저가 서버로부터 비어있는 뼈대 HTML을 받아온 후, 필요한 자바스크립트 번들을 다운로드하고 번들을 실행하여 동적으로 컨텐츠를 채우는 렌더링 방식

작동 방식

1. 브라우저가 서버에 빈 HTML과 JS 파일 요청
2. 브라우저가 JS 파일을 다운로드하고 실행
3. 실행된 JS가 HTML의 빈 공간을 채우며 화면을 생성

장점

1. 빠른 상호작용 서버에서 필요한 파일을 초기에 로드받은 후에는 동적으로 빠르게 렌더링이 가능함
2. 서버 부담 감소 페이지 렌더링 후에는 추가 서버 요청이 필요 없어 서버 부하가 적음

단점

1. 초기 렌더링 속도 느림 브라우저가 JS 파일을 모두 다운로드하고 실행해야 화면 표시가 가능하여 초기 렌더링이 느림
2. SEO 취약 JS로 생성된 콘텐츠는 검색 엔진 크롤러가 읽지 못할 가능성이 높음

2. SSR(Server-Side Rendering)이란?

개념

SSR은 서버에서 HTML 페이지를 완성한 뒤 클라이언트(브라우저)에 전달하는 렌더링 방식

작동 방식

1. 사용자가 브라우저에서 페이지 요청
2. 서버는 요청에 따라 HTML 페이지 생성
3. 생성된 HTML을 브라우저로 전송
4. 브라우저는 HTML을 즉시 화면에 렌더링

장점

1. 빠른 초기 렌더링 서버에서 완성된 HTML을 제공하여 사용자에게 첫 화면을 빠르게 표시 가능.

💡 SSR은 서버에서 페이지를 구성하는 시간은 CSR보다 더 걸리지만, 브라우저가 JavaScript를 다운로드하고 실행할 필요가 없어 사용자가 실제로 콘텐츠를 보게 되는 시점은 더 빠르다

1. SEO에 유리 검색 엔진 크롤러가 HTML을 쉽게 읽을 수 있어, 검색 결과 상위 노출 가능성이 높음

단점

1. 서버 부하 증가 모든 페이지 요청마다 서버가 HTML을 새로 만들어야 하기 때문
2. 복잡한 구현 서버와 클라이언트 로직의 분리 관리로 인한 개발과 유지보수의 복잡성 증가

🤔 Q. CSR은 왜 검색엔진에 불리하고 SSR은 왜 유리한가요?

CSR의 경우, 아래 이미지처럼 초기 HTML이 거의 비어있는 상태(div id="root")로 전달되고 JavaScript가 실행된 후에야 실제 콘텐츠가 생성되는데, 대부분의 검색엔진 크롤러는 이 JavaScript 실행을 기다리지 않고 빈 HTML만 읽고 지나가기 때문

반면 SSR은 서버에서 이미 모든 콘텐츠가 포함된 완성된 HTML을 제공하므로, 크롤러가 JavaScript 실행 없이도 모든 콘텐츠를 즉시 읽을 수 있어 검색 엔진 최적화에 유리함

3. SSR과 CSR 비교

4. 면접 질문과 예상 답변

Q. SSR과 CSR의 주요 차이점은?

A. SSR은 서버에서 완성된 HTML을 생성하여 제공하고, CSR은 브라우저가 JavaScript로 화면을 동적 생성합니다.

각각의 특징

• SSR: 초기 로딩 빠름, SEO 유리, 서버 부하 큼
• CSR: 동적 상호작용 빠름, 서버 부담 적음, SEO 취약

Q. 어떤 상황에서 각각을 사용해야 하나요?

SSR 적합

• 블로그, 쇼핑몰 등 검색엔진 최적화가 중요한 서비스
• 빠른 초기 로딩이 필수인 경우

CSR 적합

• 관리자 페이지처럼 상호작용이 많은 서비스
• 실시간 데이터 업데이트가 잦은 경우

프로그래머스 데브코스에서 진행한 2차 팀 프로젝트 회고를 진행해 보려 한다

처음 경험하는 규모의 프로젝트는 처음이기도 했고 2024년 마지막 프로젝트였기 때문에 더 욕심이 났다.

그리하여 우리 팀이 만든 서비스는 두둥 🔗깃허브 주소

서비스 소개

!O운완?O운완 서비스는 현대인의 건강한 라이프스타일을 위한 사진 기반 운동 인증 커뮤니티로, 사용자들에게 동기부여와 정보를 제공하는 것을 목표로 삼았다.

주요기능

• 4가지 주요 채널 제공 : 오운완 인증, 프로틴 추천, 식단 공유, 헬스장 리뷰
  • 게시글 작성으로 건강 및 운동 정보를 공유
  • 좋아요, 댓글, 팔로우 기능으로 활발한 커뮤니티 형성
• 운동 동기 부여 기능:
  • BMI 계산기
  • 운동 인증 캘린더 및 운동 달성도 그래프

프로젝트 명세서

주제: 제공되는 api를 이용한 회원 인증 기반 커뮤니티 기간: 2024.12.05 ~ 2024.12.23

기본 요구사항

• 사용자는 회원가입과 로그인을 할 수 있습니다.
• 사용자는 채널에 올라온 글을 볼 수 있습니다.
• 사용자는 가입자 목록을 볼 수 있습니다.
• 사용자는 가입자를 이름으로 검색을 할 수 있습니다.
• 사용자는 가입자의 정보를 볼 수 있습니다.
• 사용자는 포스트 혹은 가입자를 검색할 수 있습니다.
• 인증된 사용자는 자신의 정보를 변경할 수 있습니다.
• 인증된 사용자는 채널에 올라온 글을 볼 수 있습니다.
• 인증된 사용자는 채널에 포스트를 남길 수 있습니다.
• 인증된 사용자는 포스트를 좋아요 할 수 있습니다.
• 인증된 사용자는 포스트에 댓글을 남길 수 있습니다.
• 인증된 사용자는 자신의 알림 목록을 확인 할 수 있습니다.
• SPA 형태로 만들어주세요.
• 엉뚱한 페이지에 접속하면 404 페이지를 보여주세요.

보너스 요구사항

• 사용자는 현재 접속 중인 사용자를 볼 수 있습니다.
• 인증된 사용자는 다른 가입자에게 메시지를 보낼 수 있습니다.
• 인증된 사용자는 자신에게 온 메시지 목록을 확인 할 수 있습니다.
• 인증된 사용자는 특정 사용자와의 메시지 대화 내역을 확인 할 수 있습니다.
• 인증된 사용자는 프로필 이미지 변경
• 인증된 사용자는 포스트를 작성할 때 이미지를 첨부할 수 있습니다. 파일 업로드를 구현해보세요.
• 다크 모드를 적용해보세요.

📅 프로젝트 진행 과정

기획

주제 선정

주제는 요구사항에 맞춰서 팀원들이 각자 의견을 던지고 투표를 진행하였다

투표 결과 top3 주제들로 요구사항에 충족시킬 수 있는지 확인 후 특이사항을 점검하고 투표로 진행되었다

그 결과 최종적으로 내가 제안한 오운완이 선정됐다 🎉

🗣️ 오운완 제안 이유

• 운동인이라는 구체적인 타겟층을 설정하여 그들의 니즈(운동 성과 공유, 경험과 노하우 공유)에 효과적으로 대응할 수 있다

• 인스타그램이나 핀터레스트같은 사진 기반 커뮤니티 서비스를 구현하고자 했다

  ⇒ 운동인증이라는 주제는 시각적 콘텐츠와 어울린다

• 제공된 API를 활용해 주요 기능을 구현하는 데 있어 현실적인 접근이 가능하다

유저플로우

디자인에 들어가기 전 유저플로우를 작성했다

유저플로우를 작성함으로써 다음과 같은 이점을 얻을 수 있었다

• 서비스의 전체적인 흐름을 시각화하여 팀원들과 효과적으로 소통할 수 있었다
• 사용자 관점에서 서비스를 바라보며 불필요한 단계나 개선이 필요한 부분을 미리 파악할 수 있었다
• 기능 개발의 우선순위를 정하고 작업 범위를 명확히 할 수 있었다
• 인증/비인증 사용자의 접근 권한을 명확히 구분하여 보안 설계에 도움이 되었다

디자인

디자인은 피그마를 통해 진행되었다. 반응형 웹을 전제로 디자인을 진행했으며, 피그마에서 공통 컴포넌트들은 별도 분리해 관리하며 디자인 시스템을 효율적으로 구축하고자 했다. 이를 통해 디자인의 일관성을 유지하고 수정 사항 발생 시 빠른 대응이 가능했다.

• 메인 컬러로 포카리스웨트를 연상시키는 #3B6CB4를 선택했다. ⇒ 운동과 관련된 서비스의 정체성을 잘 표현할 수 있는 색상이라 생각했다.

• 폰트는 다국어 지원이 우수한 프리텐다드를 사용했다.

• 이미지가 주요 콘텐츠인 만큼, 불필요한 디자인 요소를 최소화하고 시각적 콘텐츠를 돋보이게 하는 미니멀한 디자인을 추구했다.

• 사용자의 집중도를 높이기 위해 게시물에는 최소한의 정보(프로필 이미지, 닉네임)만 표시하고, 호버 시 제목과 내용 일부를 보여주는 인터랙션으로 클릭을 유도했다.

• 디자인의 일관성을 위해 버튼과 같은 상호작용 요소에는 메인 컬러를 적용하여 시각적 통일감을 주었다.

기능명세서

프로젝트 초기에는 기능명세서를 어떻게 정리해야 할지 막막했지만, 여러 블로그 글을 참고하며 페이지별로 나누어 작성하는 방식을 선택했다. 그 결과 다음과 같은 이점이 있었다.

1. 기능 가시성 향상

• 각 페이지마다 필요한 기능을 한눈에 확인할 수 있어 중복 기능을 쉽게 식별할 수 있었다
• 구현해야 할 기능들이 명확히 정리되어 개발 방향이 분명해졌다

2. 효율적인 역할 분담

• 기능별로 나눠서 팀원들과의 역할 분담이 수월해졌다
• 각자 담당 기능이 명확히 정해지면서 책임감이 상승했다

3. 실시간 진행 상황 공유

• 진행 상황을 실시간으로 업데이트하여, 완료되지 않은 기능들을 파악하고 우선순위에 따라 작업을 조율할 수 있었다.
• 작업이 완료된 팀원들이 다른 팀원들을 도와주며 협업할 수 있었다. 🤔 다만 컴포넌트별로 분리가 되어 있지 않아서, 디자인 단계에서 중복된 컴포넌트가 많았는데도 개발 시에는 개별 컴포넌트로 나누어 작업하게 되었다. 초반에 중복되는 요소들은 한 명이 전담해서 진행했다면 더 효율적이지 않았을까 싶다!

💻 개발문화

1. 깃허브 이슈와 PR 활용

깃허브에서는 이슈와 PR 템플릿을 활용하여 일관된 형식을 유지할 수 있었다.

라벨을 통하여 작업 내용을 한눈에 파악할 수 있었고, 각 PR에서는 구현한 로직에 대한 간단한 설명을 포함하여, 다른 팀원들이 코드를 리뷰하고 이해하는데 도움이 되도록 했다.

2. 브랜치 관리

브랜치와 이슈를 연동하여 PR 머지 시 해당 이슈가 자동으로 closed 되도록 설정했다. 이를 통해 작업 진행 상황을 효율적으로 추적할 수 있었다.

브랜치 네이밍 규칙은 'dev_task_#issuenumber' 형식을 따랐다. (예: feat_header_#2)

각 팀원이 한 번에 1개의 태스크만 담당하도록 하여 코드 병합 과정에서 발생할 수 있는 문제를 사전에 방지할 수 있었다.

🔥 그럼에도 발생한 충돌… 원인은 개인 개발에 몰두하여 pull을 받지 않고 작업을 진행하는 경우가 있었기 때문.

이를 해결하기 위해 Zoom 채팅과 카카오톡 등 모든 연락망으로 PR과 머지 상황을 실시간 공유했고, 이를 통해 팀원들이 즉시 pull을 받아 충돌을 최소화하며 작업을 이어갈 수 있었다! 👍

👥 협업방식

• 슬랙을 통한 일일 스크럼: 매일 아침 팀원들과 컨디션을 공유하고 진행 상황을 점검했다
• 노션을 활용한 일정 관리: 프로젝트 전체 일정과 개인 일정을 공유하고 관리했다
• 깃허브 기반 협업: 이슈와 PR 활용했다
• 피그마를 통한 디자인 협업: 유저플로우와 디자인 작업을 실시간으로 공유하고 피드백을 주고받았다

💫 트러블슈팅 QA

개발시 지속적으로 테스트를 진행했다. 발견된 버그들은 즉시 수정하거나 노션에 기록하여 추후 해결할 수 있도록 했다. 이런 방식으로 모든 팀원이 버그 발견과 수정에 적극적으로 참여하여 서비스의 안정성을 높일 수 있었다.

테스트와 품질 관리를 위해 다음과 같은 방식으로 진행했다

• 실시간 버그 트래킹: 발견된 모든 오류사항을 즉시 기록하고 담당자를 지정했다
• 체계적인 이슈 관리: 각 버그에 대해 완료 여부를 체크리스트로 관리하여 진행 상황을 명확히 했다
• 우선순위 기반 해결: 사용자 경험에 직접적인 영향을 미치는 문제부터 우선적으로 해결했다

🔥 개발하는 시간보다 오류를 잡는 데 더 많은 시간을 할애했던 것 같다. 기능 구현이 끝났다고 생각했지만 QA를 진행할수록 계속해서 예상치 못한 오류들이 발견되었고, 이를 해결하기 위해 많은 시간과 노력을 들였다. 다음 프로젝트에서는 QA 시간을 충분히 확보해야겠다.

⌛️마치며

이번 프로젝트의 1차 스프린트에서는 보너스 요구사항을 제외한 모든 기능 구현을 목표로 삼고, 수업 시간뿐 아니라 주말과 저녁 시간까지 팀원들이 함께 슬랙 허들에 모여 개발에 매진했다. 팀원 모두 적극적인 참여로 기한 내에 보너스 요구사항까지 도전할 수 있었고, 결과적으로 전체 21개 중 메시지 기능을 제외한 18개의 요구사항을 성공적으로 구현했다!

팀내 에이스 분들(양대산맥)이 화면을 공유하며 어려운 부분을 설명해 주신 덕에 수업 시간에 완벽히 이해하지 못했던 axios나 zustand와 같은 기술들도 프로젝트에서 활용해 볼 수 있었다.

개발 과정에 집중하다보니 나머지 버그 수정과 QA에 충분히 시간을 할애하지 못한 점이 아쉽지만, 3주라는 짧은 시간동안 정말 열심히 했다는 점에서 만족한다! 중간에 어려운 부분도 있었지만 팀원들의 응원 덕분에 프로젝트를 끝까지 마무리할 수 있었다. 굿굿 👍

📚 오늘 한 일 팔로우 기능 추가 메인페이지 디자인 및 퍼블리싱

💬 마치며 스와이퍼 커스텀 만만치 않았다 리액트에선 css 모듈 불러오는 오류가 계속 나서 link로 넣었다.

24.12.17

📚 오늘 한 일 메인 페이지 bmi 계산기 추가 헤더 반응형 구현

24.12.18

📚 오늘 한 일 메인 페이지 데이터 필터링 메인 페이지 로딩창 추가 그외 자잘한 로직, css 수정

💬 마치며 슬슬 기능은 마무리돼서 다른 분들 코드 보면서 자잘하게 수정했다. 중복되는 코드들이 보였는데 어떻게 손을 대야 할지...

24.12.19

📚 오늘 한 일 사이드바 상태 로컬스토리지 저장 자잘한 스타일, 로직 수정

💬 마치며 무한 스크롤 적용해야 하는 페이지가 하나 남아서 리액트쿼리를 공부해 보기로 했다

24.12.20

📚 오늘 한 일 무한스크롤 구현 - intersection observer 자잘한 스타일, 오류 수정 알림창 css 수정

💬 마치며 별도의 라이브러리 설치가 필요없는 intersection로 무한스크롤을 구현했다. 사실 팀원분 코드를 가져다 썼다고 보는 게 맞음. 다음엔 혼자서 해 봐야겠다.

24.12.21

📚 오늘 한 일 리액트 강의 - todolist 만들기

24.12.22

📚 오늘 한 일 아는 만큼 보이는 프런트엔드 개발 도서 읽기

📚 오늘 한 일

• 프로젝트 디자인작업 수정
• 프로젝트 맡은 부분 퍼블리싱

💬 마치며 고려해야 할 부분이 추가적으로 계속 생긴다. 그래도 프로젝트 기간이 짧다보니 애자일하게 가는 게 맞을 것 같다.

24.12.08

📚 오늘 한 일

• 프로젝트 디자인작업 수정
• 프로젝트 맡은 부분 퍼블리싱 마무리
• 기능명세서 작성 페이지별 기능을 정리하고 우선순위를 정리했다 비고엔 고려사항을 적었다

💬 마치며 기능명세서를 작성하니 구현해야 할 부분들이 한눈에 들어와서 일정 조율이 수월해졌다

24.12.09

📚 오늘 한 일

• 데브코스 역량평가(알고리즘, 과제테스트)진행(5h)

• 특강 진행: 올바르게 프론트엔드 내 지식으로 만들기

  강사: 김태희 강사님 - 당근 엔지니어 일시: 2024년 12월 9일(월) 15:00-19:00(4시간)

• 기능명세서를 기반으로 팀원들과 일정조율 1차, 2차로 나누어 개발을 진행하기로 하고 기능별로 담당자를 지정했다

💬 마치며

현재의 기술이나 라이브러리가 등장하게 된 배경과 발전 과정을 이해하면 앞으로의 발전 방향을 예측할 수 있고, 새로운 기술을 더 효과적으로 학습(가성비 학습)할 수 있다고 하셨다 그냥 기술을 사용하는 것이 아닌 "이 기술이 왜 필요했을까?", "어떤 문제를 해결하려고 했을까?"와 같은 질문을 자주 던지며 공부해야겠다

+) 강사님 밴드 하신다고 했는데 내가 너무 되고 싶은 모습이었다... 직장인밴드

24.12.10

📚 오늘 한 일

• 프로젝트 사이드바 토글 기능 구현
• 사이드바 현재 path에 따라 채널리스트 활성화 처리
• 자잘한 ui 수정
• 게시판 페이지 디자인

💬 마치며 깃허브 이슈를 이용하니 팀원들이 작업 중인 부분을 확인할 수 있어서 충돌을 (그나마) 피할 수 있었다. 프로젝트를 하면서 사이드바 토글 상태를 zustand로 관리하게 됐다. 수업 시간에 애매하게 이해했는데 직접 필요를 느끼고 하니 zustand 사용법을 확실히 익힐 수 있었다

24.12.11

📚 오늘 한 일

• 댓글 불러오기, 삭제, 추가 기능 구현

💬 마치며 전역 폰트 설정을 하지 않은 상태로 진행했는데 맥, 윈도우 환경에 따라 기본 폰트가 다르기 때문에 깨져 보일 수도 있다는 것을 알게 됐다. 댓글 기능 구현을 하는 중인데 api가 익숙하지 않아서 시간을 엄청 잡아먹었다. 내일 퍼블리싱 된 곳에 옮겨서 마무리해야지

24.12.12

📚 오늘 한 일

• 퍼블리싱 완료된 댓글창에 기능 입히기
• 좋아요 기능 구현 중
• git complete 해결해 봤다

💬 마치며 기능 구현 후에도 자잘하게 손댈 게 많았다 게시글 불러오면서 댓글수도 같이 불러오기 때문에 댓글 입력시 댓글수가 늘어나지 않아서 상태 관리를 이용한다거나,, 회원만 댓글 입력 가능하게 표시를 해 줘야 되는데 이거 내일 추가해야겠다 좋아요도 한 명이 여러번 하지 못하게 막아야 할 것 같다

24.12.13

📚 오늘 한 일

• 좋아요 기능 완료

💬 마치며 좋아요 기능이 생각보다 어려워서 한참 잡고 있었다 코드는 엉망이겠지만... 일단 현재까지 기능 이상 없음 뿌듯해 한 컴포넌트에서 댓글, 좋아요 로직을 모두 작성하다보니 엄청 길어졌는데 이것도 정리해 봐야겠다

24.12.14

📚 오늘 한 일

• 로딩창 추가

💬 마치며

• 로딩창 은근 생각할 게 많았다. 로딩 화면은 어디에 띄워야 하는가, 데이터 로딩 중인 곳에만 띄웠을 때 css 처리는?
• 레이아웃 파일에서 띄우고 싶었는데 일단 css 이슈로... 데이터 로딩이 필요한 각 컴포넌트에서 불러올 수 있게 처리했다

24.12.15

📚 오늘 한 일

• 사이드바, 유저모달, 마이페이지 ui 수정

💬 마치며 아르바이트 때문에 css 위주로 손봤다 폰트 사이즈 날잡고 전체적으로 수정해야겠다

프로젝트를 본격적으로 시작하는 첫날

오늘 한 것

• 플로우차트
• 디자인
• 디자인리뷰
• 퍼블리싱 역할분배

수정할 부분은 많지만 일단 이렇게 하는 것만 종일 걸렸다 아직 완전하진 않지만 조금씩 의견이 좁혀지고 있는 것 같음! 이번 프로젝트로 팀원들 보두 각자 부족한 부분을 채울 수 있었으면 좋겠다.(나포함)

• JSON Server를 활용 API 통신
  • JSON Server 라이브러리 설치 및 설정
  • db.json 파일 생성하여 더미 데이터 구성
  • GET, POST, PUT, DELETE 메서드 테스트
• Fetch API를 사용한 데이터 통신
  • fetch 함수를 통한 HTTP 요청 구현
  • async/await를 활용한 비동기 처리
  • try-catch 문으로 에러 핸들링
  • 커스텀 훅으로 디벨롭
    • API 호출 로직을 커스텀 훅으로 분리
• TMDB API를 활용한 영화 데이터 통신 실습
• React Router
• JWT 인증 로그인 로그아웃(복습…)
• 2차 프로젝트 설명(회원 인증 기반 커뮤니티)

💬 마치며

JWT 로그인 로그아웃 기능이 이해가 잘 안 된다… 손이 바빴던 하루

프로젝트 시작인데 1차에 비해 규모가 배로 커진 느낌이라 기한내에 끝낼 수 있을까 의문이지만…

해피크리스마스를 위해 1팀 파이팅~!

1. 전역 상태 관리 Context API, Redux, zustand

• 전역 상태 관리를 활용한 카운터 앱 구현
  • 전역 상태로 카운터 값 관리하기
  • Context API: 메모리 최적화를 위한 상태와 함수 분리
  • zustand(디벨롭): 로그아웃시 reset 함수 호출
• Context 중첩
  • Auth Context 생성 및 설정
  • isLogin 상태값으로 조건부 렌더링한 카운터 앱 구현

1. API와 HTTP 통신
   • fetch, async/await를 활용한 비동기 처리
   • axios 라이브러리 사용

• TMDB API 과제
  • TMDB API 회원가입 및 인증키 발급
  • API 사용 가이드 학습
  • 과제: 영화 데이터를 활용한 리스트 페이지 구현

💬 마치며

Context API를 사용하면서 Context를 중첩해서 적용할 수 있다는 것을 알게 되었다. 권한에 따라 컴포넌트를 보여주는 인증 기반 서비스에 적용할 수 있다는 점을 배웠다. 전역 상태 관리가 헷갈려서 오늘은 Context API와 Zustand를 다시 학습했다. 여전히 헷갈리지만 조금은 정리된 것 같다...(아마도) Redux는 내일 다시 봐야지. 😭 우선은 프로젝트에서 사용하기로 한 Zustand 한 놈에게 집중해야겠다.

1. useEffect

• 함수형 컴포넌트의 생명주기를 관리하는 React Hook
• 컴포넌트의 마운트, 업데이트, 언마운트 시점에 특정 작업 수행
• 실습: Todo 리스트에서 로컬스토리지를 활용한 데이터 영속성 구현

2. 메모이제이션

• 불필요한 리렌더링을 방지

  • React.memo(): 컴포넌트 자체를 메모이제이션
  • useCallback(): 함수를 메모이제이션
  • useMemo(): 계산값을 메모이제이션

  최적화 적용 순서

  1. 컴포넌트 메모이제이션 (React.memo)
  2. 참조형 props 메모이제이션 (useCallback, useMemo)
  • 실습: Todo 리스트 컴포넌트 최적화 구현

3. 전역상태관리

• Context API를 통한 전역 상태 관리
  • 전역 상태를 여러 컴포넌트에서 공유할 수 있음
  • 불필요한 props drilling 방지

4. useId

• 서버사이드 렌더링 환경에서도 안정적인 고유 ID 생성
• 접근성 향상을 위한 라벨-폼 요소 연결에 활용
• 실습: Todo 리스트의 체크박스-라벨 연결에 useId 활용

💬 마치며

useEffect, 메모이제이션 응용 연습이 필요할 것 같다. 뭔가 사용해 보려고 하면 감이 안 잡힘... 포스팅은 머리에서 정리가 되는대로 해봐야지 ^.^

useReducer (별도 포스팅 예정)

• useReducer 예제 복습
• 당일 과제 TODO 만들기(등록, 추가, 삭제)

💬 마치며

TODO 과제 회고

id 값을 설정할 때 초기에는 배열의 마지막 인덱스를 기준으로 id를 설정했는데, 배열 변경이 일어날 경우 예상치 못한 충돌이나 변경 문제가 발생할 가능성이 있었다. 그래서 useRef를 활용해 id 값을 관리하는 방식으로 변경

기존 코드

// 마지막 배열 인덱스 번호로 id 설정
 const lastIndex = todos[todos.length - 1].id + 1;

변경 코드

 //id
  const idRef = useRef(0);

  // 투두리스트 추가 함수
  const addTodo = (value: string) => {
    if (value.trim() === "") {
      alert("내용을 입력해 주세요");
      inputRef.current?.focus();
    } else
      setTodos((todos) => [
        ...todos,
        { id: idRef.current++, content: value, completed: false },
      ]);
    setInput("");
    inputRef.current?.focus();
  };

분명 더 좋은 코드가 있겠지만... 이번 과제를 통해 useRef가 DOM 조작 외에도 다양한 상황에서 활용될 수 있다는 것을 알게 됐다

array의 각 element 중 divisor로 나누어 떨어지는 값을 오름차순으로 정렬한 배열을 반환하는 함수, solution을 작성해주세요.

divisor로 나누어 떨어지는 element가 하나도 없다면 배열에 -1을 담아 반환하세요.

제한사항

• arr은 자연수를 담은 배열입니다.
• 정수 i, j에 대해 i ≠ j 이면 arr[i] ≠ arr[j] 입니다.
• divisor는 자연수입니다.
• array는 길이 1 이상인 배열입니다.

입출력 예

입출력 예 설명

입출력 예#1

arr의 원소 중 5로 나누어 떨어지는 원소는 5와 10입니다. 따라서 [5, 10]을 리턴합니다.

입출력 예#2

arr의 모든 원소는 1으로 나누어 떨어집니다. 원소를 오름차순으로 정렬해 [1, 2, 3, 36]을 리턴합니다.

입출력 예#3

3, 2, 6은 10으로 나누어 떨어지지 않습니다. 나누어 떨어지는 원소가 없으므로 [-1]을 리턴합니다.

🥔 내 코드

1차

const solution = (arr, divisor) => {
  const result = arr.filter((num) => num % divisor === 0).sort((a, b) => a - b);
  if (!result[0]) return [-1];
  return result;
};

2차

const solution = (arr, divisor) => {
    const result = arr.filter((num)=> num % divisor === 0).sort((a, b) => a - b)
    return result[0] ? result : [- 1]
    }

✅ 풀이 과정

1. filter로 조건에 맞는 요소 필터링: arr.filter((num) => num % divisor === 0)
2. sort로 배열 오름차순 정렬: sort((a, b) => a - b)
3. 빈 배열 처리: 삼항 연산자(result[0] ? result : [-1]) 사용

• result[0]이 truthy면 result 반환, falsy면 [-1] 반환
• 빈 배열의 첫 요소는 undefined로, falsy 값

💡 다른 사람의 코드

function solution(arr, divisor) {
    var answer = arr.filter(v => v%divisor == 0);
    return answer.length == 0 ? [-1] : answer.sort((a,b) => a-b);
}

💬 마치며

1차 방식대로 풀었다가 다른 분의 풀이를 보고 2차 삼항연산자를 이용해서 값을 리턴하도록 했다

삼항연산자 꽤나 유용하게 쓰이는 것 같다

문제 설명

이 문제에는 표준 입력으로 두 개의 정수 n과 m이 주어집니다.

별(*) 문자를 이용해 가로의 길이가 n, 세로의 길이가 m인 직사각형 형태를 출력해보세요.

제한 조건

• n과 m은 각각 1000 이하인 자연수입니다.

예시

입력

5 3

출력

*****
*****
*****

🥔 내 코드

process.stdin.setEncoding('utf8');
process.stdin.on('data', data => {
    const n = data.split(" ");
    const a = Number(n[0]), b = Number(n[1]);

    let rectangle = "";
    for (let i = 0; i < b; i++) {
        rectangle += "*".repeat(a) + "\n"; // 가로 길이만큼 별 반복 후 줄바꿈
    }
    console.log(rectangle)
});

✅ 풀이 과정

1. rectangle 빈 변수 선언
2. for문 이용해서 가로 길이 b만큼 반복
3. 세로는 repeat(a)로 반복 후 “\n”으로 줄바꿈

💡 다른 사람의 코드

process.stdin.setEncoding('utf8');
process.stdin.on('data', data => {
    const n = data.split(" ");
    const a = Number(n[0]), b = Number(n[1]);
    console.log((('*').repeat(a)+`\n`).repeat(b))
});

💬 마치며

오… repeat() 두 번 사용하는 방법도 있구나

Q1: Virtual DOM이란 무엇인가요?

A: Virtual DOM은 실제 DOM을 추상화한 가벼운 복사본으로, 메모리에 객체 형태로 존재합니다. 변경 사항이 발생했을 때 실제 DOM에 직접 반영하지 않고, Virtual DOM에서 먼저 처리한 후 필요한 부분만 실제 DOM에 업데이트하여 효율적인 렌더링을 가능하게 합니다.

Q2: Virtual DOM을 사용하는 이유는 무엇인가요?

A: DOM을 직접 조작하면 브라우저 렌더링이 빈번하게 발생하여 성능이 저하될 수 있습니다. Virtual DOM을 사용하면 실제 DOM 조작을 최소화하여 성능을 개선할 수 있습니다.

Q3: Virtual DOM이 항상 더 나은 성능을 보장하나요?

A: 반드시 그렇지는 않습니다. Virtual DOM을 생성하고 비교하는 과정에서도 연산 비용이 발생하기 때문입니다. 상황에 따라 성능 차이가 있을 수 있습니다.

특징

• 빌드 도구가 이미지를 최적화하고 관리함
• 사용하지 않는 이미지는 최종 번들에 포함되지 않는 트리쉐이킹 적용
• 빌드 시 이미지 이름이 해시값이 포함된 새로운 파일명으로 변환
• 임포트(import)를 사용하여 이미지 추가

에셋 폴더 사용법

1) 이미지 임포트 및 렌더링

import tree from "./assets/images/tree.jpg";

export default function App() {
  return (
    <>
      {/* 이미지 렌더링 */}
      <img src={tree} alt="tree" />
    </>
  );
}

• 장점: 빌드 도구가 경로를 자동으로 관리하고, 이미지 최적화 및 캐싱 처리
• 결과: 개발 모드에서 'tree.jpg'였던 경로가 'assets/tree.123abc.jpg'처럼 최적화된 경로로 변경

⚠️ 주의: img src에 직접 경로 입력 시 빌드 후 npm run preview 로 확인시 이미지 깨짐 <img src="../src/assets/images/tree.jpg" alt="" />

• JSX는 JavaScript로 상대 경로 파싱 불가
• 해결: import로 이미지 불러옴

✅ 빌드와 프리뷰

npm run build 명령어로 프로젝트를 빌드하면 최적화된 배포 파일 생성

npm run preview 명령어로 빌드된 파일을 로컬에서 미리 확인 가능

개발 모드와 빌드/프리뷰 모드의 차이

• 개발 모드: index.html 직접 사용
• 프리뷰 모드: dist 폴더의 최적화된 index.html 사용
• 프리뷰는 실제 배포 환경과 유사한 조건에서 테스트 가능

2) 백그라운드 이미지로 사용

<div
  className="w-60 h-60"
  style={{ backgroundImage: `url(${tree})` }}
></div>;

4) 이미지 관리 파일 생성 💡

🤔 이미지가 100개가 되면 코드가 너무 지저분해지지 않을까?

이미지 개별 임포트가 번거롭다면 이미지 관리 파일로 한 곳에서 관리하여 코드를 깔끔하게 유지할 수 있음

예시: 이미지 관리 파일 생성

assets/images/images.ts

import tree from "./tree.jpg";
import flower from "./flower.jpg";

export const images = {
  tree,
  flower,
};

사용법

import { images } from "./assets/images/images";

export default function App() {
  return (
    <>
      <img src={images.tree} alt="tree" />
      <img src={images.flower} alt="flower" />
    </>
  );
}

2. 퍼블릭 폴더

특징

• 빌드 도구가 관여하지 않고 이미지를 있는 그대로 복사함
• 모든 파일이 최종 번들에 포함되며, 사용하지 않아도 번들 크기에 영향을 줌
• 파일 이름이 그대로 유지되며, 절대 경로로 접근 필요
• 정적 자산(예: 파비콘, robots.txt 등) 관리에 적합

퍼블릭 폴더 사용법

1) 이미지 렌더링

export default function App() {
  return (
    <>
      <img src="/tree_p.jpg" alt="tree" />
    </>
  );
}

• 절대 경로(/)를 사용해야 이미지가 올바르게 표시됨
• 빌드 후에도 경로가 변하지 않음

2) 백그라운드 이미지로 사용

<div
  className="w-60 h-60"
  style={{ backgroundImage: "url('/tree_p.jpg')" }}
></div>;

3. 에셋 폴더와 퍼블릭 폴더 비교

4. CSS 이미지 사용

CSS 파일에서 이미지를 사용할 때는 경로 작성

.bg {
  background-image: url("../assets/images/tree.jpg");
}

출처: 수코딩

비제어 컨트롤러란?

비제어 컨트롤러는 DOM 요소에 직접 접근하여 값을 관리하는 방식으로, 실시간 값 변화 감지 불가

useRef를 사용해 DOM 요소 참조

useRef란?

React에서 제공하는 Hook으로, 값을 보관하고 관리할 수 있는 저장소

주요 특징:

• 컴포넌트가 리렌더링되어도 동일한 참조값 유지
• 값이 변경되어도 컴포넌트가 리렌더링되지 않음
• DOM 요소에 직접 접근할 때 사용되며, current 프로퍼티를 통해 값을 안전하게 관리

🤔 DOM 조작에 querySelector 대신 useRef를 사용하는 이유 querySelector는 실제 DOM을 직접 조작하여 React의 가상 DOM 시스템과 충돌 가능 컴포넌트가 리렌더링될 때마다 참조가 깨질 수 있고, React의 단방향 데이터 흐름을 방해할 수 있음 ❌ React에서도 직접적인 DOM 조작을 권장하지 않음

예시코드

import { useRef } from "react";

export default function App() {
  const inputRef = useRef<HTMLInputElement | null>(null);

  const handleSubmit = () => {
    console.log(inputRef.current?.value); // input 값 가져오기
  };

  return (
    <>
      <input type="text" ref={inputRef} placeholder="Enter your name" />
      <button onClick={handleSubmit}>Submit</button>
    </>
  );
}

useRef와 DOM 접근

useRef로 생성된 객체는 current 프로퍼티를 통해 DOM 요소에 접근 가능

이를 통해 값이나 메서드를 호출 가능

console.log(inputRef.current?.value); // input의 값
inputRef.current?.focus(); // input에 포커스

폼 데이터

useRef를 여러 개 사용하여 폼 입력값 가져오기 가능

예제: 다중 입력값 처리

import { useRef } from "react";

export default function App() {
  const idRef = useRef<HTMLInputElement | null>(null); //ref 객체
  const pwRef = useRef<HTMLInputElement | null>(null);

  const handleSubmit = (e: React.FormEvent<HTMLFormElement>) => {
    e.preventDefault();
    console.log("ID:", idRef.current?.value);
    console.log("Password:", pwRef.current?.value);
  };

  return (
    <form onSubmit={handleSubmit}>
      <input type="text" ref={idRef} placeholder="아이디 입력" />
      <input type="password" ref={pwRef} placeholder="비밀번호  입력" />
      <button type="submit">로그인</button>
    </form>
  );
}

라디오 버튼과 체크박스 처리

라디오 버튼

useRef와 배열을 활용해 선택된 라디오 버튼의 값을 가져옴

라디오 버튼 처리 시 필요한 특별 처리:

• 배열로 참조 관리 (useRef<HTMLInputElement[]>([]))
• 각 라디오 버튼에 ref 콜백 함수로 배열에 요소 할당
• find() 메서드로 선택된 라디오 버튼 탐색

예시 코드:

const radioRef = useRef<HTMLInputElement[]>([]);

// 선택된 라디오 버튼 찾기
const selectedRadio = radioRef.current.find((radio) => radio.checked);
console.log(selectedRadio?.value);

// JSX에서 ref 설정
<input
  type="radio"
  ref={(el) => {
    if (el) radioRef.current[0] = el;
  }}
  name="gender"
  value="female"
  defaultChecked
/>
<input
  type="radio"
  ref={(el) => {
    if (el) radioRef.current[1] = el;
  }}
  name="gender"
  value="male"
/>

체크박스

checked 속성으로 체크 여부 확인

const checkboxRef = useRef<HTMLInputElement | null>(null);

console.log("Checked:", checkboxRef.current?.checked);

제어 컨트롤러 vs 비제어 컨트롤러

출처: 수코딩

1. 일반 변수 선언 (화면 렌더링에 영향 없음)

• let, const, var로 선언된 변수들은 리액트가 변화 추적 불가

2. 상태 변수 선언 (화면 렌더링에 영향 있음)

• useState와 같은 리액트 훅으로 선언
• 상태 변경 시 화면 자동 리렌더링

2. useState: 제어 컨트롤러 상태 관리

React에서 상태를 사용해 폼 요소나 화면 UI를 제어 컨트롤러 방식으로 관리 가능

제어 컨트롤러란?

• 제어 컨트롤러는 React 상태를 사용해 폼 요소나 UI를 실시간으로 제어하는 방식임

useState란?

• React 16.8에 도입된 훅(hook)
• 상태와 상태를 변경하는 함수를 배열로 반환

기본 문법

// 비구조화할당
const [state, setState] = useState(초기값);

• state: 현재 상태 값
• setState: 상태 값을 변경하는 함수
• 초기값: 상태의 초기값

3. useState 사용 예제

상태 관리로 화면 렌더링 반영

import { useState } from "react";

export default function App() {
  const [count, setCount] = useState(0);

  const increment = () => {
    setCount(count + 1); //값 전달 시 count의 최신값으로 설정
  };

  return (
    <div>
      <h1>count: {count}</h1>
      <button onClick={increment}>증가</button>
    </div>
  );
}

✅ 관례

• 상태 이름이 count면 업데이트 함수는 setCount로 작명
• 예: isVisible → setIsVisible, userName → setUserName

4. setState의 두 가지 사용 방식

1. 값 전달 방식

setCount(count + 1); //값 전달 시 count의 최신값으로 설정

• 이전 상태를 참조하지 않을 때 사용

2. 콜백 함수 방식 setState((현재상태) ⇒ 값)

setCount((count) => count + 1); //콜백함수 반환값이 count의 최신값으로 설정

• 이전 상태를 참조해야 할 때 사용

3. 두 방식 차이점

값 전달 방식과 콜백 함수 방식의 주요 차이점은 상태 업데이트의 동작 방식에 있음

예시: 3번의 상태 업데이트 시도

const increment = () => {
  setCount(count + 1);
  setCount(count + 1);
  setCount(count + 1);
};

count는 1만 증가함. 각 setCount가 동일한 count 값을 참조하기 때문(비동기)

하지만 콜백 함수 사용 시:

const increment = () => {
  setCount(prev => prev + 1);
  setCount(prev => prev + 1);
  setCount(prev => prev + 1);
};

count가 3씩 증가함. 각 콜백이 이전 상태의 최신값을 참조하여 업데이트하기 때문

5. 리액트에서의 불변성

React는 불변성을 기반으로 상태 변화를 감지

✅ 즉, 상태를 직접 변경하지 않고 새로운 상태를 생성해야 함

배열 상태 예제

const [students, setStudents] = useState(["james", "john"]);

const addStudent = () => {
  // ❌ 잘못된 방식 (원본 수정)
  // students.push("smith");
  // setStudents(students);

  // ✅ 올바른 방식 (새 배열 생성)
  setStudents((prevStudents) => [...prevStudents, "smith"]);
};

💡 올바른 방식: spread 연산자(...), map(), filter()를 사용해 새로운 상태를 생성

6. 제네릭 타입으로 상태 관리

타입스크립트와 useState

interface User {
  name: string;
  age: number;
  gender?: string; // 선택적(optional) 속성
}

const [user, setUser] = useState<User>({ name: "john", age: 20 });

// gender는 선택적 속성으로 추가 가능
const updateUser = () => {
  setUser(prev => ({ ...prev, gender: "male" }));
};

7. 폼 요소 상태 관리

input[type="text"]

const [input, setInput] = useState("");

const handleChange = (e: React.ChangeEvent<HTMLInputElement>) => {
  setInput(e.target.value);
};

return <input type="text" value={input} onChange={handleChange} />;

// 혹은 onChange 내에서 직접 호출
<input type="text" value={input} onChange={(e) => setInput(e.target.value)} />

💡 value와 onChange는 폼 요소 제어 시 세트로 사용

• value 속성 없으면 리셋 기능 추가해도 인풋 내부 값 제어 불가
• 폼 요소 완전 제어를 위해 value와 onChange 함께 사용 필수

input[type='date']

// date input
const [dateInput, setDateInput] = useState("");
<input type="date" value={dateInput} onChange={(e) => setDateInput(e.target.value)} />

textarea

// textarea
const [textInput, setTextInput] = useState("초기값");
<textarea value={textInput} onChange={(e) => setTextInput(e.target.value)} />

체크박스

const [checked, setChecked] = useState(false);
<input type="checkbox" checked={checked} onChange={() => setChecked(!checked)} />;

radio

초기값 설정 필수 ⇒ defaultChecked 설정

const [radioValue, setRadioValue] = useState("male");
      <div>
        <input
          type="radio"
          name="gender"
          className="border border-slate-500"
          value={"male"}
          defaultChecked
          onChange={() => setRadioValue("male")}
        />
        male
      </div>
      <div>
        <input
          type="radio"
          name="gender"
          className="border border-slate-500"
          value={"female"}
          onChange={() => setRadioValue("female")}
        />
        female
      </div>

셀렉트 박스

select 요소 초기값 지정 시 defaultValue 속성 사용 가능

value와 defaultValue 차이점

• value: 컴포넌트가 제어되는 상태로, React에 의해 값이 관리됨
• defaultValue: 컴포넌트의 초기값만 설정하고 이후 React의 제어를 받지 않음

const [selected, setSelected] = useState("apple");
<select value={selected} onChange={(e) => setSelected(e.target.value)}>
  <option value="apple">Apple</option>
  <option value="banana">Banana</option>
</select>;

출처: 수코딩

리액트 이미지 렌더링 useState useRef

💬 마치며

주말 과제 한다고 포스팅 할 글 정리를 못해서 주말 이용해서 해 봐야겠다... 요즘 매일 새로운 걸 궤짝으로 배우는데 소화할 수 있는 양은 소주잔 정도라(술 안 좋아함) 수업 없는 주말이 소중해졌다. 폼 요소 제어하는 부분도 헷갈려서 다시 봐야겠다

유튜브 영상 찾아보면서도 이해가 안 됐던 리액트 훅 진도를 나갔는데 실습하면서 좀 감이 잡힌 것 같다. 실습 좋긴 한데 시간내에 못끝내면 좀 화나. 나만 느려. 주말 과제로 내주신 것도 타입 에러 뜨긴 하는데 일단 구현은 했다... 돌아가긴 함. 내일 다시 봐야지

프롭스 드릴링 리액트 조건부 렌더링 리액트 반복 렌더링 재사용 가능한 컴포넌트 Tailwind Css

💬 마치며

오늘 실습이 많았다 확실히 개념만 배우는 것보다 내 눈에 UI가 보이는 게 재미있는 것 같다. 피그마 디자인을 컴포넌트로 만들어 보고 props를 구조분해할당과 나머지매개변수를 이용해서 재사용 가능한 컴포넌트로 리팩토링하는 과정을 보여주셨는데, 나름 props 하나 전달했다고 재사용 가능한 컴포넌트 완성! 이러고 있었는데 역시나 쉬운 건 없었음. 고려할 점이 백만개(아님)였다. 많은 경우의수를 생각하면서 개발해야 되는구나 느꼈다.

+) 부모님 결혼기념일이라 수업 마치고 식당 노래방 풀코스로 즐기고 왔다...(공부 못했단소리)

map 메서드는 배열의 요소를 순회하며 새로운 배열을 반환하는 역할을 함

리액트에서 자주 사용되는 이유는 JSX 요소를 배열 데이터로부터 생성하는 작업에 매우 적합하기 때문임

map 메서드의 특징

1. 콜백 함수 실행: 배열의 각 요소를 순회하며 콜백 함수 실행
2. 새로운 배열 생성: 콜백 함수의 반환값으로 구성된 새로운 배열 생성
3. 원본 배열 불변: 원본 배열 유지

리액트에서의 활용

리액트에서는 map 메서드를 사용해 배열 데이터를 JSX 요소로 변환하여 반복 렌더링이 가능함

💡 표현식({})에서 객체는 직접 출력이 불가능하며, JSON.stringify()를 사용하여 문자열로 변환해야 함

예시

export default function Loop() {
  // 배열 데이터 생성
  const items = ["apple", "banana", "cherry"];
  return (
    <ul>
      {items.map((item) => {
        return <li>{item}</li>;
      })}
    </ul>
  );
}

실행 결과

<ul>
  <li>apple</li>
  <li>banana</li>
  <li>cherry</li>
</ul>

map 메서드의 매개변수

map 메서드는 3개의 매개변수를 받을 수 있음:

1. item: 현재 처리 중인 요소 (필수)
2. index: 현재 처리 중인 요소의 인덱스 (선택)
3. array: map을 호출한 배열 자체 (선택)

예시: item과 index 사용

export default function LoopWithIndex() {
  const items = ["apple", "banana", "cherry"];
  return (
    <ul>
      {items.map((item, index) => (
        <li key={index}>{`${index + 1}. ${item}`}</li>
      ))}
    </ul>
  );
}

실행 결과

<ul>
  <li>1. apple</li>
  <li>2. banana</li>
  <li>3. cherry</li>
</ul>

key 속성

리액트에서 반복 렌더링할 때는 각 요소에 고유한 key 속성을 지정해야 함

key 역할

1. 렌더링 성능 최적화: 변경된 요소를 효율적으로 업데이트
2. 요소 추적: 요소를 정확히 식별

key 설정 예시

export default function LoopWithKey() {
  const items = ["apple", "banana", "cherry"];
  return (
    <ul>
      {items.map((item, index) => (
        <li key={index}>{item}</li>
      ))}
    </ul>
  );
}

💡 주의: 배열의 인덱스를 key로 사용하는 것은 권장되지 않음. 데이터에 고유한 값(ID)이 있다면 이를 사용할 것

React에서 조건부 렌더링은 특정 조건에 따라 컴포넌트를 표시하거나 숨길 때 사용

1. if문 사용

JSX 외부에서 조건에 따라 전체 컴포넌트 또는 JSX 블록을 처리할 때 유용함

예제: 컴포넌트 렌더링

import Login from "../Login";
import Logout from "../Logout";

export default function IfExample() {
  const isLoggedIn = true;

  if (isLoggedIn) {
    return <Login />;
  }
  return <Logout />;
}

예제: 간단한 메시지 출력

export default function IfExample() {
  const isLoggedIn = false;

  if (isLoggedIn) {
    return <h2>환영합니다!</h2>;
  }
  return <h2>로그인이 필요합니다.</h2>;
}

2. 삼항 연산자

JSX 내부에서 참과 거짓에 따라 다른 요소를 렌더링할 때 사용

1. 단순 텍스트 조건부 렌더링

export default function TernaryExample() {
  const isLoggedIn = true;

  return (
    <>
      <h1>{isLoggedIn ? "로그인 되었습니다" : "로그인이 필요합니다"}</h1>
    </>
  );
}

2. JSX 요소 조건부 렌더링

{isLoggedIn ? <h1>로그인 되었습니다</h1> : <h1>로그인 되지 않았습니다</h1>}

3. 컴포넌트 조건부 렌더링

{isLoggedIn ? <Login /> : <Logout />}

4. 인라인 스타일 조건부 적용

<h1 style={{ color: isLoggedIn ? "red" : "blue" }}>로그인</h1>

5. 클래스명 조건부 적용

<h1 className={`${isLoggedIn ? "text-rose-400" : "text-green-600"}`}>로그인</h1>

6. Tailwind Merge를 활용한 조건부 스타일링

<h1 className={twMerge(isLoggedIn ? "text-rose-400" : "text-gray-500")}>로그인</h1>

3. && 연산자

JSX 범위 안에서 참에 따른 분기 처리를 하고 싶을 때

예제: 특정 컴포넌트 렌더링

import Login from "../Login";
// 내가 true일 때만 렌더링하고 싶을 때 사용
// flase는 신경 안 쓰고 싶다! 하면 이렇게
export default function AndExample() {
  const isLoggedIn = true;

  return (
    <>
      {isLoggedIn && <Login />}
      <h2>이 메시지는 항상 보입니다.</h2>
    </>
  );
}

예제: 클래스 이름 적용

import { twMerge } from "tailwind-merge";

export default function AndExample() {
  const isLoggedIn = true;

  return (
     {/* 클래스네임 조건부 */}
      {/* style로는 불가능 */}
    <h1 className={twMerge(isLoggedIn && "text-green-600")}>
      조건부 클래스 적용
    </h1>
  );
}

4. 즉시 실행 함수 (IIFE)

🤔 JSX 표현식에서 if문 사용 불가? 놉, IIFE(즉시실행함수)로 사용 가능

IIFE를 사용하여 JSX 표현식 내에서 if문을 사용하는 방법

1. 함수를 소괄호 ()로 감싸기
2. 함수를 즉시 실행하기 위해 끝에 ()를 추가
3. 함수 내부에서 일반적인 if-else 문 사용 가능

예제: if문으로 조건부 렌더링

export default function IIFE() {
  const isLoggedIn = true;

  return (
    <>
      {(() => {
        if (isLoggedIn) {
          return <h2>로그인 되었습니다</h2>;
        } else {
          return <h2>로그인이 필요합니다</h2>;
        }
      })()}
    </>
  );
}

💡 참고: IIFE 활용 시 JSX 표현식 내부에서도 if문 사용 가능. 단, 가독성을 위해 외부 처리나 삼항/&& 연산자 사용이 일반적임

조건부 렌더링의 선택 기준