[01/08 부트캠프] 강의: 리액트 입문 2주차, ③UX집중반: 쏘카 문제해결 과제

 

내일배움캠프 D-54 (12주차)

 

📌To Do List

* 강의: 리액트 입문 2주차  ✅ 드뎌 완료!!!

* UX집중반: ③문제해결 ✅

 

 

 

01 강의: 리액트 입문 2주차

✏️컴포넌트 및 렌더링

＊컴포넌트

- 리액트의 핵심

- UI요소를 표현하는 최소한의 단위

- 화면의 특정 부분이 어떻게 생길지 정하는 선언체★

 

전엔 명령형 프로그래밍인 DOM을 사용해서 컴퓨터가 수행하는 절차를 일일이 작성해서 어려웠다고한다.

현재는 리액트(선언형 프로그래밍)를 쓰면 어떻게 화면에 그려야할지 리액트 내부에서 추상화를 하는데,  더 빠르고 효율적으로 사용할 수 있다.

 

 

＊렌더링

- 컴포넌트가 현재 props와 state상태에 기초해 어떻게 UI를 구성할지 컴포넌트에게 요청하는 작업.

이렇게만 봤을 때 무슨 뜻인지 잘 이해가 가지않았는데 강사님께서는 이것을 한 레스토랑 상황에 빗대어서 설명해주셨다.

 

UI : 요리

컴포넌트 : 주방장

리액트 : 웨이터

 

이렇게 봤을 때 렌더링의 프로세스에 대해 더 잘 이해할 수 있었다.

 

<렌더링 프로세스>

① triggering: 렌더링 일으킴 (UI주문하고 주방으로 리액트가 전달한다)
② rendering: 렌더링 함 (주방에서 컴포넌트가 UI를 만든다)
③ commit: 렌더링 결과를 실제 DOM에 커밋 (리액트가 손님 테이블에 UI를 올린다)

 

trigger는 피그마를 공부할 때도 많이 배워서 익숙했는데

렌더링과 커밋은 그렇지 않았다. 레스토랑 상황에 빗대어서 생각해보니 보다 쉽게 이해할 수 있었다.

 

 

🤔렌더링은 어떤 경우에 발생할까?

1) 처음 리액트 실행

2) 리액트 내부에 어떤 상태(state)가 변경됐을 때

- state 변경, 새로운 props 들어올 때 → 부모 컴포넌트에서 이와 같은 이유가 발생할 때 (자식 컴포넌트도 영향을 받아 리렌더링 됨)

 

<리렌더링>

- 재주문해서 컴포넌트가 새로운 UI(요리)를 만들고 다시 손님테이블에 가는 것

새로고침의 개념이라고 이해했다.

 

하지만 리액트 렌더링과 브라우저 렌더링은 다르기 때문에 혼동하면안된다고 한다.

<브라우저 렌더링 프로세스> = 페인팅이라고 불리기도함.

렌더링 → 리액트가 DOM업데이트 → 브라우저에서 화면 보여줌.

 

 

✏️DOM

＊DOM (Document Object Model): 문서객체모델

- 문서(document): 컴포넌트로 구성된 웹페이지

- 엘리먼트(element): 페이지 이루는 컴포넌트

- 노드(node): 트리의 요소 하나하나. 각 노드는 노드에 접근/제어할 수 있는 API제공

- API(Application Programming Interface): html 요소에 접근해서 수정할 수 있는 함수.

: 클라이언트(요청(나)) - 서버(본사에서 응답하는 컴퓨터)로 구성

http://sahilsk.github.io/articles/so-youre-writing-api-client/

하나하나 모든 요청에 다 응답할 수 없어서 그 사이에 API가 있는 것.

어떤 방식으로 정보를 요청해야하는지, 그런 요청을 보낼 때 어떤 형식/데이터를 받을 수 있는지 정리한 규격/약속!

요청과 응답을 주고받는 체계! 

즉! 프로그램들이 서로 상호작용하는 것을 도와주는 매개체.

https://developers.kakao.com/docs/latest/ko/kakaologin/common)

이런 디스크립션 자체가 API 규격이라고 보면된다. 로그인을 했을 때, 로그인해서 연결했을 때, 가입했을 때, 로그아웃 했을 때 어떻게 절자가 진행되는지 관련된 것을 API라고 하는 것 같다.

즉. API는 웨이터같은 느낌! 

 

