나의 경우 .. 사이드바를 내 페이지에서 사용할 수 있게

(장비 목록 클릭 ➡️ 사이드바 열림이 되도록 해야하는 상황이였다!)

사이드바와 장비 목록의 파일은 다른데 .......... 이럴때는 어떻게 해야할까 ?

바로 바로 ...

⭐⭐⭐

!! PROPs !!

⭐⭐⭐

props은 부모 컴포넌트에서 자식 컴포넌트로 데이터를 전달하는 방식으로

리액트에서 컴포넌트 재사용에 있어 아주 중요한 개념이다 😊

예시와 함께 살펴보면 >>

// 부모 컴포넌트
const ParentComponent = () => {
  const message = "Hello, World!";
  return <ChildComponent message={message} />;
};

// 자식 컴포넌트
const ChildComponent = (props: { message: string }) => {
  return <h1>{props.message}</h1>;
};

위 코드에서 ParentComponent는 ChildComponent에 message라는 값을 props로 전달하고 자식 컴포넌트는 이를 props.message로 받아서 출력한다.

이제 특징을 살펴보며 props에 대해 제대로 이해해보자 🐸

특징

1. 리액트의 단방향 데이터 흐름

리액트는 단방향 데이터 흐름을 따른다! 데이터는 *부모 -> 자식 방향으로만! * 전달할 수 있다는 것이다.

(( 내 코드에서는 selectedEquipment를 부모 컴포넌트( EquipmentContainer )에서 ➡️ 자식 컴포넌트( CustomSidebar )로 전달하고 있다. ))

2. Props는 읽기전용 😮

props의 경우 데이터를 읽기 전용 데이터로 전달한다.

즉! 일반적으로 *자식 컴포넌트에서는 내용을 수정할 수 없고❌ * 부모가 전달한 값을 그대로~~ 사용해야한다.

(자식에서 변경하고싶다면 콜백함수를 사용해서 부모에게 변경 요청을 보내야한다. )

3. props가 변하면 리렌더링

props가 바뀌면 컴포넌트가 리렌더링 된다.

즉 , *|⭐ 부모-데이터 ➡️ 자식 컴포넌트 ➡️ 자식컴포넌트 리렌더링 ⭐| *인 구조다.

내 코드를 살펴보면 )

selectedEquipment는 데이터고, 이 값을 props로 전달한다.

① 부모에서 selectedEquipment가 변경될 때마다, ② 자식 컴포넌트(CustomSidebar)도 변경된 데이터를 자동으로 받아서 ③ 리렌더링!

3. 함수 전달

데이터를 전달할 뿐만 아니라, 함수도 전달할 수 있다.

예를 들어 ! 부모 컴포넌트에서 자식에게 상태를 변경하는 함수를 전달하여, 자식 컴포넌트에서 그 함수를 실행할 수 있습니다.

// 부모 컴포넌트
const ParentComponent = () => {
  const [count, setCount] = useState(0);

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

  return <ChildComponent increment={increment} />;
};

// 자식 컴포넌트
const ChildComponent = (props: { increment: () => void }) => {
  return <button onClick={props.increment}>Increment</button>;
};

위 코드에서 increment 함수는 부모에서 자식 컴포넌트로 전달되고, 자식 컴포넌트에서 그 함수를 호출하여 부모의 상태를 변경할 수 있다.

🐸정리⭐

** Props는 | 컴포넌트 간의 데이터 공유를 가능하게 하는 데이터 전달의 핵심 !! | ** 컴포넌트 간의 관계를 형성하고, . . 특징으로는 1. 단방향 데이터 흐름 ** *2. 읽기 전용 * _ 자식에서 내용 변경할 수 없음 상태 관리가 필요한 컴포넌트에서는 useState나 useReducer를 사용해야 !~! **3. Props가 변경되면 해당 컴포넌트는 리렌더링 . . 장점은 ! 컴포넌트 재사용성 높여줌 👍

끝 🥰

이런 걸 만들고 싶었는데 문제가 생겼다 …

⭐ 오류:

"선택된 장비가 없습니다" 문구가 사라지지 않는 오류‼️😢

현상 :

아이템이 선택되어 대여 신청 버튼 api에 정보가 추가되었지만, 여전히 "선택된 장비가 없습니다." 문구가 표시되는 혼란이 있었다. 😮

( selectedItems[category] || []).length > 0 조건이 예상대로 동작하지 않음 )

내가 생각했던 초기 원인은 ..🙆‍♀️

그렇다면 selectedItems의 업데이트와 렌더링이 문제가 아닐지 의심되었는데..

1. handleItemClick에 로그를 넣어도 console에 출력되지 않고..

2. selectedItems들은 정상적으로 업데이트 되고 있었다..

   그래서 느낌은 오는데 어떤 코드 때문인지 확신이 들지 않았다.

실제 원인은 ...!

➔ 상태 관리 방식의 문제!

: selectedItems 혹은 plan.equipment가 이전 상태를 참조하며 불변성이 유지되지 않고

-> ‼️ 렌더링이 정상적으로 이루어지지 않은 것..‼️

⭐ 해결 방법 :

• 각 카테고리를 Set을 사용하여 중복을 처리👏

• plan.equipment의 상태 업데이트를 불변성을 유지하면서 안전하게 변경한 것이 핵!심! 포인트 !

  • selectedItems[category]로 선택된 장비들을 관리하면서 그 상태를 반영하여 렌더링

. . .

• !!! 중복 코드가 많을 때는 상태 관리가 복잡해지니까 코드가 깔끔하게 업데이트되고,

• 불필요한 렌더링을 방지*하는 방향으로 개선하는 것이 중요하다고 한다.

• ( + ) Set을 사용함으로써 불필요한 중복 코드와 map() 호출 줄이기

➕ 불변성(Immutable State) : React에서 상태를 직접 수정하는 것보다 ➡️ 상태를 새로 생성하는 것이 중요 - 예를 들어, setSelectedItems(prev => [...prev])처럼 이전 상태를 변경하지 않고 새로운 상태를 반환하는 방식 😮

이 중에서도

⭐Set<string> 사용⭐이

중점적인 문제 해결에 도움을 준것 같아서, 이 부분에 대해 자세히 알아보고자 한다. >.<

Set<string>의 개념과 사용👏👏

Set : 중복된 값을 허용하지 않는 데이터 구조

• 배열과 비슷한데 중복 허용안함
• 메서드 : 아이템 추가 및 삭제 - add(item), delete(item) / 값 확인(존재 여부) - has(item) / 모든 값 삭제 - clear()
• 순서 없음

우리가 주목해야할 포인트는 중복 허용하지 않음 !

예를 들어 ))

이미 선택된 장비를 추가하려고 할 때, Set은 그 아이템이 이미 포함되어 있으면 추가하지 않고, 이미 존재하지 않는 경우에만 추가하게 되어있다 .

즉 ,

Set이 중복된 값들이 생기지 않도록 자연스레 관리해주는 역할 ! 을 한다 😻

set의 장점은 🤗

• 중복 제거
• 효율적인 추가 및 삭제
• 불변성 유지 ( 원본 수정 대신 새롭게 복사된 개체로 값 업데이트 함 )

이라고 할 수 있겠다 !

배열을 쓰는 것보다 직관적이고 간단하게 관리하며 불변성의 오류를 줄일 수 있다 굿~~

실제 코드 비교 🐱

해결 전 코드:

const handleItemClick = (category: string, item: string) => {
  setSelectedItems((prev) => {
    const prevItems = prev[category] || [];
    const newItems = prevItems.includes(item)
      ? prevItems.filter((i) => i !== item) // 이미 선택된 경우 삭제
      : [...prevItems, item]; // 선택되지 않은 경우 추가
    return { ...prev, [category]: newItems };
  });

  // 강제 리렌더링 트리거
  setForceRender((prev) => prev + 1);
};

해결 후 코드:

const handleItemClick = (category: string, item: string) => {
  setSelectedItems((prev) => {
    const updatedCategory = new Set(prev[category] || []); // **Set**으로 기존 아이템 복사
    updatedCategory.has(item) ? updatedCategory.delete(item) : updatedCategory.add(item); // 추가 및 삭제
    return { ...prev, [category]: updatedCategory }; // **불변성을** 지키며 상태 업데이트
  });

  // 강제 리렌더링 트리거
  setForceRender((prev) => prev + 1);
};

+ 불필요한 map() 호출 제거

처음 코드에서는 plans.map()을 사용하여 모든 아이템을 순회했지만,

이렇게 해주면 중복된 아이템을 관리하는 데 Set만 사용하면 되어서 성능을 개선할 수 있다

// 중복 없이 아이템을 가져오는 방법
const uniqueItems = Array.from(
  new Set<string>(plans.flatMap((plan) => plan.equipment?.[category] || []))
);

⭐ plans.map()을 사용한 방식에서는 매번 배열을 순회해야 했지만, Set을 사용하면 flatMap을 사용하여 중복 없이 한번에 처리할 수 있다. ⭐

.

.

코드가 복잡해질때는 간결하고 명확한 것이 최고 … ⭐ ))

⭐ 전체 문제 해결 완 ! 뭐가 나아졌나면 ..