API는 손님(프로그램)이 주문할 수 있게 메뉴(명령 목록)를 정리하고, 주문(명령)을 받으면 요리사(응용프로그램)와 상호작용하여 요청된 메뉴(명령에 대한 값)를 전달한다. 돔에서 컴포넌트의 역할과 비슷하구나..

 

다른 회사의 API를 우리 회사에 가져와서 구현시킬 수도 있다고 한다.

다른 회사 개발자도 사용할 수 있도록 만든 API → Open API

 

참고 사이트 1: https://yozm.wishket.com/magazine/detail/53/

참고 사이트 2: https://enjoyinjoanne.tistory.com/56

 

 

 

회사에서 API호출.. API를 불러와야한다는 말을 많이 듣게됐는데

이게 무슨 뜻인지 알아볼 생각을 하지 않았던 것 같다ㅋㅋㅋ 많이 사용되는 단어인만큼 알아야했었는데..

 

🤔API가 무엇인지 알겠어. 그렇다면 "API 호출해야 한다"는 뜻은 무슨 뜻일까?

관련된 브런치 포스팅이 있어 참고했다.

참고 사이트 1: 기획자인 내가 아직까지 API가 헷갈렸던 이유 - 이론

참고 사이트 2: 기획자인 내가 아직까지 API가 헷갈렸던 이유 - 실전

 

우리는 API를 사용 하기 전 꼭 지켜야할 조건/약속이 있다.

1) API URL

- 누구에게, 어떤 요청을 할 것인지 명시 (서버 주소/ 기능 이름)

2) 메서드: 요청의 종류 (4가지가 있으며 CRUD라고 불림)

      ① create(=POST): 서버에 데이터 생성하는 요청

         - 클라이언트 A 정보 → 서버 B 업로드 가능

       ② read(=GET): 서버에 데이터 불러오는 요청

         - create와 반대. 서버 B 정보  → 클라이언트 A로 가져옴.
       ③ update(PUT/PATCH): 데이터를 바꾸는 요청

         - 서버 B의 정보를 클라이언트 A가 다른 정보로 변경 가능.
       ④ delete: 데이터를 삭제하는 요청

         - 서버 B 데이터 삭제 가능

💡응용하기

👨‍💻이 API 메소드가 뭐죠?
😉create 입니다!

 

3) 헤더,바디,파라미터(매개변수)

우리가 이메일을 보낼때 " 저는 어느어느 회사의 누구누구입니다~ 이걸 요청하고싶은데요~" 이런식으로 보내는데

API요청할 때도 똑같다고 한다.

      ① Header(헤더) 내가 누구인지?

      ② Body(바디) 어떤 걸 요청할 것인지?

이렇게 적는데 여기서 알아야 하는 개념은 parameter, value.

 

＊parameter(파라미터): 비밀번호처럼 요청할때마다 값이 달라지는 항목.

ex. 비밀번호 = 파라미터 / 비밀번호 값 = value

 

4) 응답의 명시화

API는 체계를 정해놓은 거라 응답에도 정해진 방식이 있다고한다. 개발자가 정의해서 다 다르지만

API요청 시 성공 응답/ 실패 응답으로 나뉜다는 것은 정해져있는 거니까 알고가기!

 

 

그리고 실제로 API를 호출하는 포스팅을 통해 어떻게 API를 호출하는지 읽어봤다.

API호출하기 위해서는 애플리케이션을 등록해야하고

https://brunch.co.kr/@b30afb04c9f54dc/5

이런식으로 메서드를 선택하고 URL을 입력하는 가이드가 안내되고있다.

 

이런식으로 API 호출이 이루어지는구나. API관련해서 개발자가 이런 말을 하면 어느 정도 이해할 수 있지 않을까 예상해본다.

 

 

- DOM이란? 엘리먼트를 tree 형태로 표현한 것.

다른 설명에서 보면 DOM은 html문서를 객체로 표현한 것이라고도 한다.

출처: TCP school.com

추가적으로 DOM설명 포스팅도 참고해서 읽었다.

여러개의 설명을 다른 방식으로 읽어서 그런지 DOM의 구조 같은 걸 더 명확하게 할 수 있었다.

하지만 이론으로만 들어서그런지 완전하게 이해하진 못했다.

그냥 요정도로만 이해하고 넘어가야겠다.

참고 사이트: DOM은 정확히 무엇일까? 

 

 

✏️가상DOM(Virtual DOM)

- 리액트는 가상돔이다. 실제돔과 가상돔 형태는 똑같다.

실제 돔은 아니지만 객체형태로 저장할 수 있어 더 빠르게 조작할 수 있다고한다.

 