1. 중복 처리 최적화: Set을 사용하여 중복 아이템이 자동으로 관리되므로, 불필요한 상태 업데이트를 줄일 수 있었다.
2. 상태 관리의 불변성 유지: 상태를 직접 수정하지 않고, 복사본을 만들어서 업데이트하므로 React에서 예상치 못한 동작을 방지할 수 있었습니다.
3. 성능 최적화: map() 호출을 줄이고, Set을 사용하여 아이템을 효율적으로 관리함으로써 렌더링 성능을 개선할 수 있었습니다.👍

⭐ 새롭게 배운점

1. 불변성의 중요성…😉 ( setState 공부 이후 또 다시 느낀 .. )

React에서 상태를 직접 변경하지 않고, 상태의 복사본을 만들어 변경하는 방식

렌더링에도 영향을 미쳐서 매우매우 중요한 것 같다

2. Set의 효율성

중복 코드가 많아지고 상태 관리가 복잡해질 때, Set의 사용은 중복을 자동으로 제거해주니까 매우 효율적이다 .. !>!>

3. 상태 업데이트 최적화

상태 업데이트를 최적화하려면..!

불필요한 map() 호출을 피하고, Set과 같은 자료구조를 사용해서 성능 개선 해보기 … !

끝 ‼️

: 기억하고 관리해야하는 동적인 데이터 🐱

➡️버튼 클릭 횟수, 사용자가 입력한 텍스트, 서버에서 가져온 데이터 등은 모두 상태이다 !

😮상태에 영향을 주는 것 : 사용자 입력이나 서버의 응답, UI의 변화 등 ..

➕추가로 ... ** 리액트는 **불변성을 기반으로 동작하기에, 기존 객체 수정 ( X ) 새로운 객체를 생성해 교체👍 ( O ) -> 이렇게 참조 주소를 비교하는 것은 렌더링 성능에 도움을 준다

((변경된 부분만 업데이트 → 브라우저에 최소한의 성능 비용으로 변경 반영!해주기 때문 ))

⭐ 상태 관리의 필요성

React는 UI = f(상태)라는 개념을 기반으로 동작해서 즉, 상태가 변경되면 UI가 다시 렌더링된다.

올바르게 관리하지 않으면 어떤 문제가 발생할 수 있냐면 ..

1. 비일관성: UI와 내부 데이터가 일치하지 않는 😮 상황 발생

2. ** 복잡성 증가**: 상태를 효율적으로 관리하지 않으면 코드가 복잡해짐 😢

3. 디버깅 어려움: 상태 변경 흐름을 이해하기 어려워짐

. .

나의 경우에는 비일관성 문제를 겪어서 렌더링이 바로 되지 않는 문제가 생겼었다

하지만 !!!

상태관리를 알아둔다면

이런 문제를 만들지 않을 수 있다 .. 👍🐱

상태 관리를 신경쓰기만 해도 UI와 데이터의 일관성을 유지하고, 코드의 가독성과 유지보수성 향상시킬 수 있으며, 디버깅이나 확장도 쉬워질 것이다~

그러니까 알아둬야한다..

우선 개념을 알아보도록 하자

⭐ React에서의 상태 관리 - useState

useState란?

useState는 React에서 컴포넌트의 상태를 선언하고 관리할 수 있도록 도와주는 훅이다.

📌 기본 개념

1. 상태 변수 선언
2. 상태 변경 함수 제공

앞서 말했듯이 리액트에서는 상태 변경 -> UI 리렌더링이 되기에 쉽게 ~! 동적 UI 를 구현할 수 있다

📌 기본 사용법

const [state, setState] = useState(initialValue);

• state : 현재 상태 값
• setState : 상태를 변경하는 함수
• initialValue : 상태의 초기값 (숫자, 문자열, 배열, 객체 등이 가능함!)

코드를 살펴보며 설명해보면

import React, { useState } from 'react';

function Counter() {
  //⭐ 상태 변수 count, 상태 변경 함수 setCount
  const [count, setCount] = useState(0); 
//⭐➡️ count 초기값 : 0 -> 처음 렌더링때만 적용 !!

  //⭐버튼 클릭 시 상태 변경 ➡️ 클릭시 1 증가
  const handleIncrement = () => {
    setCount(count + 1); //⭐ 상태 변경 예약 & 렌더링 요청, 상태 변경시 리렌더링 ‼️
  };

  return (
    <div>
      <p> 현재 카운트: {count} </p>
      <button onClick={handleIncrement}>+1 증가</button>
    </div>
  );
}

export default Counter;

여기서 중요한 건 리액트는 이전 상태와 새로운 상태의 참조를 비교해서 렌더링 여부를 결정한다는 것이다. . . 그렇기에 setCount만 설정하면 상태 변경이 예약된 상태이고 위의 코드의 경우 onClick으로 상태가 변경되어야‼️ 리렌더링이 이루어진다 🙆‍♀️

개념을 알았다면 좀 더 본격적으로 ☺️ 본격적인 특징과 동작 원리를 공부해보자 ⭐

⭐ useState의 특징과 동작 원리

_

1. 비동기적 상태 업데이트

바로 직전에 설명했던 것이다 !~))

React는 성능 최적화를 위해 상태 업데이트를 비동기적으로 처리한다.

setState를 호출한 직후에는 변경된 값이 바로 반영되지 않고 ❌

Batch Processing(일괄 처리)를 통해 여러 상태 변경을 묶어서 처리한다.

const [count, setCount] = useState(0);

const handleClick = () => {
  setCount(count + 1);
  console.log(count); // 예상: 1 / 실제: 0 (이전 값 출력)
};

이 코드의 문제는 무엇일까 ~?

. .

정답 : 상태 업데이트를 예약만 하고 바로 실행하지 않기에 문제가 생긴다! 렌더링 시점의 count를 참조하기 때문에 항상 이전 값이 사용되고 있다 😮

어떻게 수정해주면 좋을까 ? . .

const handleClick = () => {
  setCount(prevCount => prevCount + 1);
  console.log(count); // 예상: 1 / 실제: 여전히 이전 값이지만 내부 로직은 올바르게 동작
};

➡️ 이렇게 함수형 업데이트를 활용해서 수정해줄 수 있다 ! 🐱

= 이러면 prevCount를 통해 최신 상태가 유지되고, 다음 렌더링 시에는 올바른 값이 화면에 표시된다. ☺️

2. 객체 상태 관리와 불변성

React는 불변성 원칙을 따르기 때문에 기존 객체를 직접 수정하면 안된다

➡️ 기존 객체를 수정하면 참조 주소가 동일해서 변경이 없다고 판단하여 렌더링이 일어나지 않는다 . .

• 기존 객체 수정 → 리렌더링 ❌

  const [user, setUser] = useState({ name: 'Lee', age: 24 });
  >
  const changeName = () => {
  user.name = 'Kim';
  setUser(user); // 참조 주소 동일 → 리렌더링 안 됨
  };

• 새로운 객체 → 리렌더링 😉

  const changeName = () => {
  setUser(prevUser => ({ ...prevUser, name: 'Kim' }));
  };

3. 독립적 상태 관리 💖

React에서는 각 상태가 독립적으로 관리된다.

🐱 관련된 상태는 객체 형태로 묶어서 관리 가능하다 → 코드 가독성 올라감 😮

const [user, setUser] = useState({ name: '', age: 0 });

const updateName = (newName) => {
  setUser(prevUser => ({ ...prevUser, name: newName }));
};

정리해보면 ~

• 상태(state)는 React에서 동적 데이터를 관리하고 변경 시 UI가 자동으로 리렌더링 🔃

• 불변성 유지 중요 ⭐ 객체 수정 시 반드시 새로운 객체를 생성해야 리렌더링 작동

• setState는 비동기적 ☺️‼️ 최신 상태를 보장을 위해서 함수형 업데이트를 사용해야 함

. . . 끝 ✌️

- 계속 찾아오게 되는 ux / ui

• 직관적인 단어 사용
• 친근한 어투 + 이름 불러줌

: ㅇㅇ님을 위해 준비했어요 (이벤트 광고임), ㅇㅇ님을 위한 서비스 (서비스 랭킹, 이것도 사실상 광고임) → 그렇지만 ..~~ 소속감을 주고 앱에 대한 좋은 경험을 주는 말투임

• 로딩, 페이지 전환 시 애니메이션 사용 및 멘트 : 기다리는 동안 지루하지 않음 (도허티 임계값)

- 토스의 이벤트는 왜 참여하게 될까 ? ( UX )

1. 클릭하기 좋은 하단의 위치에 이벤트가 있음

2. 제일 처음 눈길이 가는 상단에 이벤트 배너가 있음 , 배너의 아이콘이 *움직임 *(클릭 유도)

   : 이렇게 혹해서 들어가면 …. 머무는 시간에 따라 포인트를 지급하는 이벤트가 있는데 이러면 처음에 토스 앱에 들어왔던 목적은 까먹고 계속 머무르게 된다 .. . … 시선이 가는 위치에 시간이 뜸

3. 공유하는 미션, 이벤트 : 한 번씩 토스 이벤트 링크 친구한테 받아본 적 있을 것이다….ㅇ.. !

4. 친근한 대화체

토스의 ui 에 대해 알아보자

색상 간소화