🤔실제 돔이 아닌데 가상돔으로 어떻게 화면이 바뀌는 건가요?

① 리액트는 2가지 버전의 가상DOM 가짐.

- 화면 갱신 전/후의 가상 DOM(갱신 후 과정이 리렌더링상태이며 이때 가상DOM만들게됨)
② diffing: 갱신 전,후 가상돔 비교해서 어느 엘리먼트에서 변화가생겼는지 빨리 파악.
③ 재조정(reconciliation): 변경된 부분만 실제 DOM에 적용시킴.

- 5개가 변경됐다면? 하나하나 변경X → 모아서 한 번에 변경!!! 이걸 Batch Update라고함.

 

 

✏️브라우저 렌더링(=페인팅)

- 리액트가 위의 단계를 거쳐 렌더링을 하면 그 다음은 브라우저 렌더링으로 이어진다.

(리액트)실제 돔 업데이트 → 브라우저 렌더링 엔진 → 화면 반영

<브라우저 렌더링 과정>

① 스타일 계산: html, css분석해서 스타일 계산.
② 레이아웃: 위치, 크기 계산
③ 페인팅: 2번단계를 바탕으로 화면에 나타냄.

 

브라우저 렌더링과 리액트 렌더링은 다르다!!!

 

 

 

🐬실습: 카운터 앱 만들기

갑자기 만들라니까 못하겠다.. 이래서 어떻게 하냐......?ㅠㅠㅠ

강사님의 문제풀이 영상을 먼저 보고 따라한 후 다시 혼자 실습해보는 시간을 가졌다.

 

import React, { useState } from "react";

const App = () => {
  const [number, setNumber] = useState(0);
  const onMinusButtonClick = () => {
    setNumber(number-1);
  }
  const onPlusButtonClick = () => {
    setNumber(number+1);
  }
  return (
    <div
      style={{
        display: "flex",
        flexDirection: "column",
        alignItems: "center",
      }}
    >
      <div>{number}</div>
      <div>
        <button onClick={onMinusButtonClick}>-1</button>
        <button onClick={onPlusButtonClick}>+1</button>
      </div>
    </div>
  );
};

export default App;

 

+버튼을 누르면 숫자가 1씩 추가되고

-버튼을 누르면 숫자가 1씩 줄어들게 만들었다.

 

 

 

✏️리팩토링

- 반복되는 컴포넌트 처리

- 컴포넌트 분리

 

이름.map() 안에는

이름.map(function () {}) 콜백함수가 들어가고 function다음 괄호에 있는곳엔 반복되는 요소에 대한 할당이 일어남. 

import { useState } from "react";

const App = () => {
  const vegetables = [`감자`, `고구마`, `오이`, `가지`, `옥수수`];


  return (
    <div style={{ padding: "20px", display: "flex", gap: "20px" }}>
      {vegetables.map((vegetableName) => {
        return (
          <div className="square-style" key={vegetableName}>
            {vegetableName}
          </div>
        );
      })}
    </div>
  );
};

export default App;

 

()map을 이용해서 배열을 순회하는 방법을 알게됐다.

css 스타일을 보다 효율적으로 쓰기 위해 좀 더 뒤에 있는 강의를 보며 따라해야겠다.

 

 

<객체로 이루어진 배열 map으로 반환하기>

import React from 'react';
import './App.css'; // 🔥 반드시 App.css 파일을 import 해줘야 합니다.

//  User 컴포넌트를 분리해서 구현
function User(props) {
  return (
    <div>{props.user.age}살 - {props.user.name}</div>
  );
}

const App = () => {
  const users = [
    { id: 1, age: 30, name: '송중기' },
    { id: 2, age: 24, name: '송강' },
    { id: 3, age: 21, name: '김유정' },
    { id: 4, age: 29, name: '구교환' },
  ];
  return (
    <div className="app-container">
      {users.map((user) => {
        return <User user={user} key={user.id} />;
      })}
    </div>
  );
};

export default App;

key: 엘리먼트 고유 식별자

- 동적인 리스트에서 엘리먼트 고유한 키값을 가져가야한다. (중복X)

- 일반적으로 map() 메서드와 함께 사용된다.

 

App에서 화면에 출력되는 모든걸 적으려 하지 말고

User컴포넌트에서 props해서 중괄호 이용해서 정보를 가져오고,

만들어진 User컴포넌트를 App return값의 태그형식으로 넣어서 그 속성만 조절하는 느낌!