• 파랑 한가지의 포인트 컬러 ( 여기어때는 빨강/파랑, 당근은 초록/주황의 포인트가 있었는데 여기는 파랑뿐이다 )

  → 그럼에도 눈이 지루하지 않은 이유는 3D 아이콘의 색이 다양해서인듯 하다 😺👍

• 아주 가끔 다른 색을 쓰기도 하는데 .. (대부분 광고를 위함, 또는 업데이트 알림 )

: 이게 오히려 시선을 끄는 효과가 있다❗ ( 폰 레스토프 효과 )

깔끔하고 간결한 디자인

• 기존 은행 앱과 유사한 UI : 제이콥의 법칙
• 시각적 명확성 : 직관적인 아이콘 디자인

• 메인화면의 적은 카테고리 : 하단 네비게이션 바를 통해 페이지 안에 탭, 탭 안에 페이지 연결 등으로 연결되도록 하여 복잡하고 넓은 구조를 깔끔하게 정리해뒀다 . . . (사실상 따로 햄버거 버튼을 안 열어도 웬만한 기능은 하단 네비게이션 바의 네 개의 아이콘을 통해 들어갈 수 있을 것 같다)

• 시각적 계층 구조

  : 컨테이너의 배경색을 다르게 하고 여백을 두어 각 요소를 구분하여 가독성을 높였다

• [모든 서비스]의 텍스트 정렬

: 제목 - 설명을 space between 느낌으로 정렬한 게 좋다. 눈에 더 잘 들어오는 듯 🥰!!

• 우선순위 강조

  : 중요한 작업은 시각적으로 강조하여 사용자에게 우선순위 인식 유도

🤗 이건 어떨까 ?

• 가독성 개선

- 첫 화면에 볼드 사용 줄이기 ( -> 폰트 크기 변화로 대체 ) - 쉬운 홈 기능 추가하기 ( 우리 은행 앱 참고..😺 ) : 이벤트 내용 숨기고 은행 기능만 바로 사용할 수 있게 하면 어떨지 ~

• 첫 화면 : 우선순위에 맞게 위치 변경
  • 송금은 중요한 업무니까 → 파란색 결제도 자주 사용하니까 → 바디 부분으로 위치 변경하는것두 좋을듯

👌 심미적 사용성 효과, 게슈탈트 유사성의 원리

• 라운드 통일 ( 카드, 버튼 등 )
• 라운드 → 부드럽고 깔끔한 분위기
• 검정 / 화이트 기반의 심플한 디자인, 브랜드의 이름🥕 떠올리는 주황/초록의 포인트 컬러 사용

✨

• 심미적 사용성 효과 : 시각적으로 깔끔하고 조화로운 디자인→ 사용자의 만족도를 높이고 신뢰도 향상 시킴
• 게슈탈트 유사성의 원리 : 유사한 형태와 색상의 요소를 배치해서 시각적 그룹화 유도함

레이아웃 및 내비게이션 구조

👌 제이콥의 법칙, 히크의 법칙, 게슈탈트 원리

• 기본 구조: 상단바 - 바디 - 하단 네비게이션 바
• 하단 네비게이션바 아이콘에 익숙한 디자인을 사용 → 쉽게 이해 가능
• 햄버거 메뉴에 부가 기능을 숨겨 메인 화면의 복잡성을 최소화
• 특정 항목(3개_[동네거래])만 메인에 표시 🥰

✨

• 제이콥의 법칙 : 사용자는 다른 앱에서 경험한 인터페이스와 유사한 디자인을 선호
• 히크의 법칙 :메인 화면에서는 ‘동네거래’ 관련 핵심 기능만 노출하여 선택지를 최소화

• 사용자의 의사결정 부담 감소 🤭

• 게슈탈트 원리 : 상단바와 본문, 네비게이션 바 사이의 여백을 활용해 기능별 구분을 명확히 함

카드형 레이아웃 및 정보 구성

👌 폰 레스토프 효과, 게슈탈트 원리

• 정보구성 : 가격(+예약/완료) → 제품명 → 장소 및 업로드 시간 → 채팅 & 찜 개수 순서로 강조
  • 색상 차별, 글씨 굵기를 활용해 정보의 위계를 나타냄
• 카드형 디자인 → 직관적 정보 전달

✨

• 폰 레스토프 효과 : 주황색으로 강조 (가격 정보, 주요 버튼 등)
• 게슈탈트 원리
  : 중요한 정보(가격, 상태)를 더 강조 ❗

로딩 및 시스템 반응성

👌도허티 임계값

• 로딩 중 애니메이션과 스켈레톤 스크린 표시

✨

• 도허티 임계값 : 시스템 반응 시간이 400ms 이하일 경우 사용자가 더 유쾌하게 느끼도록 애니메이션과 시각적 피드백 제공

글쓰기 (상품 등록)

👌 폰 레스토프 효과, 피츠의 법칙

• [글쓰기] 버튼을 주황색으로 강조
• [메인] - [글쓰기] 창에서 바로 [동네 거래] 네 가지 카테고리 선택 가능 : 사용자 니즈 파악
• 글쓰기 버튼, 작성 완료 버튼은 하단에 배치하여 쉽게 터치할 수 있게 함

✨

• 폰 레스토프 효과 : 주황색으로 강조 (글쓰기)
• 피츠의 법칙 : 버튼을 사용자의 손이 쉽게 닿는 위치에 배치 : 접근성과 사용성 향상

🐹 이건 어떨까 ?

• 하단 네비게이션 바 텍스트 지우기

  : 아이콘 만으로 기능을 충분히 인지할 수 있을 것 같아 텍스트를 지우고 깔끔하게 정리해보는 건 어떨까 ~

• 대체로 탭 전환 대신 페이지 전환을 사용한 부분 → 탭 전환 사용 비율 높이기 : 로딩시간이 길어지는 문제가 생김 → 일부는 탭으로 정리해도 좋을 듯하다

• 하단 네비게이션 바 : [검색] 아이콘이 있어서 접근이 편함
• 캘린더 : 무한 스크롤로 클릭하는 것보다 사용하기 편하도록 구성함

• 카드 카테고리 화 : 카드 자체를 카테고리로 사용하여 접근이 쉬움 👌

2. 폰 레스토프 효과

• 빨강📍을 브랜드 색으로 사용해 요소들을 강조함
• 파랑으로 빨강보다 중요한 요소들을 추가적인 강조 ( 확인, 결제, 적용 등 )

3. 히크의 법칙

• 검색 내 탭 전환 : [국내숙소, 해외숙소, 항공, 레저티켓]을 따로 페이지를 열 필요 없이 탭으로 전환해 바꿔서 검색할 수 있도록 구성해 사용자의 움직임을 편하게 함

• 날짜/인원 선택 탭 전환 : 사용자가 쉽게 선택할 수 있음

4. 게슈탈트 원리

• 카드 디자인 : 클릭하기 쉬운 적당한 카드의 크기와 이미지로 이해가 쉬움( 홈 & 빌라 페이지 )
• 카드 카테고리 화 : 카드를 카테고리화하여 필요한 정보만 간결하게 담아둠

5. 기타

• 색상, 폰트 크기와 굵기로 중요도를 잘 나눠줘서 눈이 편안함
• 여백도 다른 앱에 비해 넓은 느낌임 😺
• 큐레이팅이 많으며 짧고 직관적인 단어들을 사용하여 클릭하고 싶어짐.

🤭 이건 어떨까 ?

• 카테고리 항목 개수 줄이기 _ 밀러의 법칙 : 사람은 단기 기억에서 평균 7±2개의 항목만 기억 가능하다고 함

  첫 화면에서 12개의 종류가 나오는데 더 그룹화 하면 좋을 듯함!

• 카드 크기 키우기 _ 피츠의 법칙 : 홈&빌라 페이지 외의 다른 페이지의 카드는 너무 작음

  피츠의 법칙에 따라 손가락으로 쉽게 누를 수 있는 크기로 조정해야 함

• 최저가 보장 정보 강조 (해외숙소 페이지) : 최저가 보장과 인기 여행지란이 구분이 잘 안 됨. ‘최저가 보장 인기 여행지’를 좀 더 키우고 강조해야 사용자가 더 쉽게 인지할 수 있음. 리조트 이름은 볼드체로 빼면 좋을 듯~ ~→ 당근의 중고거래 상품 ui 처럼 !

• 일관성 만들기

  • 타이틀 폰트, 배치 통일

: 홈 & 빌라 페이지만 폰트가 다르며, 타이틀이 상단 바에 위치하지 않음 일관된 디자인 원칙을 따라 통일감 있는 UI를 제공하는 것이 좋음

• 카테고리 아이콘 디자인 통일

  

    : 첫 화면의** 3D 아이콘**과 다른 페이지에서 사용된 **2D 아이콘**이 통일되지 않아 혼란을 유발할 수 있음 → 단색 아이콘이나 통일된 스타일로 변경하는 것이 좋을 듯

• 광고의 위치 때문에 다른 페이지들(예: 호텔, 리조트, 펜션)의 디자인이 달라짐 일관성 있는 디자인을 유지하도록 수정하면 좋을 듯함

• 카테고리 구분 개선

  : 펜션과 풀빌라의 인기/특가 카테고리가 혼합되어 있어 사용자가 쉽게 구별할 수 없음 카드를 더 눈에 띄게 강조하거나 카테고리를 분리하여 가독성을 높이는 것이 좋을 듯함