이런식으로라도 외워야겠다..ㅋㅋ ㅠㅠ

 

 

여기서! 우리는 const users를 state형식으로 만들어서

렌더링될 수 있게 만들어줘야함.

그럴땐 필요한 건 뭐다? useState를 써줘야한다.

 

[value, setValue] = useState(); 를 사용해보자.

 

import { useState } from "react";

const [users, setUsers] = useState([
    {
      id: 1,
      age: 30,
      name: `송중기`,
    },
    {
      id: 2,
      age: 23,
      name: `한혜진`,
    },
    {
      id: 3,
      age: 35,
      name: "산다라박",
    },
    {
      id: 4,
      age: 36,
      name: `김우빈`,
    },
  ]);

  return (
    <div style={{ padding: "20px", display: "flex", gap: "20px" }}>
      {users.map((user) => {
        return <User key={user.id} user={user} />;
      })}
    </div>
  );


export default App;

const User = (props) => {
  return (
    <div>
      {props.user.age}살 - {props.user.name}
    </div>
  );
};

이렇게했더니 알 수 없는 오류가 떴다. ㅠㅠ 

다시 강의를 보고 따라해도 강사님은 되는데 나는 안됨... 일단 코드를 첨부했다.

 

우리가 엘리먼트에 고유 식별 id/key값을 넣어줘야하는 이유!

1,2,3,4라는 값이 있다고 치자. 이 배열의 length는 4이므로 하나 더 추가하면 4에서 +1이니까 5.

1,2,3,4,5에서 중간에 있는 값인 2를 삭제했다고 쳐보자.

그러면 1,3,4,5. 이것의 length역시 4인데 여기서 하나를 더 추가하면

1,3,4,5,5 이런식으로 문제가 생길 수 있다.

그렇기 때문에 우리는 해당 엘리먼트에 고유 id를 넣어줘야한다.

 

강사님께서는 날짜, 시간으로 분별할 수 있는 메서드를 넣고 혹시라도 같은 날짜, 같은 시간에 여러번 누를 것에 대비하여 +1처리를 해줬다.

 이런식으로. 

 

 

마지막 강의까지 모두 봤지만

진도가 너무 빨라요....

나머지는 내일 할 개인 프로젝트를 진행하며 공부해보기로 했다.

 

 

 

 

02 UX집중반: 쏘카 문제해결

팀 진행상황 보고 드립니당 
큰 방향성의 솔루션 정리 (완료)
가설 설정 (완료)
가설 근거 서치 (진행중)
<공지>
01/08 목요일 오후 4시에 피그마에 모여 못 한 부분 추가로 더 작업할 예정입니다!

 

<할 일 목록>
1. 가설 1번에 대한 근거 자료 수집
- 가설 1번 근거만 찾는 이유는 우선순위 1번째인 점, 그리고 시간상의 문제로 해당 근거를 우선적으로 찾아보기로 했습니다!
- 할 일: 사용자 핵심 행동, 비즈니스 목표, 특히 ㅈㅎ님께서 찾아주신 경쟁사 사례 데이터 서치

2. 장표 제작
- 디자인에 구애 받지 말고 합시당~!
- 할 일: 큰 방향의 솔루션, 가설 설정, 가설 근거, 구체적인 솔루션, 와이어프레임 (순서 논의 필요)

<작은 이슈>
어제 피드백 받은 대로 큰 방향성의 솔루션,  가설 설정 논의 중,
가설의 기준에 대해 명확하게 해결이 되지 않아서 가설 관련 질문을 위해 튜터님께 방문.
피드백1 : 가설은 최대한 명확하게 작성하는 게 좋다. 그래야 명확한 가설이 나올 것.
피드백2 : 규범화 된 프로세스(순서)에 얽매이지 않도록 주의하자.
ex) 꼭 가설을 '먼저' 설정하고 '솔루션'을 내야해. ❌
솔루션을 먼저 도출했네? 다음 이 문제를 어떻게 풀어야할까? 가설을 설정해보자! ⭕

 

 

오늘 UX집중반에 참여하지 못한 인원을 위해 정리한 dm인데

오늘은 체력이 없어서 이 정도로만 정리해야겠다.

 

 

 

 

 

마무리하며...

할 일이 왜 이렇게 많을까!

• 리액트 개인 프로젝트
• UX집중반
• 최종 프로젝트 계획

 

개인 노션도 정리하는 습관을 들이자

+ 시간을 잘 활용하자.. 요새 너무 풀어짐