커밋에 올리고 작업중이던 코드의 오류하나를 해결했는데

괜찮았던 다른 코드에서 오류가 생겼어요.. .................*심하게.. *😭

그래서 그 부분은 예전에 올렸던 파일을 다시 가져오고 싶은데 ~

이럴때는 어떻게 해야할까요 ?

바로 이전 커밋이 아니더라도 ❗ 그 파일만 가져올 수 있을거 같은데 ~ 분명 하고 찾아봤습니다

. . .

그래서 두 가지를 발견했습니다!!~!

cheery-pick

checkout

둘 중에 어떤 걸 사용해야할까요❓

Cheery-pick이란?

Git Cherry-Pick🍒👀

다른 브랜치에서 어떤 특정 커밋만 콕! 집어서 내 브랜치로 가져오는 명령어

🐱 세부적으로는 언제 쓰냐면

(1) 공통으로 merge했던 커밋을 가져와 수정할 때 (2) 팀원이 작업한 특정 커밋을 -> 내 브랜치로 끌어와 확인/추가 하고 싶을 때 (3) 버그 픽스 커밋을 다른 브랜치에서도 적용해야 할 때

❗즉! 다른 브랜치의 여러 커밋들 중 필요한 커밋만 선택적으로 가져와서 적용할 때 ❗

사용방법

** <1> **

git cherry-pick <커밋ID>

( 원하는 커밋이 있는 위치로 이동 후 명령어 실행 )

** <2> **

. . .

⭐⭐⭐여기서 중요한 거! cheery-pick 은 *다른 브랜치 * 에서 내 브랜치로 가져올 때 유용하다는 점입니다 ......

그래서 제가 하고 싶었던 것처럼 내 브랜치에 있는 걸 다시 가져오는 데는 cherry-pick이 아닌❌❌ 다른 방법을 써야한다는거죠~😮

그 다른 방법이 checkout 입니다~

Checkout이란?

Git Checkout 🔄

: git checkout은 특정 커밋 상태로 되돌리거나, 브랜치를 전환할 때 쓰는 명령어

🐱 세부적으로는 언제 쓰냐면

(1) 특정 커밋에 있던 파일만 현재 브랜치로 가져올 때 (2) 파일 상태를 특정 커밋 상태로 복구하고 싶을 때 ⭐

사용방법

• (1) 브랜치 이동 : 작업하려는 다른 브랜치로 이동할 때

  git checkout <브랜치이름>

• (2) 파일을 이전 상태로 되돌리기

: 주로 현재 작업 중인 브랜치에서 특정 커밋의 파일을 덮어씌우는 경우에 사용 ❗

  git checkout <커밋ID> -- <파일경로>

-> ✨커밋 내역을 유지한 채 파일만 덮어쓸 수 있습니다.✨

⭐⭐ 정리해봅시다 ⭐⭐

Cherry-Pick 🍒 : 브랜치에 적용

• 다른 브랜치에 있는 커밋 -> 내 브랜치로
• 딱 필요한 커밋만 골라서 가져오는 거!
• 파일뿐만 아니라 커밋 내역을 그대로 가져와 적용하는 데 유용

Checkout 🔄 : 파일 되돌리기

• *특정 커밋에 있던 파일만 복원하고 싶을 때 *
• 내 브랜치의 파일 상태를 이전 커밋 상태로 덮기

• 파일을 복원하고 싶을 때 : checkout

• 특정 커밋을 다른 브랜치에 적용 : cherry-pick

• 커밋 보존하고, 선택적으로 변경사항을 적용 : cherry-pick

결론😎

저의경우 내 브랜치에 있던 파일을 복원하고 싶었던 것이니 checkout 을 사용하면 되겠군요 ~ . . . (해결👍) . . 흑............다행이다 이제 다시 열심히 개발해보겠습니다😉 안녕 ✨

👏 두 문제를 해결하면 알 수 있는 것

• ul 기본 설정 값
• border-box

문제 1 : 왼쪽 여백 발생

토글목록을 만드는 중 아래와 같이 두 길이가 다른 오류가 발생했다. 이상하다..🤔 가로 길이 똑같이 했는데 padding도 없고, border도 없는데 앞에 여백이 왜 생겼지..

개발자 도구를 열어 어디에 속해있는지 확인해본 결과 ul 로 묶여있었다. . .

원인은 브라우저가 ul 태그에 기본적으로 적용시킨 padding-left: 40px였다.

_그래서 ul 태그의 기본 스타일을 제거하는 코드를 추가했다. _

ul {
  margin: 0;           /* 기본 마진 제거 */
  padding: 0;          /* 기본 패딩 제거 */
  list-style: none;    /* 기본 리스트 스타일 제거 */
}

만약에 특정 클래스에만 적용하려면 :

.itemList {
  margin: 0;
  padding: 0;
  list-style: none; 
}

이런 방식으로 해결할 수 있다.

_ list-style은 ul, ol 태그에 기본 적용된 리스트 아이템의 점, 숫자 등을 제거하는 속성이다._

끝~이 아니다...

해결될 줄 알았는데 이번에는 *길이가 다르다... *

... padding과 border 설정은 맞게 한 거 같은데.. 어떻게 수정해야할까 ?

문제 2 : 패딩 및 보더로 인한 길이 차이 발생

기본적으로 width는 컨텐츠 영역만의 너비를 의미하고, padding과 border는 width에 포함되지 않기 때문에 추가적인 여백을 차지한다.

아래 코드를 추가해서 해결할 수 있다!

* {
  box-sizing: border-box;
}

이 코드를 통해 width는 padding과 border를 포함한 전체 너비를 의미하게된다.

이렇게 설정을 바꾸면 반응형 디자인에서도 사전에 지정된 기본 값을 유지하면서 특정 비율을 차지하게 쉽게 설정되어 용이해진다. -> 레이아웃 조절이 쉬워진다.👍 . . . .

❗다만, 몇가지 유의가 필요하다.

사전에 width를 설정할 때, border과 padding을 더한 값으로 설정해야함을 유의해야한다.

만약 특정 padding값과 border 값으로 디자인 할 계획이라면 box-sizing: border-box; 설정이 없어도 된다. ㅣ 나의 경우 padding, border 값과 px값이 의도한 값에 비해 작은 차이만큼만 발생하여, 반응형에 용이하도록 box-sizing: border-box;를 사용하게 되었다.

✨ 길이 차이 발생은 인접한 요소간 마진겹침 현상 때문에 발생할 수도 있다. 길이 차이가 발생한다면 마진 겹침 또한 고려해보아야한다.😉✨

해결..👏

//

나의 경우 Heading1이라는 variables.module.css에 저장된 스타일로 '장비 대여 신청'이라는 텍스트를 적으려고 했는데 아무리봐도 이건 폰트크기가 30px이라기에는 너무 커보인다 .. 😑

. .

개발자 도구를 들어가 확인해보았더니 _user agent stylesheet_라고 떴다.

user agent stylesheet로 보이는 부분은 브라우저에서 기본적으로 적용하는 스타일이라고 한다. 이걸 알기 전까지는 우선 순위고 뭐고 .. 여러 문제를 의심해봤지만 user agent stylesheet가 떴다는 것은 아무!! 스타일이 적용되지 않았다는 것이다. (...)

user agent stylesheet에서 내 텍스트는 h1 태그로 되어있어 자동으로 두껍고 큰 크기의 글씨로 적용되었다. ( h1 태그는 보통 Heading 역할을 하기 때문이다. )

. .

❗즉, heading1이 적용되지 않았다.

. . 이게 내 파일 구조인데

/pages ├── rentDetail │ ├── rent.module.css │ └── rent.tsx <- 여기에 있는 텍스트에 스타일 적용 시킬거임

/styles ├── global.css ├── globalStyle.ts ├── theme.ts └── variables.module.css 내가 적은 코드는 클래스명을 바로 heading1으로 두어 오류가 발생했다. variables로 variable.module.css를 불러왔으니 이 안에 있는 클래스 heading1을 적용시키고 싶다면 variables.heading1으로 불러와야 적용된다!

이 경우 이때 className에는 ""(문자열)이 아니라 {}로 감싸 변수 형태로 전달해야한다는 것을 유의해야한다.

유의하지 않고 아래 사진처럼 쓰면 ... 당연히 오류가 발생한다.😊 = 중괄호 {} 안에 다시 문자열로 감싼 형태이기 때문에 변수로 인식되지 않는다.

. .

그래서 올바르게 변경해주고~ 개발자 도구에 들어가 변경사항을 확인해보면~ 이제 폰트크기가 30px로 올바르게 설정된 것을 확인할 수 있다.

. .

✨ 배운 점 👏✨

1. CSS 모듈은 클래스를 변수로 불러와야 하며, 경로를 어떻게 import 해왔는지를 고려하여 불러와야한다.

2. className에서 문자열이 아닌 변수를 사용할 때는 {}로 감싸야한다.

3. 개발자 도구를 활용하여 오류를 찾고, 수정 후 적용 여부를 재검토하는 것의 중요성을 깨닫게 되었다.

4. user agent stylesheet의 의미

//

해결...🥰