React Navigation의 navigate()와 push()로 화면을 이동할 수 있다. 그래서 이 둘은 화면을 이동시켜준다는 점은 동일하다는 것!

둘 다 화면을 이동시켜준다고 생각해 나는 이 둘을 별다른 구분 없이 사용하곤 했었다. (뭔가 다름을 느꼈음에도 흐린눈했던 나 반성하자)

navigate()와 push()모두 새로운 화면으로 넘어갈 때는 크게 다를 점이 없었기에 혼동해 사용해왔던 것인데.. 이 둘은 같은 화면을 이동할 때 그 차이를 느낄 수 있다!

navigation.navigate('RouteName'); 
navigation.push('RouteName');

2. 🙅🏻‍♀️ 달라달라

(1) push()

아래의 이미지는 React Navigation 공식문서에서 설명한 push()를 사용했을 때의 경우이다. 여기서 확인할 수 있는 점은 다음과 같았다.

1. Home ➡️ Details ➡️ Details ➡️ Details 와 같이 스크린이 이동되고 있다.
2. 같은 Details 화면에서 Details 화면으로 이동하는 것임에도 화면전환 효과가 보인다.
3. 뒤로 가기를 눌렀을 때, 이전의 Details 화면들을 모두 지나야 Home 화면을 볼 수 있다.

이를 통해 push()는 어느 화면으로 이동하느냐에 상관없이 stack 구조에 차곡차곡 화면이 쌓인다는 것인다는 것을 알 수 있다.

Details ➡️ Details와 같이 같은 화면으로 이동할 때조차 각각의 Details화면이 stack에 순서대로 쌓이게 되고, 뒤로가기(pop())했을 때는 stack의 가장 위에서부터 하나씩 제거해나간다.

공식문서에서는 push()를 다음과 같이 요약하고 있다. 우리는 push를 우리가 원하는 만큼 호출할 수 있고, push는 계속해서 stack에 화면을 쌓아줄 것이라고!

📜 React Navigation We can call navigation.push('RouteName') as many times as we like and it will continue pushing routes.

(2) navigate()

navigate()는 새로운 화면으로 이동할 경우엔 push()와 동일하게 stack에 새로운 화면이 차곡차곡 쌓인다.

하지만 같은 화면으로 이동할 경우, 위의 push()와 같이 stack에 같은 화면이 쌓이지도, 화면 전환 효과가 보이지도 않는다. navigate()의 두번째 인자로 전달해주는 💥parameter값만 바꾸어 보여줄 뿐💥이다.

navigation.navigate('RouteName', { id : route.params.id })

Home ➡️ Details (id:1) ➡️ Details (id:2) ➡️ Details (id:3) 와 같이 이동한다고 했을때 stack에는 Home 화면 1개와 Details 화면 1개만 쌓이게 된다.

Details 화면은 paramerter값만 1, 2, 3으로 바뀌는 것이다. ❌Details 화면이 또다시 쌓이는 것이 아니라❌ 따라서, 가장 마지막 Details 화면(id:3)에서 뒤로 가기를 누르면 Home화면이 나오는 것을 볼 수 있다.

3. 📝 정리 및 느낀점

1. 새로운 화면 이동
   • navigate()와 push()모두 stack에 새로운 화면을 차곡차곡 쌓는다.
     
2. 같은 화면 이동 (A ➡️ A ➡️ B)
   • push()는 stack에 A, A, B화면이 순차적으로 쌓고, navigate()는 stack에 A, B화면을 쌓는다.
   • navigate()는 같은 화면을 이동할 경우 stack에 같은 화면을 또다시 쌓지 않고, parameter값만 변경해준다.

화면 이동이 필요한 경우, push()를 사용하면 어떤 화면이라도(같은 화면이라도) 항상 순차적으로 stack에 화면을 쌓아주기 때문에 뒤로 가기를 했을 때 내가 원하는 화면을 보여줄 가능성이 크다. 탭이동과 같은 화면 이동이 아닌 경우에는 push()를 사용해야겠다.

어영부영 잘 작동한다고 넘어가지 말고, 왜 화면 이동에push()가 아닌 navigate()를 사용했는지 설명할 수 있는 근거있는 개발자가 되자‼️

4. 📜 참고

• React Navigation Docs
• [React Navigation] 내비게이션 및 Hooks 익히기
• Understanding Ionic 2: Navigation with NavController

디자인 전공이라 그런지 프론트엔드 개발 공부를 하며 UI/UX 디자인에도 관심이 많았다. 하지만 제대로 알고 있지는 못했고, 어디서부터 알아가면 좋을지도 고민이었다. 그렇게 생각해낸 것은 바로 책!

'도널드노먼의 UX 디자인 특강'의 저자인 도널드 노먼은 UX의 창시자라고 한다. 그래서 이 책은 UX 디자인의 바이블과도 같다고...! 그래서 다른 최신책들보다도 이 책을 먼저 읽어보고 싶었다.

책만 읽고 모든 것을 알아가리란 안일한 생각은 하지 않는다. 그저 이 책을 통해 👀나의 시야를 확장👀시켜 더 넓은 시야로 세상을 바라보고 싶다.

메모

# 복잡함과 혼란스러움은 다르다

• 복잡함(complexity)은 실재의 상태, 혼란스러움(complicated)은 마음의 상태이다.
• 복잡함의 사전적 의미는 많은 부분이 뒤얽히고 서로 연결된 상태를 말한다.
• 복잡함은 이 세상의 일부이다. 하지만 그것이 우리를 헷갈리게 해서는 안된다.
• 우리는 덜 복잡한 것만 쫓기보다, 복잡함을 다스리는 쪽을 선택해야 한다.
• 결국 복잡함을 터득하는 핵심은 이해다.

# 인공적이고 인공적인 모든 것이 곧 기술이다

• 네트워크 및 기술이 발전할수록 우리는 지속적으로 복잡한 상호작용과 마주하게 될 것이다.

🤔 내 생각 끄적이기 🤔

기술이 발전할수록 복잡함이란 것은 뗄레야 뗄 수 없다는 것을 새삼 깨달았다. 초등학생 때 썼던 폴더폰과 지금 사용하고 있는 스마트폰을 비교해봐도 그렇다. 전화, 문자 메세지, 사진 찍기 정도만 가능했던 이전의 폴더폰과 달리, 지금의 스마트폰을 보면 사진 편집 기능, 인터넷, 다양한 서비스 등 정말 다양한 기능을 사용할 수 있게 됐다.
복잡할 수 밖에 없다. 다양한 기능이 계속해서 추가되고 있기 때문에. 하지만, 혼란스러워져서는 안된다. 혼란스러움은 헷갈리게 하는 복잡함이다. 그럼 복잡한데 헷갈리지 않기 위해선 어떻게 해야할까? 구조가 있어야 하고, 그 구조에 대한 이해가 뒷받침되어야 한다.
똑같아 보이기만 했던 복잡함과 혼란스러움의 차이를 이해할 수 있게 됐다.

# 복잡함이 단순함과 다른점

• 좋은 디자인은 사용자가 제품에 호감을 느끼고 사용하면 사용할수록 즐거운 감정을 이끌어낸다.
• 단순함과 복잡함 사이의 차이에는 구조가 있다.

# 복잡한 것들도 유쾌할 수 있다

• 야구규칙의 복잡함은 우리를 괴롭히지만 게임의 즐거움을 증가시키기도 한다.

# 습득보다는 터득이 중요하다 : 습득과 터득의 차이

• 우리는 무언가를 배우는 일이 적절한 행동이라고 생각했을 때 복잡함에 대해서는 신경 쓰지 않는다.
• 단지 애매하고 변덕스러운 무언가를 작동하는 방법을 배우느라 시간을 소모하는 게 싫은 것이다.

🤔 내 생각 끄적이기 🤔

지금까지 나는 디자인은 물론이고 사용자 경험에 있어서도 단순함 >>>>> 복잡함이라고만 생각했다. 누구나 복잡한 것보다 단순한 것을 원하지 않을까..라고 생각했다. 하지만 생각해보니 나조차도 복잡함을 추구하는 순간이 있었다.
최근 했던 다도 체험, 향수 만들기 체험 등만 놓고 봐도 그렇다. 그냥 다 만들어진 차를 사서 마셔도 되고, 완벽하게 세팅된 향수를 사서 뿌리면 된다. 근데 굳이 직접 만드는 복잡한 과정을 거치며 즐거움을 느꼈었다.
이 책에서 이야기하는 바도 이것과 같다. 복잡함의 과정 속에서 즐거움을 느낀다는 것이다. 무조건적으로 단순한 것만이 좋다고 말할 수 없겠다.
복잡함. 그 속에서의 구조를 잘 만들어내 사용자들이 혼란스러움을 느끼지 못하도록 하자!

출처

도널드 노먼의 UX 디자인 특강

🌱 NextJS의 기초를 다지고자 노마드코더의 NextJS입문 강의를 완강했다. 강의를 따라가며 공부한 내용을 기록해두고자 한다!

0. Creating a Project

TypeScript로 프로젝트를 시작하고자 한다면, --typescript를 추가해주면 된다.

npx create-next-app@latest
npx create-next-app@latest --typescript

1. Library vs Framework

(1) Library

👩🏻‍💻 Library는 개발자로서 내가 사용하는 것

• 내가 원하는대로 코드를 작성할 수도 있고, library를 사용하고 싶을 때 사용할 수도 있다.
• 대표적인 예는 React이다. React는 router를 만들든 component를 만들든 내가 코드를 작성하기 나름이고, 폴더명을 짓는 것에 있어서도 자유롭다. 자유도가 높다는 것을 알 수 있다!

(2) Framework

👩🏻‍💻 Framework는 나의 코드를 불러오는 것

• 코드를 적절한 위치에 잘 적기만 하면 Framework가 내 코드를 불러와서 모든 것을 동작하게 한다.
• 대표적인 예는 NextJS이다. Router 설정을 따로 하지 않아도 NextJS의 index.js에서 작성한 코드가 홈에 뜨는 것을 쉽게 확인할 수 있다.

2. Pages

💁🏻‍♀️ NextJS에서 페이지를 생성하려면? pages 폴더만 보면 된다!

• NextJS는 pages에 생성된 파일의 이름을 가져다가 URL의 이름으로 사용한다. (따라서 컴포넌트명은 중요하지 않다!)
• export default 컴포넌트이름 과 같이 default로 export를 꼭 해주어야한다는 것만 잘 지키자!
• 앱의 홈은 기본적으로 pages 폴더에 위치한 index.js가 나오게 되어 있다.

3. Static Pre Rendering

✨ NextJS의 가장 좋은 기능 중 하나는, 앱에 있는 페이지들이 미리 렌더링된다는 것이다.

(1) React (CSR)

CSR은 나의 브라우저가 UI를 만드는 모든 것을 한다는 것을 의미한다!

• 브라우저는 프론트 서버로부터 JavaScript를 전달받아 웹페이지 상의 모든 UI를 만들어낸다.
• create-react-app으로 React 프로젝트를 시작할 때를 생각해보자. index.html파일의 body태그에는 <div id="root"></div>밖에 없는 것을 볼 수 있다. 사실상 비어있는 div태그이며, 브라우저가 프론트 서버로부터 프론트 관련 소스(JavaScript파일 등)를 전달받아 UI가 그려진다.

(2) NextJS (SSR)

NextJS는 React.js를 백엔드에서 동작시켜서 페이지를 미리 만든다!

• NextJS는 초기 컴포넌트가 렌더링 된 HTML 파일을 먼저 받아 화면에 띄운다.
• 그러면 유저는 JavaScript 와 React.js가 로딩되지 않았더라도 콘텐츠를 먼저 볼 수 있게 된다.
• 그리고 React.js가 로딩되면, 이미 화면에 그려진 것들과 연결이 되어서 일반적인 React.js 앱이 되는 것이다.

4. Routing

✨ NextJS에 앱 내에서 페이지를 네비게이트할 때 사용해야만 하는 Link 컴포넌트가 존재한다. (따라서 a태그를 사용하면 경고표시가 뜬다!)

❓ *Link태그 사용하지 않으면? * 브라우저가 다른 페이지로 보내기 위해 전체 페이지를 새로고침하며, 이는 속도 저하를 야기한다.

import Link from "next/link";

export default function NavBar() {
  return (
    <nav>
      <Link href="/">Home</Link>
      <Link href="/about">About</Link>
    </nav>
  );
}

5. CSS Modules

(1) 사용법

• CSS Modules을 사용해 클래스 이름을 추가할 때, 클래스 이름을 텍스트로서 적지 않는다. 자바스크립트 오브젝트에서의 프로퍼티 형식으로 적는다.

import styles from "./NavBar.module.css";

export default function NavBar() {
      return (
        <nav className={styles.nav}>
          // 생략
        </nav>
      );
}

(2) 장점

• 클래스이름이 자동적으로 생성됨에 따라 충돌이 일어나지 않는다.
• 이는 다른 컴포넌트에서도 같은 클래스 이름을 사용할 수 있다는 것을 의미한다.

6. Styles JSX

<style>{`
    nav {
        background-color: tomato;
    }
    a {
        text-decoration: none;
    }
    .active {
        color: ${props.color};
    }
`}</style>

7. Custom App

(1) page 초기화의 효과

NextJS는 App 컴포넌트를 사용하여 page를 초기화한다. 이는 다음과 같은 효과가 있다.

1. 페이지 변경 간에 레이아웃 유지
2. 페이지 탐색 시 state 유지
3. componentDidCatch를 사용한 Custom 에러 처리
4. 페이지에 추가 데이터 삽입
5. Global CSS 추가

(2) App 재정의하는 법

• 기본 App을 재정의하려면 ./pages/_app.js 파일을 만든다.
• 그러면 NextJS는 index.js를 렌더링하기 전에 _app.js을 보고 내용물을 렌더링한다. 그 뒤, index.js의 내용물을 렌더링한다.

export default function MyApp({ Component, pageProps }) {
  return (
    <>
      <NavBar />
      <Component {...pageProps} />
      <style jsx global>{`
        a {
          color: white;
        }
      `}</style>
    </>
  );
}

8. Patterns

• custom app component를 사용할 때 Layout 패턴을 사용한다.
• 아주 큰 리액트 App 컴포넌트를 사용하기 보다는, Layout component를 만들어 사용해주는 것이다.
• children은 React가 제공하는 prop으로, 하나의 component를 또 다른 component 안에 넣을 때 사용할 수 있다.

(1) 예시

Layout 컴포넌트를 만들어 App 컴포넌트에 적용시켜준다.

// Layout 컴포넌트
import NavBar from "./NavBar";

export default function Layout({ children }) {
  return (
    <>
      <NavBar />
      <div>{children}</div>
    </>
  );
}

// _app 컴포넌트
import Layout from "components/Layout";

export default function MyApp({ Component, pageProps }) {
  return (
    <Layout>
      <Component {...pageProps} />
    </Layout>
  );
}

(2) 예시

NextJS에서 제공하는 Head 컴포넌트를 사용해 페이지를 이동할 때마다 해당 title이 나타나게 만들어준다. 다음 이미지는 About 페이지로 이동했을 때의 모습이다.

// Seo.js
import Head from "next/head";

export default function Seo({ title }) {
  return (
    <Head>
      <title>{title} | Next Movies</title>
    </Head>
  );
}

// About.js
import Seo from "components/Seo";

export default function about() {
  return (
    <div>
      <Seo title="Home" />
      <h1>About</h1>
    </div>
  );
}

9. Redirect and Rewrite

(1) Redirect

• redirect를 이용해서 한 페이지에서 다른 페이지로 이동하게 할 수도 있고, 아예 다른 URL의 웹사이트로 이동하게 할 수도 있다.

• /old-blog/포스트숫자를 url에 입력하면, /new-sexy-blog/포스트숫자로 이동하는 것을 확인할 수 있다.
• :path* 와 같이 뒤에 별표를 붙여주면 /old-blog/1212/comments/122 와 같이 뒤에 오는 모든 경로를 다 잡아낸다.

module.exports = {
  reactStrictMode: true,
  async redirects() {
    return [
      {
        source: "/old-blog/:path*",
        destination: "/new-sexy-blog/:path*",
        permanent: false,
      },
    ];
  },
};

(2) Rewrite

• redirects는 old-blog로 접속할 때, 유저가 url이 바뀌는 것을 볼 수 있다. (new-sexy-blog로!)

• rewrites는 유저를 redirect시키기는 하지만, url은 변하지 않는다!
• 설정한 source를 통해 destination에 접근할 수 있다! (ex)fetch("/api/movies")

const API_KEY = "0123456789";

module.exports = {
  reactStrictMode: true,
  async redirects() {}, // 생략
  async rewrites() {
    return [
      {
        source: "/api/movies",
        destination: `https://api.themoviedb.org/3/movie/popular?api_key=${API_KEY}`,
      },
    ];
  },
};

(3) API key 숨기기

• .env 파일 생성하고 가져다가 쓰면 된다.

• gitignore 됐는지 확인할 것!

// .env 파일
API_KEY=0123456789

// next.config.js
const API_KEY = process.env.API_KEY;

10. Server Side Rendering

(1) getServerSideProps 함수

💥 서버에서만 실행되는 함수임

• getServerSideProps 함수는 오직 백엔드(서버)에서만 실행된다.
• 따라서, getServerSideProps 함수에 API key를 써주면 client한테 보여지지 않는다.

🎁 props란 key를 갖는 객체를 return함

• getServerSideProps는 props라는 key를 갖는 object를 return한다.
• props라는 key에는 원하는 데이터를 넣을 수 있다.
• 이로써 원하는 데이터를 props로 page에게 전달 할 수 있다.

// index.js
export default function Home({ results }) {
  // 생략
}
export async function getServerSideProps() {
  const { results } = awiat(await fetch("/api/movies")).json();
  return {
    props: {
      results,
    },
  };
}

(2) SSR vs. CSR

• Server Side Rendering으로 렌더링되는 상태에선 API가 호출되기 전까지 아무것도 화면에 보이지 않을 것이다.

• 데이터가 유효할 때 화면을 보여주는 것(SSR)이 좋은 지, loading 화면을 보여준 뒤 데이터를 받는 것(CSR)이 좋은지는 나의 선택이다.

• SSR 방식은 해당 페이지의 데이터가 들어오기 전까진 아무것도 볼 수 없다가 해당 페이지의 데이터만 들어오면 전체를 다 볼 수 있다. (다른 페이지를 갈 때도 이 과정이 필요하다.)

• CSR 방식은 모든 JS파일들이 들어와야 (’Loading…’) 보여지는데, 그 대신 다른 페이지를 갈 때는 이미 JS 파일들을 받았으니 SSR 방식보다는 빠르게 화면을 볼 수 있다.

11. Dynamic Routes

❓ URL에 변수를 넣는 방법

• pages폴더에 movies 폴더 생성해준 뒤 [id].js파일 생성
• 이름 짓는 것은 자유다. 대괄호만 잘 작성해주기!

12. Detail

(1) Link로 navigating

<Link href={`/movies/${movie.id}`}>{movie.original_title}</Link>

(2) 이벤트 발생 시 navigating

// index.js
export default function Home({ results }) {
    const router = useRouter();
    const onClick = (id) => {
        router.push(`/movies/${id}`);
    };

    return (
    {results?.map((movie) => (
       <div onClick={() => onClick(movie.id)} className="movie" key={movie.id}>
           {/* 생략 */}
       </div>
    ))
    )
}

(3) URL에서 URL로 state 넘기기

• 아래와 같이 router를 설정하면, 영화 상세보기 시에 url이 다음과 같이 나오는 것을 볼 수 있다. http://localhost:3000/movies/315162?id=315162&title=potatos

• router의 2번째 속성인 as는 브라우저의 URL을 마스킹한다. , 뒤에 브라우저에 보일 URL을 작성하면 된다.
• router.query.title은 유저가 홈→상세로 넘어올 때만 존재한다.

// index.js Home컴포넌트
const onClick = (id, title) => {
  router.push(
    {
      pathname: `/movies/${id}`,
      query: {
          title: title,
      },
    },
    `/movies/${id}`
  );
};

// [id].js
export default function Detail() {
      const router = useRouter();
      console.log(router);
      return (
        <div>
          <h4>{router.query.title || "Loading..."}</h4>
        </div>
      );
}

13. Catch All

• catch-all URL은 뭐든 캐치해내는 URL이다.

• router.query.params || []와 같은 처리를 해주는 이유
  • 홈페이지를 거쳐서 가는것이 아니라 바로 상세페이지로 가면, 서버는 영화에 대한 정보를 모르기 때문에 error 발생

// index.js
export default function Home({ results }) {
  const router = useRouter();
  const onClick = (id, title) => {
    router.push(`/movies/${title}/${id}`);
  };
  return (
        <Link href={`/moives/${movie.original_title}/${movie.id}`}>
       {movie.original_title}
    </Link>
    )
}

// [...params].js
export default function Detail() {
  const router = useRouter();
  const [title, id] = router.query.params || [];

  return (
    <div>
      <h4>{title}</h4>
    </div>
  );
}

기계가 실행할 정도로 상세하게 요구사항을 명시하는 작업이 프로그래밍이고, 이렇게 명시한 결과가 바로 코드이다.

따라서 코드가 사라질 가망은 전혀 없다! 궁극적으로 코드는 요구사항을 표현하는 언어이기 때문이다. 어느 수준에 이르면 코드의 도움 없이 요구사항을 상세하게 표현하는 것은 불가능하다.

🙅🏻‍♀️ 나쁜 코드

가지각색의 이유로 누구나 대충 프로그램을 짠 경험이 있다. 대충 짰어도 프로그램이 돌아간다는 사실에 안도감을 느끼곤 하는데. 다시 돌아와 나중에 정리하겠다고 다짐하곤 한다. 하지만 나중은 결코 오지 않는다.

⏳ 나쁜 코드로 치르는 대가

나쁜 코드는 결국 나쁜 코드를 더 많이 양산한다. 이에 따라 개발 속도를 크게 떨어뜨려 생산성은 점점 0에 수렴한다.

태도

좋은 코드를 사수하는 일은 바로 우리 프로그래머들의 책임이다. 나쁜 코드의 위험을 이해하지 못하는 관리자 말을 그대로 따르는 행동은 전문가답지 못하다.

기한 vs. 좋은 코드

기한을 맞추기 위해, 빨리 가기 위해 시간을 들이지 않는다. 하지만 기한을 맞추는 유일한 방법은 코드를 최대한 깨끗하게 유지하는 습관이다.

🧼 깨끗한 코드란?

• '보기에 즐거운' 코드

• 세세한 사항까지 꼼꼼하게 처리하는 코드
  • 오류 처리, 메모리 누수, 경쟁 상태, 일관성 없는 명명법 등
• 한 가지에 '집중'하는 코드
  • 함수, 클래스, 모듈의 의도가 뒤섞이거나 목적이 흐려지지 않도록
• 사실에 기반하여 반드시 필요한 내용만 담은 코드
• 다른 사람이 고치기 쉬운 코드
• '주의 깊게' 작성한 코드
  • 누군가 시간을 들여 깔끔하고 단정하게 정리한 코드
• 한 가지 기능만을 수행하고, 중복을 줄이고, 제대로 표현하고, 작게 추상화한 코드

🧺 보이스카우트 규칙

캠프장은 처음 왔을 때보다 더 깨끗하게 해놓고 떠나라

• 코드는 시간이 지나도 언제나 깨끗하게 유지해야 한다.
• 지속적인 개선이야말로 전문가 정신의 본질이다!

👩🏻‍💻 결론

예술에 대한 책을 읽는다고 예술가가 되라는 보장이 없듯이 이 책을 읽는다고 뛰어난 프로그래머가 된다는 보장은 없다.

뛰어난 프로그래머가 생각하는 방식과 그들이 사용하는 기술과 기교와 도구에 대한 소개만 있을뿐 나머지는 나에게 달렸다! 연습하자!

✍🏻 비동기적으로 동작하는 useState를 알기 위해선 useState에 해당되는 Hook이 무엇인지 알아야 했다. Hook이 무엇인지를 알고자 하니 Side Effect를 이해해야 했다.
🌊 따라서 Side Effet부터 Hook, useState까지의 흐름을 그대로 타고 내려가며 최종적으로 비동기적으로 작동하는 useState까지 정리해보고자 한다!

Side Effect

❓ React 컴포넌트가 화면에 처음으로 렌더링된 이후에, 비동기적으로 처리되어야 하는 부수적인 효과들을 Side Effect라고 부른다.

비동기적으로 처리되어야 하는 부수적인 효과..? 완전히 와닿지 않을 수 있으니 예시를 들어보자!

React 컴포넌트에서 외부 API를 호출할 때, 화면에 그려주는 것들을 먼저 렌더링해준 뒤, 📫실제 데이터📫는 비동기로 가져오는 것이 권장된다. API 응답이 늦어지거나/없을 때의 영향을 최소화하기 위해 🎨_화면에 그려주는 작업_🎨을 먼저 하는 것이다.

이 때의 Side Effect는 📫실제 데이터📫를 받아오는 작업이 될 수 있겠다. (첫 렌더링 후, 비동기적으로 처리되어야하는 작업이니까!)

Hook은 이런 Side Effect를 수행하는 역할을 한다.

Hook

❓ Hook이란?

Hook은 React v16.8부터 새로 추가되었다. (22년 3월에 React v18이 출시된 상태)

함수형 컴포넌트에서 사용되는 기술을 Hook이라고 생각하면 되는데.

함수형 컴포넌트에서 상태관리를 할 수 있게 하는 useState, 렌더링 직후의 작업을 설정하는 useEffect가 Hook에 속한다.

🤷🏻‍♂️ 클래스형에서 함수형으로 굳이?

함수형 컴포넌트에서 사용되는 기술이 Hook이라고 했다. 그럼 클래스형으로 잘만 써왔는데 왜 굳이 함수형으로 바꿔 Hook을 사용해야 하는걸까란 의문이 생긴다.

우선 클래스는 진입장벽이 높다. this 등 기본적인 JavaScript 문법을 알아야 하며, 코드의 재사용성과 코드 구성을 어렵게 한다. 그리고, React 최신 기술의 적용이 효과적이지 않다.

이런 클래스의 단점을 🚀함수형 컴포넌트로 극복🚀할 수 있다. 하지만, 클래스형 컴포넌트의 장점이었던 _state 사용_이나 _Life Cycle_을 직접 다루는 기능을 사용하지 못한다는 단점이 있었다. 이를 해결하기 위해 등장한 것이 바로 Hook이다.

useState

setState()호출 후 state가 바로 업데이트되지 않는 이슈를 겪은 적이 있을 것이다. React를 배운 지 얼마되지 않았을 때 나도 굉장히 당황스러웠던 부분이었다.

이건 useState()가 비동기적으로 동작했기 때문이었다! 근데.. 그래서 비동기적인게 뭔데..?

✅ useState과 setState 제대로 구분하고 있는지 CHECK! useState : state의 초기값 설정 & return 값으로 state, setState를 돌려주는 hook setState : state의 값을 변경할 때 사용하는 함수

😤 동기, 비동기가 뭔데!

헷갈리면 동기적으로 === 순차적으로라고 기억하면 편하다👍🏻

1. 동기

사장님 혼자만 있는 👦🏻개인카페👦🏻라고 생각하면 쉽다. 직원이 없으니 주문과 음료 제조를 동시에 처리하기 불가능할 것이다. 이렇게 동시에 작업을 처리하지 않고 순차적으로 처리하는 것이 동기적으로 처리하는 것이다.

2. 비동기

동기 처리와 다르게 직원이 많은 👨‍👨‍👧‍👦프렌차이즈 카페👨‍👨‍👧‍👦를 생각하면 된다. 주문 받는 것과 음료 제조를 동시에 처리할 수 있을 것이다. 이렇듯 한 가지 일을 처리하는 동안 다른 작업이 기다리지 않고 동시에 수행하는 것을 비동기적으로 처리한다고 한다.

📝 비동기 동작 예시

아래의 코드를 보면 증가 버튼을 누를 때마다 count가 1씩 증가할 것이다.

하지만, console에 찍히는 값을 보면 증가시키기 이전의 상태 값을 출력하는 것을 볼 수 있다.

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

  const handleClick = () => {
    setCount(count + 1);
    console.log(count);
  };

  return (
    <>
     <div>현재 값 {count}</div>
     <button onClick={handleClick}>count+</button>
    </>
  );
}

💥 비동기적으로 동작하는 이유

1. state가 리렌더링 발생시킴

useState가 비동기적으로 동작하는 이유는 state와 연관이 깊다. state는 값이 변경되면 리렌더링이 발생한다는 특징이 있다.

근데... 만약 값이 변경되는 state가 100개 있다면? React는 매번 렌더링만 하다가 생을 마감할 것이다.

2. 해결방법

따라서 React는 렌더링을 줄이고자 상태값이 변한 state를 모두 취합(배치, Batch)한 후에 한 번에 렌더링이 되도록 한다.

🎀 배치(Batch)?

• React가 너 나은 성능을 위해 여러개의 state 업데이트를 하나의 리렌더링으로 묶는 것
• 16ms마다 변경된 상태값을 모아서(merge) 이전의 Element Tree와 변경된 state가 적용된 Element Tree를 비교하는 작업(reconciliation)을 거쳐 최종적으로 변경된 부분만 DOM에 적용시킨다.
• state도 결국 객체다. 상태값이 모아지는 merge 단계에서 같은 키 값을 가진 state들이 있다면 가장 마지막 실행값으로 덮어씌워진다.

3. 효과

앞서 이야기 한 배치(Batch)와 같은 과정을 통해 100번의 상태값 변화를 단 1번의 렌더링으로 최신의 상태로 업데이트할 수 있게 된 것이다.

✨ 동기적으로 처리할 수 있는 방법

이처럼 비동기적으로 동작하는 setState를 동기적으로 처리할 수 있는 방법에는 아래와 같이 2가지의 방법이 있다.

1. useEffect의 의존성 배열 이용

2. 함수형 업데이트

// 이전
setCount(count + 1);

// 이후
setCount((prevCount) => prevCount + 1);

결론

💁🏻‍♀️ useState가 비동기적으로 동작하는 이유는, 렌더링 횟수를 줄여서 더 빠르게 동작하게 하기 위해서다.

참고

이 글은 아래의 글을 바탕으로 공부하며 개인적으로 정리한 글입니다.

• React(23) 리액트 훅이란?
• React - setState가 비동기인 이유

기업협업 프로젝트를 하며 💥CORS에러💥를 마주쳤던 경험이 있었다. 프론트엔드 개발자라면 꼭 마주치게 되는 에러 중 하나라는 것을 알게되었는데.. 그래서 꼭 제대로 정리해두고 기억해두고 싶은 내용이라 기록을 남긴다.
CORS에러가 무엇인지에서부터 나는 어쩌다 마주친 CORS에러를 어떻게 해결할 수 있었는 지까지 정리해봅시당♪(´▽｀)

CORS가 뭐지?

CORS는 Cross-Origin Resourse Sharing(교차 출처 리소스 공유)의 줄임말이다. 따라서 CORS에 대해 이해하기 위해선 Cross-Origin(교차 출처)이 무엇을 뜻하는 지에 대해 먼저 짚고 넘어가는 것이 좋겠다.

❔ Origin

Cross-Origin Resourse Sharing에서 Origin(출처)은 URL에서 프로토콜, 도메인, 포트를 모두 합친 것을 의미한다. 아래와 같은 URL에서 프로토콜, 도메인, 포트는 어느 부분일까?

URL | https://hyerin.com:3000/posts/0426?data=898

• 프로토콜 : https://
• 도메인 : hyerin.com
• 포트 : :3000

❓ Cross-Origin

Origin이 무엇인지에 대해는 이제 알았다. 그럼 Cross-Origin은 무슨 의미일까? Cross-Origin이란 아래 중 한 가지라도 다른 경우를 말한다.

• 프로토콜 : http와 https같이 다른 프로토콜

• 도메인 : domain.com와 other-domain.com 같이 다른 도메인
• 포트 : 8002포트와 3000포트 같이 다른 포트

🤷🏻‍♀️ 그래서 CORS가 뭔데?

브라우저에서는 보안상의 이유로 cross-origin HTTP 요청(GET, POST등)을 제한한다. 그래서 cross-origin 요청을 하기 위해선 ⭕서버의 동의⭕가 필요하다.

만약 서버가 동의한다면 브라우저에서는 요청을 허락하고, 동의하지 않는다면 브라우저에서 거절한다.

이렇게 허락을 구하고 거절하는 과정은 HTTP-header를 통해 가능한데, 특별한 헤더인 Access-Control-Allow-Origin를 응답에 추가하면 된다.

이러한 정책을 CORS(Cross-Origin Resourse Sharing, 크로스 오리진 리소스 공유)라고 한다.

🔎 CORS가 탄생한 이유

결론부터 말하자면 CORS는 악의를 가진 해커로부터 인터넷을 보호하기 위해 만들어졌다.

CORS는 악의를 가진 해커로부터 인터넷을 보호하기 위해 만들어졌다.

CORS라는 정책 없이 누구나 데이터를 요청할 수 있다고 가정해보자. 그렇다면 😈원래 있던 기존의 사이트와 똑같은 사이트를 만들어, 사용자의 로그인을 유도해 정보를 추출해가는 것😈은 식은 죽 먹기일 것이다!

따라서, CORS는 필요한 경우에만 서버에 요청이 가능하게 하여 인터넷을 보호하기 위해 필요하다.

CORS 동작원리

1. Preflight Request

Preflight 요청은 웹 개발 시 가장 자주 마주치게 되는 시나리오다. 브라우저는 본 요청을 보내기 전, 이 요청이 안전한 것인지 확인하기 위해 예비 요청과 본 요청으로 나누어 서버에 전송한다.

🤷🏻‍♀️ Preflight란? 브라우저가 본 요청을 보내기 전에 보내는 예비 요청을 Preflight라고 부른다.

🚚 동작과정

1. fetch API등을 통해 브라우저에게 데이터를 받아오라 명령함
2. 브라우저는 서버에게 예비 요청(Preflight)을 먼저 보냄
3. 서버는 이에 대한 응답으로 자신이 어떤 것들을 허용하고 금지하는지에 대한 정보를 응답 헤더에 담아 브라우저에게 다시 보냄
4. 브라우저는 자신이 보낸 예비 요청(Preflight)과 서버가 응답에 담아준 허용 정책을 비교함
5. 안전하다고 판단되면 다시 본 요청을 보냄
6. 서버가 본 요청에 대한 응답을 하면 최종적으로 응답 데이터를 JavaScript에 넘겨줌

2. Simple Request

대부분의 경우 preflight 방식을 사용하지만, 특정 조건들이 전부 만족된 경우 예비 요청 없이 본 요청만으로 CORS 정책 위반 여부를 검사할 수도 있다.

🚚 동작과정

1. fetch API등을 통해 브라우저에게 데이터를 받아오라 명령함
2. 브라우저는 서버에게 바로 본 요청을 보냄
3. 서버는 이에 대한 응답으로 Access-Control-Allow-Origin과 같은 값을 보내줌
4. 브라우저가 CORS 정책 위반 여부를 검사함 (Preflight와 전반적인 과정은 동일하고, 예비 요청의 존재 유무만 다르다!)

그러면 만족해야하는 조건들에는 어떤 것들이 있을까? 아래의 조건을 모두 만족해야만 예비 요청의 과정이 생략될 수 있다.

🤢 만족해야하는 조건들

1. 요청 메소드가 GET, POST, HEAD 중 하나여야 함.
2. Accept, Accept-Language, Content-Language, Content-Type, DPR, Downlink, Save-Data, Viewport-Width, Width를 제외한 헤더를 사용하면 안됨
3. 만약 Content-Type를 사용하는 경우에는 application/x-www-form-urlencoded, multipart/form-data, text/plain만 허용됨.

그런데 아래의 조건들 중에서도 2번과 3번이 까다로워 만족시키기 어렵다고 한다. 왜냐하면 사용자 인증에 사용되는 Authorization나 application/json과 같은 콘텐츠 타입도 사용하면 안되기 때문..

따라서 이러한 조건을 모두 만족시키기 어렵기 때문에 본 요청을 바로 보내는 Simple Request보다 예비 요청을 먼저 보내는 Preflight Request를 더 자주 접할 수 있는 것이다.

CORS 해결방법

1. Chrome 확장 프로그램

처음에 CORS에러를 마주쳤을 때 임시방편으로나마 사용했던 방법이다.. 바로 Chrome에서 제공하는 확장 프로그램 Allow CORS를 설치하는 것!

로컬 환경에서는 CORS에러를 해결할 수 있을 것이다. 하지만, 서비스를 로컬 환경에서만 돌리는건 아니니.. 사실상 근본적인 문제를 해결해주지는 못한다. (그것도 모르고 해결했다고 좋아했다가 바로 지웠던 기억이..😂)

2. Proxy 서버 이용

📒 Proxy가 뭔가요? 프록시(Proxy)란 클라이언트와 서버 사이의 서버 대리점 역할을 한다고 보면 된다.

서버에 따로 설정을 안한 상태에서, 클라이언트가 서버에 리로스 요청을 한다면 CORS 에러가 발생할 것이다.

이런 경우, 모든 출처를 허용한 서버 대리점인 프록시(Proxy) 서버를 통해 요청을 하면 되는 것이다! 하지만, 무료 프록시(Proxy) 서버 대여 서비스들은 악용 사례가 있어 직접 프록시(Proxy) 서버를 구축하여 사용해야 한다.

내가 기업협업 프로젝트에서 마주한 CORS에러도 프록시(Proxy)서버를 통해 해결할 수 있었다.

3. 서버에서 Access-Control-Allow-Origin 헤더 세팅

📜 CORS 해결의 정석 직접 서버에서 HTTP 헤더 설정을 통해 출처를 허용하게 설정하는 가장 정석적인 해결책이라고 한다.

서버의 종류마다 해결방법이 있는 것처럼 보이는데. 프론트 단에서 해결할 수 있는 방법에 대한 이야기는 아니기에 이에 대한 내용은 추후에 차차 알아가보고 싶다. (삐약삐약거리는 나로서..모르겠어요.그냥 모르겠어요..ㅎ)

나의 경험에 대하여

💬 내가 CORS에러를 마주했던 경험에 대한 이야기를 잠깐 하고 글을 마무리하려고 한다. 기업협업 프로젝트 당시 이 에러로 하루종일 애를 먹었었기에..ヽ(*。>Д<)o゜

💥 문제상황

Next.js로 개발을 하던 도중, CORS에러를 마주쳤다. Next.js의 getSeverSideProps()로 API 호출을 하지 않고, 전역 상태 라이브러리 MobX store에서 API 호출해 데이터를 받아와야하는 상황이었다.

store에서 API를 호출해 데이터를 받아오는 함수를 만들어주었다. 그리고 받아온 데이터를 사용할 컴포넌트에서 해당 함수를 호출해 데이터를 사용하고자 했다.

// BrandStore.jsx
getModalBrandList = async () => {
  // 데이터 받아오기
  try {
      const res = await axios({
        method: 'get',
        url: 'http://example.co.kr:8000/brands/all',
      });

      if (res.status === 200) {
        runInAction(() => {
          this.modalBrandList.data = res.data.results;
        });
      }
    } catch (err) {
      console.log(err);
    } finally {
      return this.modalBrandList;
    }
};

// BrandModal.jsx
useEffect(() => {
    getModalBrandList();
}, []);

그랬더니 Access to XMLHttpRequest at 'API 호출 주소' from origin 'http://localhost:3000'has been blocked by CORS policy란 error 메시지를 확인할 수 있었다. 개발자도구의 Network탭에서도 마찬가지로 CORS에러인 것을 확인할 수 있었다.

💢 원인

🤦🏻‍♀️ 그럼 SSR에선 왜 되는건데!!

가장 의문이 들었던 점은 getSeverSideProps()로 API를 호출했을 때는 CORS 에러가 발생하지 않는다는 것이었다.

알고보니 SSR는 브라우저를 거치지 않고 프론트 서버에서 백엔드 서버로 요청을 보내는 것이기 때문에 브라우저의 개입이 없어 CORS 에러가 발생하지 않았던 것이다!

🎀 해결방법

직접 프록시(Proxy)서버를 구축하지 않아도 몇 줄의 코드로 경로를 우회시킬 수 있다니 너무 신기했다.. 갓넥스트✨

• Next.js에서 Proxy 설정을 해주려면 아래의 코드만 작성해주면 된다😱

• 이는 Next.js 공식문서를 통해 쉽게 확인하여 적용시킬 수 있다.
• rewrites는 URL 프록시 역할을 한다는 점!

// next.config.js
module.exports = {
    async rewrites() {
        return [
            {
                source: "/:path*", // 들어오는 요청 경로 패턴
                destination: "http://localhost:5000/:path*", // 라우팅하려는 경로
            },
        ];
    },
}

❓ 프론트에서 해결하는 이유? 서버에서 Access-Control-Allow-Origin 헤더를 세팅하는 방법도 있다는 것을 알았기 때문에 프론트 단에서 이를 해결한 이유에 대해 궁금해 프론트 사수분께 이를 여쭤보았다.
서버에서 CORS에러에 대한 문제를 해결하는 방법도 있지만, 만약 서비스가 배포된 상태라고 할 때, 수정이 어렵기 때문에 프론트 단에서 이를 해결해준 것이라는 답변을 얻을 수 있었다.

배운점

⭐ CORS에러는 브라우저에서만 발생

🤦🏻‍♀️ SSR과 CSR의 방식에는 백엔드 서버로부터 데이터를 호출하는 주체가 다르기 때문에 SSR의 방식에선 CORS에러가 발생하지 않고, CSR 방식에서 CORS에러가 발생한다는 것을 알게 되었다.
💁🏻‍♀️ 결론부터 말하자면, SSR은 프론트 서버가 백엔드 서버에 데이터를 요청하는 반면 CSR에선 클라이언트(브라우저)에서 백엔드 서버에 데이터를 요청한다.

(1) SSR (Server Side Rendering)

전통적인 SSR 방식은 클라이언트 - 프론트 서버 - 백엔드 서버 간의 통신 순서를 지킨다.

1. 웹사이트 접속
2. 프론트 서버가 백엔드 서버한테 데이터를 요청
3. 프론트 서버는 백엔드 서버로부터 전달받은 데이터를 HTML, CSS, JS와 같은 프론트 소스와 함께 클라이언트에게 응답

(2) Client Side Rendering (CSR)

반면에, CSR은 SSR과는 다른 방식으로 통신이 진행되며 다음과 같다.

1. 웹사이트 접속 & 클라이언트가 백엔드 서버로 직접 데이터 요청
2. 프론트 서버로부터 프론트 관련 소스만 응답받음 & 클라이언트가 백엔드 서버로부터 데이터 응답받음

🌍 브라우저가 보내는 요청

🤷🏻‍♀️ 그럼 왜 브라우저가 보내는 요청은 그 출처가 다른걸까?

대부분의 브라우저는 요청을 보낼 때 해당 요청이 안전한지 확인하기 위해 미리 찔러보는 작업을 한다고 한다.

바로 미리 요청을 보내보는 것인데, 이를 Preflight(프리플라이트)라고 한다. _(위의 'CORS 동작원리'에서 다루었던 Preflight Request와 Simple Request 떠올리기!)_

이 때, 서버에서 올바른 응답을 하더라도 응답 header에 Access-Control-Allow-Origin이 없거나, 설정된 Access-Control-Allow-Origin의 값이 요청을 보낸 클라이언트의 도메인과 다르면 브라우저에서 자체적인 오류를 발생시커 요청을 진행하지 않는다고 한다.

📜 참고

이 글은 아래의 글을 바탕으로 공부하며 개인적으로 정리한 글입니다. 이미지에 대한 출처는 아래의 포스팅에 있습니다.

• https://ko.javascript.info/fetch-crossorigin
• https://it-eldorado.tistory.com/163
• https://hannut91.github.io/blogs/infra/cors
• https://jjnooys.medium.com/web-hello-cors-f8cfe39d9265
• https://velog.io/@wiostz98kr/CORS%EC%9D%98-%EB%AA%A8%EB%93%A0-%EA%B2%83

⚡ Chrome에서 제공하는 웹사이트 성능 측정 도구, LightHouse를 사용해서 성능 최적화를 해봤다. 2차 프로젝트에 적용했으며, 18점까지도 내려갔던 점수를 90점 이상까지 끌어올릴 수 있었다.

0. lighthouse 결과항목 분석

우선 lighthouse에는 다음과 같은 항목이 존재한다. 항목 별 점수를 모두 90점 이상으로 끌어올리는 것이 목표였다.

1. ✔ Performance
   • 웹 페이지의 로딩 속도 등 실제 성능을 측정한다.
2. 🐾 Accessibility
   • 웹 페이지의 접근성을 측정한다.
3. 🧾 Best Practices
   • 웹 페이지가 웹에 대한 표준 모범 사례를 따르고 있는지 확인한다.
4. 🔎 SEO (Search Engine Optimization)
   • 검색 엔진 수집 최적화가 된 정도를 측정한다.
5. 📱 PWA (Progressive Web App)
   • 해당 웹사이트가 모바일 애플리케이션으로도 잘 작동하는지 확인한다.

1. 📸 이미지 용량 줄이기

(1) 문제상황

성능 최적화를 진행한 Main 페이지에는 크기가 큰(용량도 큰) 이미지가 많다. 이미지 슬라이드(캐러셀)은 물론이고, 클래스 항목별로 이미지를 불러오기 때문이다. 그래서 처음 lighthouse로 성능을 측정했을 때 점수가 정말 참담했다..╚(•⌂•)╝

(2) 개선방법

보통 이미지는 api 호출을 통해 url을 가져와 사용한다. 이렇게 받아온 이미지의 용량을 줄일 수 있는 방법은 image cdn을 사용하면 됐다.

📘 image cdn? image cdn을 사용하면 원하는 형태로 이미지를 바꿀 수 있다.

나같은 경우, 무료로 사용 가능한 unsplash의 이미지를 사용했기 때문에 upsplash에서 자체 제공하는 image cdn을 사용했다. getParametersForUnsplash() 함수를 선언해준 뒤, 이미지를 불러올 때 URL뒤에 해당 함수와 함께 원하는 크기값을 지정해주면 된다.

이미지 슬라이드는 react-slick라이브러리를 사용했다. 따라서 아래의 코드는 슬라이드 관련 코드를 생략하고 직접적으로 image cdn이 사용되는 부분만 가져왔다.

function Carousel() {
  // unsplash에서 제공하는 image cdn
  function getParametersForUnsplash({ width, height, quality, format }) {
    return `?w=${width}&h=${height}&q=${quality}&fm=${format}&fit=crop`;
  }

  return (
    // 생략
    <Image
      src={
        image.url +
        getParametersForUnsplash({
          width: 676,
          height: 415,
          quality: 80,
          format: 'jpg',
        })
      }
      alt="이미지 슬라이드"
    />
  );
}

(3) 결과

18점이었던 Performance 점수가 78점까지 올라갔다. 이미지 용량이 얼마나 많은 비중을 차지하고 있었던건가..(ﾟДﾟ*)ﾉ

2. 😊 react-icons 번들 사이즈 줄이기

(1) 문제상황

Opportunity에서는 리소스 관점에서의 가이드를 확인할 수 있다. 즉, 로딩 성능을 이야기하는데. Reduce unused JavaScript가 가장 많은 시간을 잡어먹고 있는 것을 확인할 수 있었다.

그런데 그 중에서도 눈에 띄었던 것은 바로 react-icons였다. 아이콘 이미지를 따로 저장해 사용하지 않고, react-icons라이브러리를 설치해서 사용해주었었는데 bundle.js에서 이렇게나 많은 비중을 차지하고 있을 줄 몰랐다.

(2) 개선방법

react-icons는 아이콘의 종류별로 하나의 JavaScript파일에 아이콘 전체를 포함하고 있다고 한다. 따라서 나는 하나만 import해왔다고 생각했지만 해당 아이콘을 담고있는 전체 파일을 가져와 성능상 문제가 생겼던 것이다.

따라서, react-icons에서 제공하는 @react-icons/all-files라이브러리를 사용했다. 이를 사용하면 아이콘 별로 JavaScript 파일을 가지고 있기 때문에 빌드할 때 보다 적은 크기의 chunk를 만들어낼 수 있다고 한다.

📘 chunk? Webpack에서 애플리케이션 코드를 각기 다른 파일로 나눈것을 chunk라고 부른다고 한다.

// Before
import { AiOutlineClose, AiFillFacebook } from 'react-icons/ai';
import { RiKakaoTalkFill } from 'react-icons/ri';
import { FiLink2 } from 'react-icons/fi';

// After
import { AiOutlineClose } from '@react-icons/all-files/ai/AiOutlineClose';
import { AiFillFacebook } from '@react-icons/all-files/ai/AiFillFacebook';
import { RiKakaoTalkFill } from '@react-icons/all-files/ri/RiKakaoTalkFill';
import { FiLink2 } from '@react-icons/all-files/fi/FiLink2';

(3) 결과

1.56초였던 Reduce unused JavaScript항목이 0.99초로 절반가량의 시간이 단축된 것을 확인할 수 있었다!🎊 (라이브러리 사용하면 편하다고 이것저것 막 갖다가 사용하면 나중에 성능상으로 문제가 생길 수 있겠단 생각이 들었다..)

3. ✂️ 코드 분할

(1) 문제상황

react-icons번들링을 줄였음에도 Reduce unused JavaScript에서 많은 시간이 지체된다고 생각했다.

이런 문제가 생긴 이유는 CRA(Create-react-app)으로 프로젝트 환경을 세팅했기 때문인데. CRA(Create-react-app)으로 환경 세팅할 경우, 기본적인 Webpack 및 Babel 설정이 자동적으로 되어있다. 그리고 번들링이 되면 모든 JavaScript의 파일이 하나의 JavaScript 파일로 합쳐지는 과정(bundle.js)을 거치게 된다.

이를 개선하는 방법으로 React에서는 코드 분할(Code Splitting)에 대해 설명하고 있다. 그래서 나도 코드 분할을 해보기로 했다!

(2) 개선방법

📘 코드 분할(Code Splitting) 사용방법 React.lazy()함수를 사용하면 동적 import를 사용해 컴포넌트를 렌더링할 수 있다.

// Before
import Detail from './pages/Detail/Detail';

// After
import { lazy } from 'react';
const Detail = lazy(() => import('./pages/Detail/Detail'));

모든 import가 아닌 Route(페이지)에 기반해여 코드 분할 방법을 사용했다. 그런데 여기서 또 문제💥가 발생했다. lazy를 건 컴포넌트 페이지로 이동 시 아래와 같은 error 문구가 나오며 페이지가 정상적으로 나오지 않았다.

error가 하는 말은 다음과 같았다. 코드 분할로 페이지 로딩하는 시간이 생겼는데 loading indicator가 없다는 것!

그래서 다음과 같이 lazy를 걸어 import하는 컴포넌트를 감싸는 Suspense를 통해 해결할 수 있었다. 로딩하는 동안 fallback속성의 내용이 화면에 보이게 된다.

Loading이란 텍스트만 임시로 넣어두었지만, spinner 컴포넌트를 따로 만들어 넣어준다면 더 사용자 경험이 좋아지겠지?👍🏻

import { lazy, Suspense } from 'react';
import { Routes, Route } from 'react-router-dom';
import Nav from './components/Nav/Nav';
import Main from './pages/Main/Main';
const Detail = lazy(() => import('./pages/Detail/Detail'));
const MyPage = lazy(() => import('./pages/MyPage/MyPage'));
const Footer = lazy(() => import('./components/Footer/Footer'));

const NavVisibleComponents = () => {
  return (
    <>
      <Nav />
      <Suspense fallback={<div>Loading...</div>}>
        <Routes>
          <Route path="/" element={<Main />} />
          <Route path="/classes/detail/:id" element={<Detail />} />
          <Route path="/mypage" element={<MyPage />} />
        </Routes>
      </Suspense>
      <Footer />
    </>
  );
};

export default NavVisibleComponents;

(3) 결과

0.99초였던 Reduce unused JavaScript항목이 0.8초로 조금이나마 줄어든 것을 확인할 수 있었다!(@^0^@)

4. ⚡ CLS 개선

(1) 문제상황

위의 내용을 개선해나가며 Performance점수가 많이 좋아졌지만, 한 가지 계속 괴롭히는 항목이 있었는데.. Cumulative Layout Shift였다.

이 항목은 동적 DOM 변경 등으로 웹 페이지의 레이아웃이 얼마나 변하는 지 측정한 값으로, 사용자가 잘못된 클릭을 하도록 유발하는 시각적 불안정성을 체크하는 지표다.

아래의 예시와 같이 ❌No, go back❌을 클릭했지만, 클릭하는 순간 광고창이 나오면서 ⭕Yes, place my order⭕버튼을 클릭하게 되는 경우이다. 이렇게 예상하지 못한 레이아웃 이동이 많다면 좋은 사용자 경험을 제공하고 있다고 할 수 없을 것이다.

아무튼 CLS에 걸리는 시간이 많다는 것은, 지금의 내 웹사이트에서 레이아웃 이동이 일어나고 있다는 것이었다.

(2) 개선방법

페이지 가장 하단에 있는 footer에서 계속 CLS점수가 높게 나오고 있었다. footer는 동적으로 콘텐츠가 삽입되는 일이 없는데 왜 자꾸 footer에서 점수가 높게 나오는건지 알 지 못해서 계속 footer위치만 조정해주며 헤맸었다.

그런데 lighthouse performance탭을 통해 웹페이지가 화면에 그려지는 과정을 단계적으로 보던 그 순간..! 중간에 강의 목록들이 동적으로 추가되어서 처음에 footer가 그려졌다가 밑으로 쭉 밀리는 모습을 볼 수 있었다. 그렇다.. 애초에 footer 문제가 아니었다. 동적으로 요소가 추가되고 있는건 그 위의 강의목록들이었다.

그래서 강의목록들이 동적으로 추가되는 전체 Container에 height를 지정해주었다. 그랬더니 Performance 점수가 놀랍게 올라가는 것을 확인할 수 있었다.

(3) 💝결과💝

맨 처음 18점이었던 Performance 점수가 91점까지 올라감으로써 성능 최적화를 모두 90점 이상인 ✅초록불✅로 끝낼 수 있게 되었다.

참고

• https://kyounghwan01.github.io/blog/React/optimize-performance/properly-size-images/#%E1%84%92%E1%85%A2%E1%84%80%E1%85%A7%E1%86%AF

• 하나의 클래스, 혹은 특정한 목적을 가진 복수의 함수로 구성된 것을 모듈이라고 한다.

• 이후 설명할 require와 exports 키워드를 사용하는 CommonJS는 Node.js 서버를 위해 만들어진 모듈 시스템이다. 여기서 모듈 시스템이란, 프로그램 코드를 기능별로 나눠서 독립된 파일에 저장하여 관리하는 방식이라고 할 수 있다.

• export와 import와 같은 특수한 키워드를 통해 다른 모듈들을 불러와 불러온 모듈에 있는 함수를 호출하는 것과 같은 기능 공유가 가능하다.

💌 require와 import

🎃 require와 import의 공통점 하나의 파일에서 다른 파일의 코드를 불러온다는 동일한 목적을 가지고 있다.

1. require / exports (CommonJS)

• NodeJS에서 사용되는 CommonJS 키워드

• 변수를 할당하듯 모듈을 불러온다.

// exports
const name = '고양이';
module.exports = name;

// require
const name = require('./module.js');

2. import / export (ES6)

• ES6(ES2015)에서 새롭게 도입된 키워드

// export
const name = '고양이';
export default name;

// import
import name from './module.js'

3. exports와 export

• exports는 CommonJS와 ES6라는 모듈 시스템에서 존재하는 객체이다.

• 모듈로부터 내보내지는 데이터들을 담고있는 하나의 객체인 것이다.
• ES6의 export default는 CommonJS의 module.exports 구문 동작을 대체하기 위한 문법이다.

📤 모듈 전체 내보내고 가져오기

1. require / exports (CommonJS)

// 모듈 전체를 export, 파일내 한번만 사용가능하다.
const obj = {
   num: 100,
   sum: function (a, b) {
      console.log(a + b);
   },
   extract: function (a, b) {
      console.log(a - b);
   },
};
module.exports = obj;

// require
const obj = require('./exportFile.js');

obj.num; // 100
obj.sum(10, 20); // 30
obj.extract(10, 20); // -10

2. import / export (ES6)

// 모듈 전체를 export, 파일내 한번만 사용가능하다.
const obj = {
   num: 100,
   sum: function (a, b) {
      console.log(a + b);
   },
   extract: function (a, b) {
      console.log(a - b);
   },
};

export default obj;

// 전체 자체를 export 할 경우 중괄호 없이 그냥 씀
import obj from './exportFile.js';

obj.num; // 100
obj.sum(10, 20); // 30
obj.extract(10, 20); // -10

📤 모듈 개별 내보내고 가져오기

1. require / exports (CommonJS)

🎃 이것만 기억하자!

1. 여러개의 객체를 내보낼 때 → exports.변수
2. 딱 하나의 객체를 내보낼 때 → module.exports = 객체

// exports
exports.name = 'Ann'; // 변수

exports.sayHello = function() { // 함수
    console.log('Hello World!');
}

exports.Person = class Person { // 클래스
    constructor(name){
        this.name = name;
    }
}

// require
const { name, sayHello, Person } = require('./exportFile.js');

console.log(name); // Ann
sayHello(); // Hello World!
const person = new Person('inpa');

2. import / export (ES6)

✅ export 개별

export const name = 'Ann'; // 변수의 export

export function sayHello() { // 함수의 export
    console.log('Hello World!');
}

export class Person { // 클래스의 export
    constructor(name){
        this.name = name;
    }
}

✅ export 한꺼번에

const name = 'Ann';

function sayHello() {
    console.log('Hello World!');
}

class Person {
    constructor(name){
        this.name = name;
    }
}

export {name, sayHello, Person}; // 변수, 함수, 클래스를 하나의 객체로 구성하여 export

✅ import 일반

import { name, sayHello, Person } from './exportFile.js';

✅ import * as 별칭

• 개별로 export 된걸 * 로 한번에 묶고 as 로 별칭을 줘서, 마치 전체 export default 된걸 import 한 것 처럼 사용 가능하다.

import * as obj from './exportFile.js'; 

console.log(obj.name); // Ann
obj.sayHello(); // Hello World!
const person = new obj.Person('inpa');

✨ CommonJS 모듈 시스템의 필요성

• 많은 프로젝트에서 ES6 모듈 시스템을 점점 널리 사용하는 추세이지만,

• 항상 import만을 사용하여 코딩할 수 있는 것은 아니다.
• <script>태그를 사용하는 브라우저 환경, NodeJS에서 CommonJS를 기본 모듈 시스템으로 채택하고 있기 때문에
• Babel과 같은 ES6코드를 변환해주는 도구를 사용할 수 없는 상황에선 require를 사용해야 한다.

🎀 정리

• require와 import는 모듈 키워드입니다.

• 외부 파일이나 라이브러리를 불러올 때 사용한다는 같은 목적을 가지고 있지만, 다른 문법구조를 가지고 있습니다.
• require는 exports와 함께 사용되며, NodeJS에서 사용되는 CommonJS의 키워드이고,
• import는 export와 함께 사용되며, ES6에서 새롭게 도입된 키워드입니다.
• Babel과 같은 ES6 변환도구가 없이는 CommonJS의 require, exports를 사용해야 합니다.

📜 참고

이 글은 아래의 글을 바탕으로 공부하며 개인적으로 정리한 글입니다.

• https://inpa.tistory.com/entry/NODE-📚-require-⚔️-import-CommonJs와-ES6-차이-1
• https://www.daleseo.com/js-module-require/
• https://code-designer.tistory.com/103

프로젝트할 때 기능 구현에만 급급해 좋은 코드를 작성하지 못했다는 생각이 들었다.

9월에 진행했던 프로젝트 코드를 다시 들여다보니 컴포넌트가 분리되어 있지 않아 가독성이 떨어졌으며, 동일한 로직을 반복하여 작성한 경우도 많았고, 함수명도 분명하지 않은 등..고쳐야할 부분이 많이 보였다.

리팩토링에 더해 TypeScript와 Redux를 공부해 적용해보기도 했던 지난2주! 리팩토링을 하며 내가 신경쓰며 진행했던 부분에 대해 정리해놓고자 한다.

👩🏻‍🔧 리팩토링 (Refactoring) 프로그램의 외부 동작은 그대로 둔 채, 내부의 코드를 정리하면서 개선하는 것

1. 컴포넌트의 분리🧩

왼쪽의 코드가 리팩토링 이전의 코드다. 한 파일, 한 컴포넌트에 한 페이지에 대한 거의 모든 내용을 담아냈었다. 내가 작성한 코드였고, 기능 구현에만 급급했기에 가독성에 대해 생각하지 못했었다.

그로부터 2-3달 정도가 지났기에 내가 작성한 코드임에도 파악하는 것이 쉽지 않았다. 어디서부터 어디까지가 어떤 기능을 하는지 하나하나 확인을 해야했다.

나조차도 이런데, 다른 사람이 이 코드를 보면 어떨까란 생각이 들었다. 그래서 컴포넌트를 최대한 분리하기 시작했다. 그러자 가독성도 좋아졌으며, 구조를 파악하기가 훨씬 좋았다.

2. 이미지 용량 줄이기📸

lighthouse로 해당 프로젝트에 대한 성능을 점수로 확인할 수 있었다. LCP(Largest Contentful Paint)에 영향을 미치는 요소 중 하나인 <img>. 이미지 로딩에 차지하는 시간이 큰 듯했다.

width와 height를 명시적으로 지정해주거나 다양한 버전의 크기를 지정해놓는 등 여러 방법이 있었는데, 우선 jpeg 파일 형식 자체가 용량이 크다고 판단했다. (png는 더 크고..╚(•⌂•)╝) 그래서 우선 메인 페이지의 이미지 슬라이드(캐러셀)에 들어가는 이미지 확장자를 avif로 변환해 바꿔주었다.

웹 성능이 20점이 넘게나 높아지는 걸 확인할 수 있었다.😱 (메인페이지에 들어가는 이미지가 많은데 이미지 슬라이드에 해당되는 이미지만 변환시켜주어서 아직 성능이 썩 좋진 않다..)

3. 로직 분리🍛

장바구니 페이지나, 찜목록 페이지나 전체 데이터를 받아오는 api호출 내용이 동일한데, 불필요하게 반복되고 있다는 생각이 들었다.

Custom Hook을 사용해 각 페이지에서 useFetch를 가져다가 사용할 수 있었다. 하지만, 각 페이지에서 받아온 데이터는 store에서 전역적으로 관리되고 있었다. 두 데이터를 구분지어 받아오는 것이 필요하다고 생각해 장바구니인지 찜목록인지 구분할 수 있는 인자를 추가적으로 넣었다.

지금까지 고안해낸 방법은 이러한 방식인데, 최선의 방법은 아니란 생각이 들어서 차차 보완해나갈 생각이다.

// useFetch.tsx
import { useDispatch } from 'react-redux';
import { useEffect } from 'react';
import { getData, getLikeData } from '../store/slices';

function useFetch(url: string, title: string) {
  const dispatch = useDispatch();
  const requestHeaders: HeadersInit = new Headers();
  const accessToken = localStorage.getItem('accessToken');
  requestHeaders.set('authorization', accessToken || 'Token not found');

  useEffect(() => {
    fetch(url, {
      headers: requestHeaders,
    })
      .then(response => {
        if (response.ok) {
          return response.json();
        }
        throw new Error('에러 발생!');
      })
      .catch(error => {
        alert(error);
      })
      .then(data => {
        if (title === 'cart') dispatch(getData(data));
        if (title === 'like') dispatch(getLikeData(data));
      });
  }, []);
}

export default useFetch;

4. 상수데이터 관리📂

Footer와 같은 경우, 상수데이터가 정말 많았다. 상수데이터를 따로 관리해 사용하지 않다보니, 나중에 유지보수하기가 정말 힘들겠단 생각이 들었다.

지금이야 작은 팀프로젝트이니 크게 문제가 되지 않겠지만 만약 정말 많은 상수값이 코드에 녹여져있는데 수정을 해야하는 상황이 온다면..? 상수데이터가 분리되어 있지 않다면 얼마나 불편할까.

'고객센터'를 'CS Center'라는 문구로 바꾼다고 가정해본다면, 상수데이터화 시켜놓지 않은 코드는 '고객센터'라는 문구를 전부 찾아 일일이 바꿔줘야할 것이다.🤧 그런상황이 오지않게 미리미리 연습해두자!

// FooterConstant.jsx
export default {
  // 생략
  CS_CENTER: {
    CENTER: [
      {
        TITLE: '고객센터',
        NUMBER: '1644-9825',
        EMAIL: 'eogh773@Naver.com',
      },
      {
        TITLE: '기업선물',
        NUMBER: '010-3633-3190',
        EMAIL: 'order@hush.co.kr',
      },
    ],
    CONTACT: [
      {
        TITLE: '상담전화',
        HOUR: '13:00 16:00(평일)',
      },
      {
        TITLE: '상담톡',
        HOUR: '10:00 16:00(평일)',
      },
    ],
  },
}

마치며

약 2주에 걸쳐 리팩토링을 진행하며 리팩토링에 끝이 존재하긴 할까..란 생각이 가장 많이 들었다. 손을 대면 댈수록 손을 대야할 부분이 계속 눈에 보였고, 고치고 고쳐도 더 나은 코드로 만들 수 있을 것만 같았다.

보수공사는 계속해서 필요한거니까!👩🏻‍🔧 이대로 1차 프로젝트에 대한 리팩토링을 종료할 생각은 없다. 2차 프로젝트 리팩토링을 하며 또 깨닫는 점이 있다면 1차 프로젝트에도 이어서 적용시켜서 더 나은 코드로 점점 발전시키고 싶다.🛬🛫

TypeScript를 알기 전에 JavaScript를 먼저 짚고 넘어가보자!

• JavaScript는 1995년 넷스케이프사의 브렌던 아이크(Brendan Eich)가 개발한 스크립트 언어이다.

• 서둘러 출시된 언어인데다가 과거 웹페이지의 보조적인 기능을 수행하기 위해 한정적인 용도로 만들어진 태생적인 한계를 가지고 있다.

1-1. JavaScript 인기 급상승 시기

하지만 한낮 보조 기능을 수행하는데 불과했던 JavaScript의 위상은 달라지기 시작하는데..🚀

1. HTML5의 등장 (2014.10.28)
   • 기존의 웹 애플리케이션은 플러그인에 의존하여 구축되었다면, HTML5 등장으로 JavaScript가 그 자리를 대신하게 되었다.
     
2. AJAX의 활성화
   • AJAX(Asynchronous JavaScript and XML)는 JavaScript를 이용해 비동기식으로 XML을 이용해 서버와 통신하는 방식
   • 서버 측이 담당하던 많은 일들이 클라이언트측으로 이동하게 되었다.

1-2. JavaScript 단점

JavaScript는 C, JAVA와 구별되는 특성이 있는데 다음과 같다.

1. 프로토타입 기반 프로그래밍(Prototype-based Object Oriented Language)
2. Scope와 this
3. 동적 타입(dynamic typed) 언어 혹은 느슨한 타입(loosely typed) 언어

이러한 특징은 클래스 기반 객체지향 언어(Java, C++, C# 등)에 익숙한 개발자를 혼란스럽게 했다. 이러한 문제를 극복하고자 자바스크립트 대체 언어가 등장하기 시작했다. 그 예로, CoffeScript, Dart, Haxe 등이 있겠다.

아무튼 타입스크립트 역시 자바스크립트의 문제를 극복하고자 등장한 자바스크립트 대체 언어이다.

2. TypeScript🎉

• 앞서 언급했듯 TypeScript JavaScript 대체 언어의 하나로,
• ES5*의 상위확장(Superset) 언어이다.
• Microsoft에서 C#의 창시자가 2012년에 발표했다. (Microsoft의 VSCode도 TypeScript로 개발되었다고 한다👀)

3. TypeScript 특징

(1) 정적 타이핑을 지원한다.

정적타입과 동적타입은 아래에서 조금 더 자세하게 다뤄보겠다.

(2) ES5의 문법을 그대로 사용할 수 있다.

(3) ECMAScript의 가장 최신 업데이트를 빠르게 반영한다.

💁🏻‍♀️ ECMAScript

• JavaScript의 기반이 되는 스크립팅 언어 명세
• ES6 (ECMAScript 2015)의 클래스, 모듈 등과 ES7의 Decorator 등을 지원한다.
• ES6의 새로운 기능을 사용하기 위해 Babel과 같은 트랜스파일러(Transpiler)를 사용하지 않아도 실행할 수 있다.

(4) 꾸준히 관심도가 증가하는 추세다.

출처: Google Trends, 검색어 TypeScript

(5) MS의 경쟁사도 선택한 언어다!

• 구글은 구글이 개발한 JS 프레임워크 Angular의 주력 언어로 TypeScript를 채택했다. (TypeScript의 상위집합인 AtScript라는 것도 계획했다하지만..결국엔..)

• 또한, 2017년 TypeScript를 사내 표준 언어(Canonical Languages)로 승인함으로써
• 구글애널리틱스, 파이어베이스, 구글 클라우드 플랫폼 등 대규모 프로젝트, 그리고 핵심적인 내부 도구에 TypeScript와 TypeScript 기반 Angular를 사용하고 있다.

4. TypeScript 사용이유/장점

(1) 정적 타입⭐

TypeScript를 사용하는 가장 큰 이유 중 하나는 정적 타입을 지원한다는 것이다.

💁🏻‍♀️ 동적 타입이란? (Dynamic)

• 컴파일 시 자료형을 정하지 않고, 코드를 실행할 때 결정한다.
• 예시

    let num = 1; // 숫자
    num = "number 1";  // 문자

💁🏻‍♀️ 정적 타입이란? (Static)

• 컴파일 시 변수의 타입이 결정되는 언어
• 변수 생성 시 타입을 같이 명시해주는 것
• 예시
  • num 변수가 int로 타입 선언된다.

    Int num = 1; 

아래의 함수는 두개의 인자를 받아 합계를 구하는 함수로 보인다. 하지만, 전달되는 인수나 return되는 값이나 Type이 명확하지 않다. 이는 JavaScript의 동적 타이핑에 의해 발생된 것이다.

// JavaScript
function sum(a, b) {
  return a + b;
}

sum('x', 'y'); // 'xy'

그럼 정적 타입핑은 왜 좋은 것일까? 우선 첫째, 컴파일 단계에서 오류를 잡아낼 수 있다. 그리고 둘째, 개발자의 의도를 명확하게 하여, 예측할 수 있게하고 디버깅을 쉽게 한다.

// TypeScript
function sum(a: number, b: number) {
  return a + b;
}

sum('x', 'y'); // error

(2) 도구의 지원⭐

TypeScript를 사용하는 가장 큰 장점은 IDE(통합개발환경)을 포함한 다양한 도구의 지원을 받을 수 있다는 것이다.

💁🏻‍♀️ IDE(Integrated Development Environment)

• 코딩, 디버그, 컴파일, 배포 등 프로그램 개발에 관련된 모든 작업을 하나의 프로그램 안에서 처리하는 환경을 제공하는 소프트웨어
• 대표적인 IDE : VScode, Eclipse

(3) 강력한 객체지향 프로그래밍 지원

TypeScript는 인터페이스, 제네릭 등과 같은 강력한 객체지향 프로그래밍 지원한다.

• 크고 복잡한 프로젝트의 코드 기반을 쉽게 구성할 수 있도록 해준다.
  • JavaScript의 동적 타이핑으로 인해, 자료형 추적이 안되는 객체가 많으며 속성 변경 역시 너무나 쉬워 버그가 생길 가능성이 매우 높다.
• Java, C# 등의 클래스 기반 객체지향 언어에 익숙한 개발자가 자바스크립트 프로젝트를 수행하는 데 진입 장벽을 낮추는 효과가 있다.

(4) 최신 문법 지원

• 브라우저
  • ES5는 컴파일러 등의 개발환경 구축 없이 바로 사용할 수 있다.
  • 하지만 ES6는 완전히 지원하지 않고 있다. (Babel 써야함)
• TypeScript
  • 개발환경 구축이 까다롭다는 점이 있지만,
  • 최신 문법을 컴파일러 없이 사용 가능한걸요?

5. 장점이 있으면 단점도 있기 마련!

(1) 개발환경 구축의 까다롭다.

• JavaScript엔진에서 실행되기 때문에 기본적으로 설치해야 하는 모듈 있고,
• 컴파일을 위한 옵션도 설정해야 한다. 최근에 개발환경 구축부터 해보고있는데 진짜..ㅎ쉽지않네..?

(2) 가독성이 떨어진다.

• JavaScript와 비교했을 때 확연히 가독성이 떨어지는 것을 알 수 있다.
• 코드의 길이 역시 길어진다. 아무래도 타입을 일일이 지정해주어야하다보니 가독성이 떨어지더라😥

(3) JavaScript에서 생기는 오류를 피할 수 없다.

• Type에러 이외의 에러는 계속 발생할 수 있다.

6. 정리

💁🏻‍♀️ 그래서 TypeScript를 왜 쓰는데요?

1. 정적 타입을 지원
   • 컴파일 단계에서 오류 잡아낼 수 있음
   • 개발자의 의도를 명확하게 하여, 예측할 수 있게하고 디버깅을 쉽게 한다.
2. VSCode와 같은 IDE(통합개발환경)을 포함한 다양한 도구의 지원
3. interface, generic과 같이 객체지향 프로그래밍을 지원
4. 최신문법을 별도의 컴파일러(babel 등) 없이 사용 가능

참고

이 글은 아래의 글을 바탕으로 공부하며 개인적으로 정리한 글입니다. 이미지에 대한 출처는 아래의 포스팅에 있습니다.

• TypeScript - Intro & Install | PoiemaWeb
• TypeScript, 왜 써야되나?? (feat. 장단점)
• MS 타입스크립트, 구글 사내 표준 언어 되다
• 012_정적 타입 언어와 동적 타입 언어, 그리고 TypeScript
• 정적타입 언어 (Statically typed) vs 동적타입 언어 (Dynamically typed)

이벤트 버블링에 대해 알기 이전에 용어를 정확히해두고 싶어 흔히 쓰이는 이벤트 리스너와 이벤트 핸들러가 진정 의미하는 것은 무엇인지 대해 알아보았다.

이벤트 리스너와 이벤트 핸들러를 합쳐 이벤트 리스너 혹은 이벤트 핸들러라고 한다. 하지만, 이를 정확하게 말하자면 이벤트 리스너에 등록된 콜백함수가 이벤트 핸들러이다.

div.onClick(() => {});
div.addEventListener('click', () => {});

1. 이벤트 핸들러의 호출 과정

1. ⬇ 하위 요소에 이벤트 전파 캡처링
2. 💌 타깃 요소에 이벤트 전달
3. ⬆ 상위 요소로 다시 이벤트 전파 버블링

2. 이벤트 버블링 (Event Bubbling)

🧼 이벤트 버블링이란? 특정 요소에서 이벤트가 발생됐을 때, 해당 이벤트가 상위 요소들로 전달되어 가는 특성을 말한다.

2-1. 예시

• document객체를 만날 때까지, 각 요소에 할당된 onClick이 동작
• 이벤트 핸들러의 동작 순서는 다음과 같다. p > div > form

!codepen[hyerrin/embed/BaVvyVP?default-tab=html%2Cresult]

2-2. 왜 이벤트 버블링인가?

이벤트가 제일 깊은 곳의 요소에서부터 시작해 부모 요소를 거슬러 올라가며 이벤트가 발생하는 모양이 마치 물속 거품(bubble)과 같기 때문이다.

2-3. event.target 과 event.currentTraget 의 차이점

타깃(target) 요소

• 이벤트가 발생한 가장 안쪽의 요소로, 내가 클릭한 바로 그 요소
• event.target을 통해 접근 가능하다.
• 버블링이 진행되어도 변하지 않는다.
  

event.currentTarget와 this

• event.currentTarget은 this와 같다.
• 왜냐? 메소드 내부의 this는 해당 메소드를 호출한 객체에 바인딩되기 때문이다.
• 다음의 예시를 통해 확인해볼 수 있었다.

<!--HTML-->
<form>
      FORM
      <div>
        DIV
        <p>P</p>
      </div>
</form>

// JavaScript
function lalala(e) {
    console.dir(this); // div
      console.log(e) // PointerEvent{}
    console.log(e.target); // <P>P</P>
    console.log(e.currentTarget); <div>...</div>
    console.log(e.currentTarget === this); true
      }
const divTest = document.querySelector("div");
divTest.addEventListener("click", lalala);

event.currentTarget

• this, 즉 eventCurrentTarget은 현재 요소로, 현재 실행 중인 핸들러가 할당된 요소를 참조한다.
• 아래의 이미지에서 form태그에만 onClick 핸들러가 있다고 했을 때, event.target과 event.currentTarget은 어떻게 다를까?

  • event.target : form 안쪽에 내가 실제 클릭한 요소

  • event.currentTarget : form 요소

2-4. 버블링 중단시키기

event.stopPropagation()

• 이벤트 버블링을 막아야하는 경우는 거의 없다.
• 위 메소드로 버블링을 막게되면, 사람들이 페이지의 어느 부분을 클릭했는지에 대한 분석 시스템이 동작하지 못하게 된다.

2-5. 주의

거의 대부분의 이벤트는 버블링되지만, 몇몇 버블링이되지 않는 이벤트도 있다. (예) focus()

3. 이벤트 캡쳐 (Event Capture)

📸 이벤트 캡쳐란?

• 이벤트 버블링과 반대되는 방법
• 이벤트 핸들러 호출 과정의 캡처링 과정에서 이벤트를 잡아내는 방법

3-1. 이벤트 핸들러 동작 과정

form, div, p 태그에 모두 click 이벤트를 설정해놓았다고 했을 때, 어떤 순서로 동작하게 될까?

1. p 클릭
2. HTML → BODY → FORM → DIV 캡쳐링
3. p 타깃요소에 이벤트 전달
4. DIV → FORM → BODY → HTML 버블링

3-2. capture 옵션

• false : default 값으로, 이벤트 핸들러가 버블링 단계에서 동작한다.
• true : 이벤트 핸들러가 캡처링 단계에서 동작한다.

div.addEventListener('click', () => {}, { capture: true }); // (1)
div.addEventListener('click', () => {}, true); // (2)

3-3. 버블링 vs. 캡쳐링

• 캡쳐링 단계는 거의 쓰이지 않으며, 주로 버블링 단계의 이벤트만 다뤄진다.
• 특정 요소를 클릭했을때 해당 내용에 대해서는 그 요소가 가장 잘 알고있기 때문에
• 지역 사건이 일어났을 때 해당 지역의 담당이 먼저 처리해본뒤, 상위 기관으로 넘기는 것과 같은 원리이다.

4. 이벤트 위임 (Event Delegation)

🎁** 이벤트 위임이란?**

• 이벤트 캡처링과 이벤트 버블링을 활용한 패턴
• 하위 요소🧑🏻마다 이벤트를 등록하지 않고도
• 하위 요소🧑🏻*들의 공통된 부모 요소👵🏻에 이벤트를 등록하여
• 하위 요소🧑🏻*의 이벤트들을 관리하는 방식이다.

4-1. 예시

1. 이벤트 위임을 사용하지 않았을 때

<!--HTML-->
<ul>
    <li>1</li>
    <li>2</li>
    <li>3</li>
    <li>4</li>
    <li>5</li>
    <li>6</li>
</ul>

// JavaScript
const li = document.querySelectorAll("li");

li.forEach((li) => {
    li.addEventListener("click", () => {
        li.classList.add("selected");
    });
});

2. 이벤트 위임을 사용했을 때

// JavaScript
const ul = document.querySelector("ul");

ul.addEventListener("click", (event) => {
    if (event.target.tagName == "LI") {
        event.target.classList.add("selected");
    }
});

4-2. 이벤트 위임을 사용하면 좋은점

여러 자식 요소에 모두 이벤트를 등록하는 것이 아닌, 부모 요소 하나에 등록함으로써 관리하기 때문에

1. 이벤트 핸들러의 관리가 수월하다.
2. 하위 요소를 자유롭게 추가하고 삭제할 수 있다.

정리

🧼 이벤트 버블링에 대해 설명해주세요!

• 이벤트 버블링은 특정 요소에서 이벤트가 발생했을 때 해당 이벤트가 상위 요소들한테 차례로 전달되는 특성이다.
• event.propagation() 메소드로 이러한 버블링 현상을 막을 수 있지만, 잘 사용되지 않는다.
• 하위요소 → 상위요소로 이벤트가 전파되는 것은 이벤트 버블링이며, 이와 반대로 상위요소 → 하위요소로 이벤트가 전파되는 것은 이벤트 캡처링이다.
• 이러한 이벤트 버블링, 캡쳐링 특성을 이용하여 하위요소마다 이벤트를 등록하지 않아도 공통된 상위요소에 이벤트를 등록해 관리할 수 있는 패턴을 이벤트 위임이라고 한다.

참고

이 글은 아래의 글을 바탕으로 공부하며 개인적으로 정리한 글입니다. 이미지에 대한 출처는 모두 아래에 있는 포스팅에 있습니다.

• 이벤트 버블링, 이벤트 캡처 그리고 이벤트 위임까지
• 버블링과 캡처링
• 이벤트 처리 - 이벤트 핸들러(event handler), 이벤트 리스너(event listener), 이벤트 리스너 등록 방법, 이벤트 호출 순서
• [JS] 자바스크립트 이벤트 위임( Event Delegation )

this는 JAVA에선 자신을 가르키거나 자신이 생성할 인스턴스를 가르키는 자기 참조 변수이다. 하지만, JavaScript에서의 this는 함수 호출 방식에따라 달라진다.

💁🏻‍♀️ this란?

• JAVA
  • 자신이 속한 객체 또는 자신이 생성할 인스턴스를 가르키는 자기 참조 변수이다.
• JavaScript
  • this는 기본적으로 window다.
  • 함수 호출 방식에 따라 this가 가리키는 객체(this에 바인딩되는 객체)는 달라질 수 있다.

🎀 바인딩은 뭘까?

• 바인딩은 this와 this가 가리킬 객체를 연결하는 것을 말한다.

❓ 함수 호출 방식에 따라 this가 달라지는 이유

• this는 실행 컨텍스트가 생성(스코프체인, 변수 객체화, this바인딩)될 때 결정된다.
• 일반적으로 함수를 호출할 때 실행 컨텍스트가 생성되기 때문에, this는 함수를 호출할 때 결정된다고 할 수 있다.

함수의 호출 방식

함수 호출 방식은 아래와 같이 4가지로 분류해 볼 수 있다.

(1) 함수 호출

const foo = function() {
 console.dir(this);
}

foo(); // this는 window

(2) 메소드 호출

const foo = function() {
 console.dir(this);
}

const obj = {
    foo : foo
};

obj.foo(); // this는 obj

(3) 생성자 함수 호출

• JavaScript에서 모든 함수는 생성자 함수이기도 하다.

• 함수 호출 시 new를 명시하면, 해당 함수(instance)는 객체를 반환하고, 생성자 함수(foo)내부에서 사용된 this는 반환된 객체(instance)를 가르키게 된다.

const foo = function() {
 console.dir(this);
}

const instance = new foo(); // this는 instance

(4) apply/call 호출

const foo = function() {
 console.dir(this);
}

const bar = {
    name : 'bar'
};

foo.apply(bar); // this는 bar
foo.call(bar); // this는 bar

1. 함수 호출

• 기본적으로 this는 전역객체(Global Object)에 바인딩된다.

• 전역객체(Global Object)
  • 모든 객체의 유일한 최상위 객체
  • Browser-side(브라우저): window객체
  • Server-side(Node.js): global객체

(1) 내부함수

전역함수는 물론 그 내부함수까지 전역객체에 바인딩된다.

function foo() {
  console.log(this); // this는 window
  function bar() {
    console.log(this); // this는 window
  }
  bar();
}
foo();

(2) 메소드의 내부함수

메소드의 내부함수 역시 this는 전역객체에 바인딩된다.

💁🏻‍♀️ 메소드란?

• 객체는 키(key)와 값(value)으로 구성된 프로퍼티(property)의 집합입니다.
• 이 프로퍼티의 값으로 함수가 올 수도 있는데, 이러한 프로퍼티를 메소드(method)라고 합니다.

let value = 1;

let obj = {
  value: 100,
  foo: function() {
    console.log(this);  // this는 obj
    console.log(this.value); // this.value는 100
    function bar() {
      console.log(this); // this는 window
      console.log(this.value); // this.value는 1
    }
    bar();
  }
};

obj.foo();

(3) 콜백함수

콜백함수도 this는 전역객체에 바인딩된다.

💁🏻‍♀️ 콜백함수란? 다른 함수의 인자로서 이용되는 함수

let value = 1;

let obj = {
  value: 100,
  foo: function() {
    setTimeout(function() { // 콜백함수
      console.log(this);  // this는 window
      console.log(this.value); // this.value는 1
    }, 100);
  }
};

obj.foo();

(4) 내부함수의 this가 전역객체를 참조하는 것을 피하는 방법

1. 외부함수에서 외부함수가 가르키는 this를 변수에 담고, 내부함수에서 참조할 수 있도록하기
2. JavaScript가 제공하는 apply, call메소드 사용하기

let value = 1;

let obj = {
  value: 100,
  foo: function() {
    let that = this;  // this === obj

    console.log(this);  // obj
    console.log(this.value); // 100
    function bar() {
      console.log(this); // window
      console.log(this.value); // 1

      console.log(that); // obj
      console.log(that.value); // 100
    }
    bar();
  }
};

obj.foo();

2. 메소드 호출

(1) 일반

메소드 내부의 this는 해당 메소드를 소유한 객체, 즉 해당 메소드를 호출한 객체에 바인딩된다.

let obj1 = {
  name: 'Lee',
  sayName: function() { // 메소드
    console.log(this.name); // this === obj1
  }
}

let obj2 = {
  name: 'Kim'
}

obj2.sayName = obj1.sayName; 
// obj2에 sayName 생성
// let obj2 = {
//   name: 'Kim',
//   sayName: function() {
//     console.log(this.name); // this === obj2
//   }
// }

obj1.sayName(); // Lee
obj2.sayName(); // Kim

(2) 일반 변형

함수를 호출할 때, 호출하는 함수가 객체의 메서드인지 그냥 함수인지에 따라 this가 달라진다.

let obj1 = {
  sayName: function() { 
    console.log(this); 
  }
}

obj1.sayName(); // obj1

let newSayName = obj1.sayName;
newSayName(); // window

(3) 프로토타입 객체

프로토타입 객체 메소드 내부의 this 역시 일반 메소드와 마찬가지로 해당 메소드를 호출한 객체에 바인딩된다.

// 생성자 함수
function Person(name) {
  this.name = name;
}

Person.prototype.getName = function() {
  return this.name;
}

let me = new Person('Lee');
console.log(me.getName()); // Lee

Person.prototype.name = 'Kim';
console.log(Person.prototype.getName()); // Kim

3. 생성자 함수 호출

(1) 생성자 함수의 역할

생성자 함수의 역할은 객체를 생성하는 것이다.

(2) 생성자 함수를 동작하게 하는 법

• 기존 함수에 new 연산자를 불러 호출하기
• 생성자 함수명은 대문자로 작성해 일반함수와 생성자함수의 혼란을 방지하는 것이 좋다.
• new 연산자와 함께 생성자 함수를 호출하지 않으면 생성자 함수로 동작하지 않는다.
• 함수 me는 생성자 함수로 만들어진 instance이며, 이 경우 내부의 this는 instance 자신이 된다.

// 생성자 함수
function Person(name) {
  this.name = name;
}

let me = new Person('Lee'); // new 연산자 사용
console.log(me); // Person {name: "Lee"}

let you = Person('Kim'); // new 연산자 사용안함
console.log(you); // undefined

4. apply/call 호출

• this 바인딩
  • 암묵적 this 바인딩 : 함수 호출 방식에 따라 결정됨
  • 명시적 this 바인딩 : apply/call 메소드

• this를 어떤 객체로 지정할 것인가를 명시적으로 정할 수 있다.
• 이 메서드들은 모든 함수 객체의 프로토타입 객체인 Function.prototype 객체의 메소드이다.

(1) apply

💁🏻‍♀️ apply

function.apply(thisArg, [argsArray])

• thisArg : 함수 내부의 this에 바인딩할 객체
• [argsArray] : 함수에 전달할 argument의 배열

let Person = function (name1, name2) {
  this.name1 = name1;
    this.name2 = name2;
};

let foo = {};

Person.apply(foo, ['name1', 'name2']);

console.log(foo); // { name1: 'name1'; name2: 'name2' }

🚀 실행 과정

1. apply()를 통해 Person 호출
   • apply()는 this를 특정 객체에 바인딩할 뿐이다.
   • 본질적인 기능은 함수를 호출하는 것!
2. this에 객체 foo를 바인딩함
3. Person 함수의 this는 foo 객체가 됨
4. Person 함수의 this에 바인딩된 foo 객체에 name 프로퍼티가 추가되고, 값이 할당됨

(2) call

💁🏻‍♀️ call apply와 같은 기능으로, 그 모양만 다르다.

Person.apply(foo, ['name1', 'name2']);
Person.call(foo, 'name1', 'name2');

let Person = function (name1, name2) {
  this.name1 = name1;
    this.name2 = name2;
};

let foo = {};

Person.call(foo, 'name1', 'name2');

console.log(foo); // { name1: 'name1'; name2: 'name2' }

정리

💁🏻‍♀️ this의 용법을 아는대로 설명해주세요.

• 실행컨텍스트는 함수가 호출될 때 생성된다.
• this는 함수의 실행컨텍스트가 생성될 때 결정된다.
• 그 이유는 함수가 호출될 때 함수 컨텍스트가 생성되기 때문이다.
• 함수의 호출 방법은 아래와 같이 크게 4가지이며, 이때마다 this가 가르키는 객체는 다르다.
  1. 전역범위에서의 함수 호출 (window)
  2. 메소드 호출 (메소드가 속한 객체)
  3. 생성자 함수 호출 (인스턴스)
  4. apply / call 호출 (this바인딩할 객체 설정)

참고

이 글은 아래의 글을 바탕으로 공부하며 개인적으로 정리한 글입니다. 이미지에 대한 출처는 모두 아래에 있는 포스팅에 있습니다.

• this | PoiemaWeb
• ZeroCho Blog

JavaScript 코드가 실행되기 위한 변수객체(Variable Object), 스코프체인(Scope Chain), this와 같은 정보들을 담고 있는 객체를 실행컨텍스트라고 한다.

1. 종류

실행 컨텍스트는 아래와 같이 2종류가 있다.

💁🏻‍♀️ 실행 컨텍스트 종류

1. Global Execution Context (전역 실행 컨텍스트)
   • JavaScript 엔진이 처음 코드 실행할 때 생성
2. Function Execution Context (함수 실행 컨텍스트)
   • 함수가 호출될 때 생성

2. 실행 컨텍스트와 콜스택

JavaScript 코드를 실행하면 전역 컨텍스트 및 함수 컨텍스트가 생성되고, 이것은 콜스택이라는 구조에 쌓여 차례로 처리된다.

💁🏻‍♀️ 콜스택 (Call Stack)

• 코드가 실행되며 생성되는 실행 컨텍스트 (Execution Context)를 저장하는 자료구조
• 후입선출 방식으로 컨텍스트를 push / pop한다.

아래의 코드는 다음의 이미지와 같이 생성된 컨텍스트를 콜스택에 쌓고(push), 실행이 종료되면 콜스택에서 제거한다(pop). (이미지 속 EC는 Execute Context로 실행 컨텍스트를 의미한다.)

var x = 'xxx'

function foo () { 
  var y = 'yyy';

  function bar () {
    var z = 'zzz';
    console.log(x + y + z);
  }
  bar();
}

foo();

💁🏻‍♀️ 실행 과정

1. 함수를 호출한다.
2. 해당 함수의 실행 컨텍스트가 만들어진다.
3. 함수가 return되어 끝난다.
4. 해당 함수의 실행 컨텍스트는 스택에서 pop되고, 메모리에서 제거된다.

3. 실행 컨텍스트의 구성

실행컨텍스는 물리적으로 객체 형태이며, 아래의 3가지 프로퍼티를 갖는다.

💁🏻‍♀️ 실행 컨텍스트 구성요소

1. Variable Object (VO, 변수 객체)
2. Scope Chain
3. this Value

3-1. Variable Object (VO, 변수 객체)

변수 객체는 JavaScript 실행에 필요한 여러 정보를 담은 객체를 의미한다. 변수객체에서는 다음과 같은 정보를 확인할 수 있다.

💁🏻‍♀️ 변수객체 구성요소

• 변수
• 매개변수(parameter)와 인수(arguments)
• 함수 선언 (함수 선언식만 function(){})

컨텍스트의 종류는 2가지로, 전역 컨텍스트와 함수 컨텍스트가 있다고 했다. 이 두 컨텍스트가 가리키는 변수 객체는 서로 다르다.

💁🏻‍♀️ 전역 컨텍스트에서의 변수객체

• 전역 객체(Global Object, GO)를 가리킨다.
• 전역 객체란 모든 전역 변수/함수를 포함하는 객체를 말한다.

💁🏻‍♀️ 함수 컨텍스트에서의 변수객체

• 활성 객체(Activation Object, AO)를 가리킨다.
  • 활성 객체란 해당 컨텍스트에서 실행에 필요한 여러 정보를 담은 객체를 말한다.
• arguments 객체
  • 활성 객체 속 arguments 객체는 해당 함수의 매개변수와 인수들의 정보를 배열의 형태로 담고 있다.

3-2. Scope Chain

스코프 체인은 전역 객체(Global Object) 또는 활성 객체(Activation Object)의 리스트이다.

현재 실행 컨텍스트의 활성 객체(Activation Object)를 시작으로 순차적으로 상위 컨텍스트의 활성객체를 가르키며, 최종적으로 전역 객체(Global Object)를 가리킨다.

3-3. this

• 전역 실행 컨텍스트(Global Execution Context)에서 this는 window다.
• 함수 실행 컨텍스트에서의 값은 this 함수가 호출되는 방식에 따라 다른데, 이에 대한 내용은 다음 포스팅 때 상세히 다뤄보고자 한다.

4. 실행 컨텍스트 생성 과정

var x = 'xxx'

function foo () { 
  var y = 'yyy';

  function bar () {
    var z = 'zzz';
    console.log(x + y + z);
  }
  bar();
}

foo();b

전역 컨텍스트 생성

전역 컨텍스트가 생성되어 실행 컨텍스트 스택에 쌓이는데, 변수객체, Scope Chain, this가 들어온다.

스코프 체인 생성 및 초기화

스코프 체인은 전역 객체를 참조하는 리스트가 된다.

변수 객체화(Variable Instntiation) 실행

변수 객체화란, 변수 객체(Variable Object)에 프로퍼티와 값을 추가하는 것을 의미한다.

변수 객체(Variable Object)에는 변수, 매개변수, 인수 정보, 함수 선언 추가하여 객체화한다. 아래의 이미지와 같이, 전역 컨텍스트가 가르키는 변수 객체는 전역 객체이다. 전역 객체에는 매개변수, 인수 정보(arguments) 등이 없다.

변수 객체화를 통해 생성된 함수 객체는 [[scopes]] 프로퍼티를 갖는다. 이는 함수 객체만이 소유하는 내부 프로퍼티로, 함수 객체가 실행되는 환경이다. 생성된 함수 객체는 자신의 실행 환경(Lexical Enviroment)과 자신을 포함하는 외부 함수의 실행 환경과 전역 객체를 가리킨다.

💁🏻‍♀️ 렉시컬 환경(Lexical Environment)

• 스크립트 전체, 실행중인 함수, 코드블록 등은 자신만의 렉시컬 환경을 갖는다.
• 렉시컬 환경은 환경레코드(Environment Record), 외부렉시컬 환경(Outer Environment)으로 구성된다.

this value 결정

이전까지 this는 전역 객체(window)를 카르키고 있었다. 하지만 this는 함수 호출 방식에 따라 바인딩되는 객체가 달라진다. 단, 전역 컨택스트의 경우 Variable Object, Scope Chain, this값은 항상 전역 객체(window)다.

지금까지 살펴본 전역 컨텍스트를 객체로 표현해보면 다음과 같다.

'전역 컨텍스트': {
  전역변수객체: {
    arguments: null,
    variable: [{ x: 'xxx' }, { foo: Function }],
  },
  scopeChain: ['전역 변수객체'],
  this: window,
}

전역 코드의 실행

변수 값의 할당

var x = 'xxx'

function foo () { 
  var y = 'yyy';

  function bar () {
    var z = 'zzz';
    console.log(x + y + z);
  }
  bar();
}

foo();

현재 실행 컨텍스트의 스코프 체인이 참조하고 있는 변수 객체(Variable Obejct)부터 검색한다. 전역 컨텍스트의 경우, 변수 객체(Variable Object)는 전역 객체(Global Object)이다.

변수명에 해당되는 프로퍼티가 발견되면 값(xxx)을 할당한다.

함수 foo의 실행

var x = 'xxx'

function foo () { 
  var y = 'yyy';

  function bar () {
    var z = 'zzz';
    console.log(x + y + z);
  }
  bar();
}

foo();

새로운 함수 실행 컨텍스트 생성

스코프 체인 생성과 초기화

(1) 활성 객체(Activation Object) 생성 및 arguments 객체 초기화

(2) 전역 컨텍스트의 Scope Chain이 참조하고 있는 객체가 Scope Chain에 push

(3) 변수 객체화(Variable Instantiation) 실행

활성 객체에 변수, 매개변수, 인수 정보(arguments), 함수 선언 추가하여 객체화한다.

(4) this value 결정

• this에 할당되는 값은 함수 호출 패턴에 의해 결정된다.
• 내부 함수의 경우, this의 value는 전역 객체이다.

foo 함수 코드의 실행

함수 foo의 코드 블록 내 구문이 실행된다.

var x = 'xxx'

function foo () { 
  var y = 'yyy';

  function bar () {
    var z = 'zzz';
    console.log(x + y + z);
  }
  bar();
}

foo();

1. 변수의 값을 할당한다. var y = 'yyy'
2. 함수 bar가 실행된다
3. 함수 foo의 실행 과정과 동일한 (1) 스코프 체인 생성과 초기화, (2) 변수 객체화 실행, (3) this value 결정의 과정이 순차적으로 진행된다.

5. 정리

• 자바스크립트의 코드들이 실행되기 위환 환경이다.

• 전역 컨텍스트와 함수 컨텍스트 2가지가 존재한다.
• 전역 컨텍스트 생성 후에 함수가 호출할 때마다 함수 컨텍스트가 생성된다.
• 컨텍스트 생성 시 변수객체, 스코프 체인, this가 생성된다.
• 컨텍스트 생성 후 함수에 사용되는 변수들은 변수 객체 안에서 값을 찾고, 없다면 스코프 체인을 따라 올라가며 찾는다.
• 함수 실행이 마무리 되면 해당 컨텍스트는 사라지고, 페이지가 종료되면 전역 컨텍스트 사라진다.

📜 참고

이 글은 아래의 글을 바탕으로 공부하며 개인적으로 정리한 글입니다. 이미지에 대한 출처는 모두 아래에 있는 포스팅에 있습니다.

• Execution Context | PoiemaWeb
• Call Stack과 Execution Context 를 알아보자
• zerocho
• 학습 목표와 범위

2차 프로젝트는 클래스101을 모티브로 진행했다. 클래스101은 내가 프로젝트 아이디어로 제시한 서비스였다. 다양한 정보를 제공함에도 UI가 직관적이고 깔끔해 가장 인상 깊었던 서비스였기에, 이런 서비스를 모티브로 프로젝트를 진행한다면 배울점 역시 많을 것이라는 생각이 컸다.

클래스101에서는 강의 수강 뿐만 아니라 스토어 상품을 구매할 수도 있고, 구독 시스템도 있다. 사용자가 크리에이터가 되어 강의를 등록할 수도 있다. 처음 생각했던 것보다도 하나하나 들여다보니 다양한 기능이 있어 처음 프로젝트를 기획해나갈 때 꽤 골치 아팠었다.

1차 프로젝트 때는 주로 상품을 담고 결제하는 흐름으로 프로젝트가 진행되었다. 그래서 2차 프로젝트에는 사용자가 상품(우리 프로젝트에서는 강의!)을 등록하고 수정할 수 있는 기능을 중점적으로 구현해내고자 했다.

📆 기간

22.10.04 - 22.10.13

👩🏻‍🔧 기술

• Front-end React styled-component ◽ CRA(Create-React-App)을 통한 리액트 개발 환경 세팅 ◽ 함수형 컴포넌트 사용 ◽ ESLint, Prettier 설정
  

• Back-end Node.js, Express.js, MySQL
  
• Business Tool Slack, Trello, Notion

🔗 Github Link

• 기존 : Github Repository
• 개인적인 리팩토링 후 : Github Repository

📝 일정 관리

일정 관리는 1차 프로젝트 때와 마찬가지로 Trello(트렐로)를 사용했다. 가장 처음 했던 일은 각자 맡은 기능을 정리한 티켓들을 Backlog칸에 옮겨두는 것이었다. 프로젝트 시작 전, 빼곡한 Backlog칸을 보면 가슴이 웅장해진닷,,,

매일 10~11시 사이에 Daily StandUp Meeting을 빠짐없이 진행했다. 고정된 시간에 다 같이 모여 프로젝트 진행상황이나 예정된 상황을 공유하고 하루 일정을 시작해서인지 티켓 상태 업데이트가 비교적 잘 이루어졌던 것 같다.

티켓이 무지막지하게 많아지는 것을 방지하고자 세부 기능은 티켓 내부의 체크박스로 대신했다. 티켓을 한눈에 파악하기에 좋았던 것 같다.

✨ 주요 구현 기능

나는 메인페이지와 구독신청페이지를 담당했다.

1. 소셜 로그인

• 카카오톡 소셜 로그인

2. 메인 페이지

• nav, footer
• 이미지 슬라이드
• 다중모달
• 카테고리 필터링 및 정렬
• 페이지네이션
• 찜하기

3. 상세 페이지

• 상세 이미지 미리보기
• 리뷰 등록, 삭제
• 링크 복사
• 찜하기

4. 크리에이터 센터 페이지

• 클래스 등록
• 강의 등록, 수정, 삭제

5. 강의 영상 페이지

• 비디오 재생 및 선택하기

6. 구독 신청 페이지

• 레이아웃

7. 결제 페이지

• 레이아웃

8. 찜목록 페이지

• 찜목록 슬라이드

💁🏻‍♀️ 내가 구현한 기능

1. nav, footer

[ react-icons의 편리함 ] 상단바에는 검색, 프로필, 좋아요와 같은 다양한 아이콘들이 있는 것을 볼 수 있다. 이전까지는 이미지 파일을 프로젝트 폴더 내부에 저장해 사용해왔었다. 하지만 프로젝트 내부에 여러 아이콘 파일들이 담기는 것이 불필요하다는 생각을 항상 해왔었다. 그래서 이번 프로젝트를 진행하며 처음 react-icons라는 리액트 라이브러리를 사용해보게 되었고 편리한 점이 많았다.

react-icons를 설치하면 아이콘을 사용하고자 하는 파일에 import하여 손쉽게 적용해볼 수 있다. 또한, 다른 스타일(색상, 크기 등)을 적용하고 싶다면 className을 부여하여 지정해주면 된다, 색상을 내 마음대로 바꾸기 힘든 이미지 파일보다 그때그때 커스텀하기 좋았다.

[ 상수데이터의 분리 ] Footer 속 회사와 관련된 정보를 상수 데이터로 만들어 따로 파일을 분리해주었다. 이를 통해 상수데이터가 너무 길어져 가독성을 해치거나, 해당 상수데이터가 재사용되는 경우 따로 파일을 분리하면 좋다는 것을 알 수 있었다.

상수 데이터를 여러개의 파일로 나눠 관리할 필요없이, named Export로 한 파일 내에서 여러개의 변수를 내보낼 수 있는 방법에 대해 배울 수 있었다.

// Footer.jsx
import { INFO_LIST, SOCIAL_LIST } from './infoData';

// infoData.jsx
export const INFO_LIST = [
  {
    id: '0',
    title: '이용약관',
    url: '#',
  }, 
  // 이후 생략
]
export const SOCIAL_LIST = [
  {
    id: '0',
    title: 'IOI Korea',
    url: '#',
  },
  // 이후 생략
]

2. 이미지 슬라이드

[ react-slick을 사용한 캐러셀 구현 ] 이미지 슬라이더보다 캐러셀이라고 많이 불리는 것을 보고 캐러셀의 의미가 가장 먼저 궁금했었다. 캐러셀은 회전목마라는 뜻이 있다고 한다. 회전목마처럼 일련의 콘텐츠들이 순환하는 슬라이더를 말하는 것임을 알 수 있었다.

이미지 슬라이드는 자기소개 웹페이지를 만들 때, Vanilla JavaScript로 구현한 적이 있다. 여러개의 이미지를 가로로 쭉 붙여서 가로 이미지의 크기만큼 위치를 이동시켜주어야만 했다. 하지만, 라이브러리를 사용하니 정말 간단하게 구현할 수 있었다. react-slick으로부터 import해온 Slider 컴포넌트 안에 여러 장의 이미지 리스트를 map으로 반복시켜주기만 하면된다.

Vanilla JavaScript만으로 구현해본 적이 없다면 라이브러리의 편리함을 이렇게 크게 느끼지 못했을 것이다. 그러나 버튼 모양이라든지 스타일적인 부분을 내 입맛대로 커스텀하기에는 라이브러리를 사용하는 것보다 직접 기능을 모두 구현하는 것이 더 편리했던 것 같다. 역시 모든 것에는 장단점이 있기 마련이구만!

import Slider from 'react-slick';

<StyledSlider {...settings}>
    {CarouselImgData.map(image => (
        <ImageBox key={image.id}>
            <Image src={image.url} alt="이미지 슬라이드" />
        </ImageBox>
    ))}
</StyledSlider>

const StyledSlider = styled(Slider)`
  /* 생략 */
`

3. 다중 모달 속 카테고리 필터링 및 정렬

[ 공통된 모달의 컴포넌트화 ] 메인페이지에는 강의목록을 필터링 및 정렬 할 수 있다. Selectbox를 선택하면 그 밑에 Dropdown으로 목록이 나오는 구조가 아니라, 모달에 목록을 띄운다. 메인 카테고리, 서브 카테고리, 정렬, 이렇게 3가지 종류가 있으며 모달의 UI는 동일하다. 따라서 이 모달을 하나의 컴포넌트로 만들어 재사용해주면 된다고 생각했다.

하지만, 메인 카테고리에서 어떤 카테고리를 선택하느냐에 따라 서브 카테고리의 목록이 바뀌므로 이것을 해결하는 것이 어려웠다. 그럼에도 불구하고! 이는 모달 컴포넌트에 props로 사용자가 어떤 카테고리를 선택했는지 그 리스트를 넘겨줌으로써 해결할 수 있었다. 부모 컴포넌트와 자식 컴포넌트간의 props를 넘겨주며 코드의 중복을 줄이는 것의 중요성을 깨달았다. 구조는 다음과 같다.

// *Main 컴포넌트*
<Container>
  <FilterAndSortBox /> // 메인 카테고리
  <FilterAndSortBox /> // 서브 카테고리
  <FilterAndSortBox /> // 정렬
</Container>

// *FilterAndSortBox 컴포넌트*
<FilterAndSortBox>
    <CategoryWrap/> // SelectBox
    <FilterAndSortModal/> // 모달
</FilterAndSortBox>

[ 카테고리 필터링 및 정렬 ] 강의 목록을 카테고리에 따라 필터링하고, 가격순으로 정렬하는 것은 filter혹은 sort를 통해 프론트에서도 해결 가능하다. 하지만, 서비스를 하고 있는 다양한 웹페이지를 보면 필터링을 하거나 정렬을 할 때마다 서버에 요청을 보내는 모습을 개발자 도구 Network탭에서 확인할 수 있었다. 페이지의 URL에 https://test.com/?category=0123456&sort=recommendOrder에서도 정렬에 대한 정보가 추가되는 것을 쉽게 확인 할 수 있다.

필터링 및 정렬할 때마다 searchParams메서드를 통해 URL에 정보를 추가해주었다. 그리고, searchParams가 바뀐다는 것은 새로운 데이터를 불러와야한다는 것이기 때문에 useEffect의 의존성 배열에 searchParams를 추가해주었다.

// *높은 가격순 정렬*
const sortByHighPrice = e => {
    setBoxName(e.target.innerText); // 선택한 정렬을 selectbox 이름으로 바꾸기
    searchParams.set('sort', 'costHigh'); // searchParams를 통해 sort=costHigh 추가하기
    setSearchParams(searchParams);
    setMainModalOpen(prev => !prev); // 정렬 선택 후 모달 닫기
};

// *메인 페이지*
const fetchURL = searchParams.toString();

useEffect(() => {
  fetch(`${BASE_URL}/main?${fetchURL}`)
    .then(res => res.json())
    .then(data => {
    setClassList(data.getFilter);
    });
}, [searchParams]);

아래의 이미지를 보면, 가격 높은 순 정렬을 클릭했을 시 페이지 URL에 sort=costHigh가 추가되는 것을 확인할 수 있다.

4. 페이지네이션

페이지네이션 역시 앞선 카테고리 필터링과 정렬과 마찬가지로 searchParams를 사용했다. 사용자는 페이지를 이동하게 되면 URL의 offset값이 변하는 것을 확인할 수 있다. 강의목록을 12개씩 보이도록 limit을 설정한다면, 첫 페이지의 offset은 0이되고 그 다음 페이지의 offset은 12, 또 그다음 페이지의 offset은 24가 된다.

// Main 페이지의 컴포넌트
const LIMIT = 12;
const movePage = pageNumber => {
    searchParams.set('limit', LIMIT);
    searchParams.set('offset', (pageNumber - 1) * LIMIT);
    setSearchParams(searchParams);
};

return (
    <>
        <BtnContainer>
            <PageBtn onClick={() => movePage(1)}>1</PageBtn>
            <PageBtn onClick={() => movePage(2)}>2</PageBtn>
            <PageBtn onClick={() => movePage(3)}>3</PageBtn>
        </BtnContainer>
    </>
)

필터링, 정렬, 페이지네이션과 같은 내용을 전부 다른 URL에 요청해야했다면 반복되는 코드도 많아 가독성이 떨어지고 비효율적이었을 것이다. searchParams를 통해 URL의 구성요소를 바꾸고, 이를 토대로 서버에 데이터를 요청하는 방법에 대해 배울 수 있어 좋았다.

5. 찜하기

가장 처음 강의 목록을 불러올 때, access token이 LocalStorage에 저장되어있는 상태, 즉 로그인 상태라면 사용자가 찜한 강의 목록에 하트가 채워진 상태❤여야 했다. 이를 위해 사용자가 찜한 강의목록을 받아왔다. 그리고 찜하기를 누를 때마다 어떤 강의 목록을 찜하고, 찜을 삭제했는지 서버에 POST 및 DELETE요청을 보내 마이페이지 찜하기 목록에서 찜한 강의 목록을 확인할 수 있게 만들어주었다.

📋 프로젝트 발표

2차 프로젝트 발표날은 절대 잊을 수 없는 하루였기 때문에 꼭 기록으로 남겨두고 싶었다.

2차 프로젝트 발표 당일인 새벽 2시가 되어서야 프로젝트가 마무리됐다. 프로젝트를 마무리짓기 바빠서 발표는 생각할 겨를도 없었다. 그래서 발표 자료는 물론이고 발표 준비가 하나도 되어있지 않은 상황이었던 것. 그런데 그런 발표를 해야하는 발표자는 누구...? PM은 누구?

당장 오전 10시가 발표였다. 2주간 밤낮없이 달려온 마지막날이었기에 체력적으로 쉽지 않은 상황이었다. 하지만 절대 어영부영 대충하고 싶지 않았다. 어떤 일을 하든 유종의 미를 거두어야한다는 생각을 항상 가지고 있었기에 잠도 안왔다. 하루정도 안자도 괜찮다는 생각으로 발표 자료를 만들고 발표 연습까지 끝마쳤다. 준비한게 있으니 두려울게 없었고, 그렇게 발표는 성황리에 마무리되었다.👏🏻👏🏻👏🏻 (1차 때는 발표하는 사진 찍어주시던뎅..2차 때는 없당..괜시리 섭섭..)

이 날의 경험은 내게 근거있는 자신감을 만들어주었다. 나는 어떤 상황이든 책임감 있게 내가 맡은 일을 해내는, 그것도 잘 해내는 사람이라는 근거를 만들어주었고 이로 인해 자신감이 생겼다. 그래서인지 짧다면 짧았고 길다면 긴 2주간의 2차 프로젝트는 내게 정말 뜻깊은 시간이었다.

👏🏻 마치며

다가오는 기업협업 일정으로 전체적인 분위기가 꽤 어수선했었다. 그럼에도 불구하고 우리 클래스IOI 팀은 분위기에 휩쓸리지 않고 끝까지 집중했고, 목표로 한 기능을 구현해낼 수 있었다. 행동의 가치는 그 행동을 끝까지 이루는데 있다는 말이 있다. 처음에 누구나 열심히 한다. 문제집의 앞부분만 너덜너덜한 것처럼 말이다. 이번 프로젝트는 팀원 모두가 마지막까지 각자의 자리에서 최선을 다함으로써 그 가치를 증명해냈단 생각이 들어 뿌듯함이 크다.

• 브라우저 렌더링이란, 브라우저 주소창에 주소 입력 시 해당 페이지가 화면에 그려지는 과정을 이야기합니다.
• 브라우저는 유저가 선택한 자원(페이지, 이미지, 비디오)를 서버로 부터 받아와 렌더링 과정을 통해 유저에게 보여주죠.

2. 브라우저 기본 구조

• 브라우저는 아래와 같이 7개의 구성 요소로 이루어져 있습니다.
• 이 7개의 구성 요소 중에서도 렌더링 엔진이 HTML, CSS 문서를 브라우저가 이해할 수 있는 구조로 변환하여 화면에 그려주는 역할을 합니다.

1. 사용자 인터페이스
2. 브라우저 엔진
3. 렌더링 엔진 : 요청 받은 내용을 브라우저 화면에 표시 (HTML, XML문서, 이미지)
   • Safari, Chrome : 웹킷(Webkit) 엔진
   • Firefox : 모질라의 게코(Gecko) 엔진
4. 통신
5. UI 백엔드
6. 자바스크립트 해석기
7. 자료 저장소

출처 | 네이버D2, 브라우저의 주요 구성 요소

3. 브라우저 렌더링 과정 ⭐

1. 파싱 HTML 파일과 CSS 파일을 파싱해서 각각 Tree를 만든다.
2. 결합 두 Tree를 결합하여 Rendering Tree를 만든다.
3. 배치 Rendering Tree에서 각 노드가 화면의 정확한 위치에 표시될 수 있도록 한다.
4. 그리기 각 노드를 화면상의 실제 픽셀로 변환하고, 레이어를 만들고 합성하여 실제 화면에 나타낸다.

4. 파싱

(1) 파싱(parsing)이란?

앞서 HTML 문서와 CSS 문서가 HTML 파서와 CSS 파서를 통해 파싱되어 parse tree로 변환되는 과정이 있었죠. 여기서 파싱(parsing)이 무엇인지 궁금증이 생겨 알아본 결과!

💁🏻‍♀️ 문서를 파싱한다는 것은 브라우저가 코드를 이해하고 사용할 수 있는 구조로 변환하는 것을 뜻해요.

(2) 파싱 종류

파싱의 종류로는 크게 어휘 분석과 구문 분석이 있어요.

어휘 분석을 통해서는 자료를 토큰으로 분해하고, 구문 분석을 통해 언어의 구문 규칙에 따라 문서 구조를 분석함으로써 파싱 트리(parse tree)를 생성해요.

출처 | 네이버D2, 문서 소스로부터 파싱 트리를 만드는 과정

(3) 파싱 결과

파싱 결과는 파싱 트리, 즉 문서 구조를 나타내는 노드 트리(parse tree, syntax tree)에요.

HTML DOM을 예로 들자면, DOM은 노드(node)라고 불리는 계층적 단위에 정보를 저장하고 있죠. HTML DOM은 이러한 노드들을 정의하고, 그들 사이의 관계를 설명해 주는 역할을 합니다.

(4) DOM

HTML 문서의 파싱을 통해 생성되는 DOM에 대해서 조금 더 알아볼게요.

DOM이란 HTML 문서에 대한 인터페이스로, HTML 문서의 객체 기반 표현 방식이에요. 🌳하나의 부모 줄기에 여러 개의 자식 나뭇가지, 또 각각의 나뭇가지는 잎들을 가질 수 있는 구조🌳를 띄고 있죠.

주로 브라우저 뷰 포트(Viewport, 화면크기로 메뉴바나 탭영역을 제외한 순수 화면 영역)에 렌더링 시, 또는 JS에 의해 수정될 시에 사용돼요.

여기서 짚고 넘어갈 점! DOM은 브라우저에서 보이는 것이 아니에요. 브라우저 뷰 포트에 보이는 것은 DOM과 CSSOM의 조합의 렌더 트리랍니다.

(5) CSS 파싱

그렇다면 CSS 파싱은 어떻게 이루어지는걸까요?

CSS 파일은 스타일 시트 객체로 파싱됩니다. 각 객체는 CSS 규칙을 포함해요. 또한, CSS 규칙 객체는 선택자(div)와 선언 객체(margin, 10px) 그리고 CSS 문법과 일치하는 다른 객체를 포함해요.

div {
    margin: 10px;
}

출처 | 네이버D2, CSS 파싱

참고

NAVER D2 Javascript Environment | PoiemaWeb 38.브라우저의 렌더링 과정 브라우저 렌더링 과정 이해하기

지난주 금요일에 프로젝트 발표를 마친 🔥러쉬코리아 클론 프로젝트🔥에 대한 회고를 시작해보려고 해요. 저희 4팀은 러쉬코리아의 LUSH를 HUSH로 변경해 샤워용품이 아닌 디저트류를 판매하는 사이트를 만들었어요(저작권 절대 지켜👊🏻). 러쉬와 발음이 유사한 허쉬(Hershey)초콜릿에서 영감을 받았답니다!

이렇게 프론트와 백이 모여 제대로 프로젝트를 진행한 건 처음이었기에 여러 방면에서 제 자신에 대한 부족함을 많이 느꼈고 그래서 배울 점이 참 많았던 첫 프로젝트였어요. 협업 방식, 일정 관리, 리액트 렌더링, 통신 등.. 모든 면에서요! 이번 1차 프로젝트를 회고하며 개선해야할 부분에 대해 정리하고, 더 성장한 모습으로 2차 프로젝트를 시작해보려고 해요!

📆 작업 기간

2주가 이렇게 짧았던 적이 있었나 싶어요. 정말 눈깜짝할 사이에 2주가 지나있었어요. 레이아웃이나 기능 구현은 1주차에 거의 마무리가 됐었고, 그 이후로는 코드를 수정/개선하고 통신하는 데에 시간을 보냈어요.

2주 (22년 09월 19일 ~ 22년 09월 29일)

🔨 기술 스택

프론트엔드 4명(강루비, 김대호, 양석문, 주혜린), 백엔드 3명(김정훈, 정승렬, 정다영)이 함께 프로젝트를 진행했어요.

Front-end

React, SASS ◽ CRA(Create-React-App)을 통한 리액트 개발 환경 세팅 ◽ 함수형 컴포넌트 사용 ◽ ESLint, Prettier 설정

Back-end

Node.js, Express.js, MySQL

co-work

Github, Slack(소통), Trello(일정관리), Notion(회의록)

✅ 일정 관리

일정 관리는 Trello를 사용했어요. This sprint에는 이번 주까지 해야할 일을, In progress는 지금 진행 중인 작업을, In Review는 PR을 올리고 리뷰를 받고 있는 작업을, Done은 리뷰까지 반영돼 merge완료된 작업을 올렸어요. 레이아웃 구현과 기능 구현은 다른 티켓으로 나누어 올려 구분지었답니다.

아쉬운 점이 있다면, 기능 구현하기에 급급해 업데이트된 내용을 반영하지 않은 날도 있다는 것이었어요. 지금이야 도착하면 팀원들이 가까이 모여 프로젝트를 진행하지만, 현업에 가면 재택을 하는 것과 같이 서로의 상황을 제대로 알 수 없을 수 있겠더라구요. 2차 프로젝트에는 매일 도착하자마자 Trello를 확인하고 업데이트/관리하는 것을 기본 중의 기본으로! 가져가고자 해요.

Trello로 일정 관리를 하기는 하지만, 아날로그틱한 갬성으로 계획짜는 것을 좋아하는 저는 그 날 그 날 해아할 일이나 기억해야할 사항을 적어놓는데 플래너를 사용했어요. 하지만, 이런 플래너는 저만 알 수 있기 때문에 최대한 Trello에 더 디테일한 내용을 쓰고자 노력해야겠단 생각이 들어요. (노트에 떨어져 있는 자국은 코피 자국이었으면 좋았겠지만..커피 자국..☕코피 자국이 되는 그날까지..🏃🏻‍♀️)

✨ 주요 구현 기능

저희 팀 프론트는 페이지별로 나눠 담당했어요. 저는 색으로 표시한 것과 같이 회원가입, 로그인, 장바구니, 찜목록을 담당해 구현했답니다.

1. 회원가입, 로그인

• 이메일 중복 확인
• 비밀번호 유효성 검사

2. 메인 페이지

• nav, footer
• 이미지 슬라이드
• 애니메이션 효과

3. 제품 페이지

• 카테고리탭 별 이동
• 페이지네이션
• 가격 필터링(높은 순, 낮은 순)

4. 상세 페이지

• 수량 조절
• 상품 후기 작성
• 메뉴탭 이동

5. 장바구니 페이지

• 장바구니 목록 불러오기
• 제품 단일 선택/전체 선택 주문
• 제품 단일 선택/전체 선택 삭제
• 수량 조절
• 제품 합계 금액

6. 찜 목록 페이지

• 찜 목록 불러오기
• 제품 단일 선택/전체 선택 삭제

7. 결제 페이지

• 결제 상품 불러오기
• 주문자 정보 불러오기
• 배송 메시지 저장

👩🏻 내가 맡은 기능

1. 회원가입

회원가입 시, 이미 회원가입 된 이메일은 사용할 수 없도록 중복 확인 기능을 넣어주었어요. 중복 확인을 하지 않고 회원가입 버튼을 누르면 중복 확인을 하라는 alert창이 뜨도록 만들어주었답니다.

잠깐!🖐🏻 기억에 남는 코드가 있다면?

중복확인을 했는지, 안했는지를 isCheckEmail이라는 state로 관리해주었어요. 그래서 중복 확인하는 API요청에서 성공 메시지를 받으면 isCheckEmail을 true로 바꿔주었고, 그렇지 않으면 false로 바꿔주었죠.

const [isCheckEmail, setIsCheckEmail] = useState(false);

그리고 최종적으로 회원가입 form을 제출할 때 isCheckEmail이 true일 때는 회원가입 데이터를 서버에 보냈고, 그렇지 않을 경우에는 alert를 띄웠어요. 아래와 같이 if...else문을 사용했죠.

const submitForm = e => {
  if (isCheckEmail) {
    fetch('http://000.000.000.000:3001/user/signup', {
        // 생략  
      });
  } else {
    alert('이메일 중복을 확인해주세요.');
  }
};

코드 리뷰를 받으며 if...else문보다 직관적으로 작성할 수 있는 법을 알게 되었어요. 이메일 중복 확인에 실패하면 바로 alert를 실행하고 return함으로써 함수를 끝내버리는 방법이었죠! 이메일이 중복된 경우라면 쓸데없이 if문의 긴 코드를 읽어내려갈 필요가 없으니 미리 끝내버리는 효율적인 코드라고 생각했어요.

const submitForm = e => {
  if (!isCheckEmail) {
    alert('이메일 중복을 확인해주세요.');
    return;
  }
  fetch('http://000.000.000.000:3001/user/signup', {
      // 생략  
  });
};

2. 로그인

이메일이나 비밀번호를 다르게 작성했을 때, 그에 맞는 alert창을 띄워주었어요.

잠깐!🖐🏻 기억에 남는 코드가 있다면?

요청에 대한 응답 메시지에 따라 access token을 저장하거나 alert창을 띄우게 만들고자 했어요. if...else if로 나누어주면 되겠다고 생각해 아래와 같이 나누어주었죠.

if (data.message === 'ACCESS_SUCCESS') {
  localStorage.setItem('accessToken', data.accessToken);
  alert('로그인 성공');
} else if (data.message === 'WRONG_EMAIL') {
  alert('이메일 다시');
} else if (data.message === 'WRONG_PASSWORD') {
  alert('비밀번호 다시');
}

하지만, 아까 기억에 남는 코드 첫번째의 경우와 같이 if...else if로 코드를 쭉 나열할 필요가 없었어요. 만약 로그인 성공이라면 바로 return함으로써 쓸데없이 밑의 코드를 읽어갈 필요가 없게 할 수 있었죠.

if (data.message === 'ACCESS_SUCCESS') {
  localStorage.setItem('accessToken', data.accessToken);
  alert('로그인 성공!');
  navigate('/');
  return;
}
if (ERROR_MSG[data.message]) {
  alert(ERROR_MSG[data.message]);
  return;
}
alert('로그인 실패!');

또한, 에러 메시지 같은 경우는 아래와 같이 상수 데이터로 관리해줄 수 있어요.

const ERROR_MSG = {
  WRONG_EMAIL: '이메일을 다시 작성해주세요.',
  WRONG_PASSWORD: '비밀번호를 다시 작성해주세요.',
};

3. 장바구니

장바구니에 담긴 상품 목록을 불러와 수량을 조절하고 선택 주문 및 삭제가 가능한 장바구니 페이지를 만들었어요. 이 페이지를 만들며 정말 다양한 어려움이 있었고, 그래서 배운점 역시 많았어요.

⚡ 어려움1. setState()는 비동기적으로 처리된다는 것

첫 번째 어려움은 checkbox로 선택한 상품을 배열에 담는 데에서 생겼어요. 해당 배열을 state로 관리해주었었기 때문에, 선택 상품을 클릭하면 setState로 배열에 상품을 추가해주었죠. 이 때, 저는 setState가 실행되는 별도의 함수 안에서 console로 배열에 담긴 상품을 확인했어요. 그랬더니 한 박자씩 느리게 상품이 담기는 것을 확인할 수 있었죠.
setState와 같은 state 변경함수는 비동기적으로 처리된다는 사실을 인지하고 있지 못해 엄청 헤맨 경우였죠. setState는 비동기적으로 처리되기 때문에 setState가 실행되자 마자 state가 바로 변경되는게 아닌데 말이에요. 해당 setState가 오래 걸리는 작업이면, 밑의 다른 코드부터 실행한다는 것 잊지 않기!

⚡ 어려움2. 데이터를 불러오기도 전에 화면이 그려지는 것

이 문제는 통신을 하며 알게 됐어요. 제품 상세페이지에서 상품을 장바구니 페이지에 담으면, 바로 담기지 않는 문제였죠. 어떨 때는 바로 담기기도 했구요. 한 템포가 느렸어요. 장바구니에 담긴 데이터를 불러오는 것보다 화면이 먼저 그려지기 때문에 발생한 문제였어요.
제품 상세페이지에서 상품을 장바구니에 담으면 alert창💥을 띄워주자 문제가 해결됐어요. alert창으로 인해 데이터를 불러오는 시간이 생겨 해결된거였죠. 다음 프로젝트 때는 데이터를 불러올 때 loading중이란 것을 알 수 있도록 UI를 보여주도록 구현해보고 싶어요.

4. 찜목록

장바구니와 동일하게 단일 선택/전체 선택 삭제가 가능한 찜 페이지를 만들었어요.

잠깐!🖐🏻 기억에 남는 코드가 있다면?

처음 찜목록을 받아올 때와, 품목을 삭제했을 때, 이렇게 2번 찜목록 데이터를 fetch요청을 받아와요. 그래서 각각의 경우에 모두 동일한 fetch 요청 코드를 작성했었답니다. 그런데 코드 리뷰를 통해 해당 fetch요청을 함수로 묶어 사용해주면 된다는 것을 알게됐어요. getData라는 함수로 묶어 재사용해주었답니다!

const getData = () => {
  fetch('http://000.00.00.0:3000/user/like', {
    headers: {
      authorization: accessToken,
    },
  })
    .then(response => {
      // 생략
    })
    .then(data => {
      setProductData(data.likes);
    });
};

느낀점

👍🏻 잘한 점

# 소통 통신을 하는 과정에서 변경사항이 있거나 맞추면 좋겠는 부분이 있으면 지체없이 대화해 조율했다는 점이 잘한 점이라고 생각해요! 예를 들어, 장바구니에서 수량을 조절했을 때 서버에 조절한 수량 자체를 전달할 수도 있고, +1인지 -1인지만을 전달할 수도 있었어요. 어떻게 전달하고 받을것인지에 대해 맞춰보아야 했죠. 이런 부분에 있어서 서로 감정 상하는 일 없이 소통하고자 노력했고, 그 결과 통신까지 잘 이어질 수 있었단 생각이 들어요

그리고 소통의 연장선상에서 깨달은 점이 있다면, 설명의 중요성이에요. 제가 요청하고 싶은 데이터가 있다면 왜 필요하고 어떻게 사용할 것인지 대해 명확히 알고 백엔드분께도 충분히 납득할 수 있게 설명할 수 있어야함을 느꼈어요. 누구나 알아들을 수 있게 설명할 수 있는 능력을 키우자는 다짐을 합니다🤗

🤔 아쉬운 점과 개선방법

# 초기세팅 초기세팅을 성급하게 했다는 점이 아쉬워요. 공통으로 적용할 style들을 중간에 수정하고 추가하는 일도 생겼고, ESLint 경고메시지가 계속 뜨는 번거로움도 있었어요. 팀원들이 clone 받아 작업을 진행할 때 이러한 이유로 작업이 지체되는 일이 없도록 초기세팅을 꼼꼼하게 체크할 생각이에요.

또, 저는 branch 속에 branch를 만들어 각 branch의 commit이 합쳐진채 PR이 올라간 현상을 보기도 했답니다,,저 아래 이미지의 초록 가지가 보이시나요😖 결국 이렇게 branch에서 가지쳐진 branch들을 삭제하고 다시 master에서 branch를 만들고 push해서 해결할 수 있었어요. 깃허브 commit 이력이 꼬이지 않게 꼭 신경쓰기!

# 스케줄 관리 코드 리뷰를 받고 merge되는 시간까지 고려해서 스케줄을 짜지 못했어요. 기능 구현만 하면 된다고 생각했었죠. 2차 프로젝트 때는 코드 리뷰를 받고 수정해 merge되는 시간까지 고려할 생각이에요. 그러기 위해서 기능 구현을 최대한 빨리 마무리해 리뷰를 받고 수정/보완해나갈 생각입니다!

# 렌더링 React 렌더링에 대한 부분을 꼼꼼하게 고려하지 않아서 막상 전체 통신을 했을 때 한 템포 느리게 데이터를 보여주는 일이 많았어요. 개별 통신때는 잘 구현되었기에 더 멘붕이었던 것 같아요. 기능 하나하나에 집착하느라 큰 그림을 보지 못한거라고 생각해요. 사전에 이에 대한 부분을 충분히 고려해 코드를 짜야겠다는 다짐을 해봅니다🤧

# 나홀로 갇혀있지 말기 잘 구현되지 않는 기능이 있을 때, 혼자서 끙끙거리는 시간이 너무 길었던 점이 아쉬워요. 이걸로 기능 구현에 걸린 시간이 제 예상보다 좀 더뎠던 것 같아요. 프로젝트 기간이 짧았기 때문에 도저히 안되겠단 판단이 서면, 함께 고민해 빠르게 해결할 수 있었을텐데 말이에요. 뭔가 조금만 더 하면 구현될거같단 생각이 컸던 것 같아요😩 내가 맡은 파트는 도움 없이 내가 책임지고 해결해내야한단,, 그런 생각,,?

다음 프로젝트 때는 나홀로 갇히지 않으려구요! 잘 해결되지 않는 부분이 있다면 어떻게 하면 해결할 수 있는 지에 대해 충분히 공유하려고 해요.

마치며

팀원분들과 함께라서 마지막까지 힘내서 프로젝트를 잘 끝마칠 수 있었어요🎉 2주 동안 계속 달리니 2주차 막바지 가서는 체력적으로 쉽지 않더라구요ㅠㅠ 그런데 서로 잘 되지 않는 부분이 있으면 도와주기도 하고 도움받기도 하며 같이 으쌰으쌰한게 큰 힘이 됐던 것 같아요. 그리고 먹는거에 진심인 팀원분들을 만나 중간중간 맛난 식사하며 에너지 충전할 수 있어 넘 좋았습니당(◍ᐡ₃ᐡ◍) 역시 한국인은 밥심..!🍚

이제 내일부터는 2차 프로젝트 시작이에요. 기대가 되면서 어떤 어려움이 기다리고 있을지 무섭기도 하지만!!!!! 그러한 어려움이 절 더 강하게 만드리라 믿습니다!! 다 덤벼!!👊🏻 내일을 시작으로 2주 뒤의 저는 또 어떤 모습으로 성장해 있을지 둑흔둑흔 설레는 마음으로,,회고를 마칩니다💞

HTTP는 Hyper Text Transfer Protocol의 약자예요. HTTP를 한 줄로 말하자면, 컴퓨터들끼리 HTML파일을 주고받을 수 있도록 하는 소통방식이라고 할 수 있어요.

서버로 데이터를 전송해야하는 웹 프론트엔드 개발자를 꿈꾸는 저로서는 꼭 알고있어야할 개념이에요!

• *Hyper Text * 문서와 문서가 링크로 연결돼 접근 할 수 있는 텍스트
• *Transfer * HTML로 만든 웹페이지 문서를 전송 (보내는 주체🙋🏻‍♀️와 받는 주체🙋🏻‍♂️ 있음)
• *Protocol * 컴퓨터끼리 어떻게 HTML파일(Hyper Text)을 주고 받을지에 대한 약속

📜 HTTP란? HTTP(Hyper Text Transfer Protocol)은 웹 상에서 정보를 주고 받을 수 있는 프로토콜이며, 주로 HTML 문서를 주고받는 데에 쓰인다. 위키백과, HTTP

Request(요청)

HTTP의 특징 중 하나는 클라이언트와 서버 사이에 이루어지는 Request(요청)와 Response(응답)프로토콜이에요. 먼저 Request(요청)에 대해 알아볼게요.

서버에 요청을 보낼 때는 요청에 대한 정보를 담아줘야 해요. 그래야 서버는 클라이언트에서 어떤 정보를 원하는 지를 알 수 있죠.

HTTP 메시지는 시작줄(Start Line), 헤더(Headers), 본문(Body)로 구성돼요.

💬 HTTP 메시지 구성

1. 시작줄(Start Line)
2. 헤더(Headers)
3. 본문(Body)

1. 시작줄 (Start Line)

• 예시 POST/login HTTP/1.1

• 구성 HTTP method/Request target/HTTP version

• 상세 HTTP method : GET, POST, DELETE와 같은 액션을 정의 Request target : 요청이 전송되는 목표 URL HTTP version : HTTP 버전으로, 주로 1.1버전이 많이 쓰임

2. 헤더 (Headers)

헤더는 요청에 대한 정보를 담고 있으며, 아래의 예시 말고도 그 종류가 다양해요.

• 예시

  Headers : {
  Host: : www.hyerin.co.kr,
  User-Agent : chrome,
  Content-Type : application/json,
  Content-Length : 50,
  }

3. 본문 (Body)

본문(Body)에는 요청의 실제 내용이 들어가요.

Body : {
    "username" : "hyerin",
    "password" : "hyerin123",
}

Response(응답)

클라이언트가 서버에 보낸 요청에 대해 서버는 응답을 보내줘요. 응답도 요청과 마찬가지로 메시지인데요, 이 또한 크게 세 부분으로 구성돼요.

💬 HTTP 메시지 구성

1. 시작줄(Start Line)
2. 헤더(Headers)
3. 본문(Body)

1. 시작줄 (Start Line)

• 구성 HTTP version Status Code Status Text

• 상세 HTTP version : HTTP 버전 Status Code : 응답 상태 코드 Status Text : 응답의 상태를 간략히 설명하는 텍스트

• 예시 HTTP/1.1 404 Not Found

2. 헤더 (Headers)

요청의 헤더와 동일해요. 헤더는 응답에 대한 정보를 담고 있으며, 요청의 헤더와 마찬가지로 그 종류가 굉장히 다양해요.

Headers : {
    Host: : www.hyerin.co.kr,
    User-Agent : chrome,
    Content-Type : application/json,
    Content-Length : 50,
}

3. 본문 (Body)

본문(Body)에는 응답해줄 데이터를 넣어줘요. 로그인 요청에 대해 성공했을 경우, 아래와 같이 성공 메시지와 토큰을 전달해줄 수 있죠!

Body : {
    "message" : "success",
    "token" : "dasldkfjowiejrfasdf",
}

참고

HTTP란 무엇인가 HTTP

🤗 1차 프로젝트를 진행하며 쿼리 스트링을 알게됐어요. URL에도 부가적인 정보를 담을 수 있다는게 정말 신기했답니다. 하지만 아직 제대로 사용하고 있단 생각이 들진 않아서 차차 살을 덧붙여가며 공부를 해볼 생각이에요.

쿼리 스트링(Query String)

https://www.hyerin.com/cart?productId=1&productId=2&productId=3

💁🏻‍♀️ 쿼리스트링은 URL의 한 부분입니다. 요청하고자 하는 URL에 추가 정보를 포함하고 싶을 때 사용하죠. key=value의 형태의 문자열로 표현하는데, URL에서 쿼리 스트링이 시작된다는 표시는 ?를 통해 표현할 수 있습니다. URL내의 여러개의 key=value쌍을 구분하고자 할 때는 &를 통해 구분할 수 있어요.

삭제 요청 보내기

쿼리 스트링을 사용해 삭제할 품목들의 상품ID를 URL을 담아 서버에 DELETE 요청을 하고자 했어요. 삭제할 품목들은 checkbox로 선택할 수 있었고, 사용자가 상품을 체크하면 checkedList라는 배열에 상품ID를 담았죠.

삭제할 제품을 체크하면 URL에 productId=선택한상품ID&를 붙여줘야 했어요. 여러개를 선택했을 경우 해당 상품들을 모두 URL에 쭉 붙여줘야 했으므로 반복문을 사용해 URL에 함수를 넣어줬어요.

아래의 코드는 반복문을 사용해 삭제할 상품ID를 쿼리스트링 형태에 맞게 붙이도록 한 함수입니다. 마지막의 &은 제거해줘야하기 때문에 slice()를 사용해 마지막 &을 제거해주는 작업 필수-!

// 선택 삭제 클릭 시 선택한 상품ID 반복해 붙이기
const checkedQueryString = () => {
    let checkedProducts = '';
    for (let i = 0; i < checkedList.length; i++) {
      checkedProducts += `productId=${checkedList[i]}&`;
    }
    return checkedProducts.slice(0, -1);
};

아래의 deleteChecked는 선택 삭제 버튼을 클릭하면 fetch로 DELETE요청을 보내는 함수입니다. 선택한 상품이 있을 경우에는 요청을 보내도록 했고, 그렇지 않은 경우에는 alert창을 띄우게 했어요.

// 선택 삭제 클릭 시 선택한 상품ID를 쿼리 스트링 형태로 요청
const deleteChecked = () => {
    if (checkedList.length > 0) {
      fetch(`http://172.20.10.6:3000/cart?${checkedQueryString()}`, {
        method: 'DELETE',
        headers: {
          authorization: accessToken,
        },
      })
    } else {
      alert('삭제할 상품을 선택해주세요!');
    }
};

🎀 분리되어 있지 않은 컴포넌트를 분리해서 재사용하는 실습을 했어요. 실습을 하며 되도록 컴포넌트를 재사용할 수 있는 방법에 대해 고민할 수 있었습니다! :)

1. UI 구성 요소 파악

첫번째, 두번째, 세번째 카드 중에서 비슷한 요소들을 색깔로 구분지어 봤어요. 이미지, 태그, 제목, 설명은 텍스트의 내용만 다르고 화면에 그려지는 모양은 같은 것을 알 수 있었어요.

2. Mock Data

UI가 어떻게 구성되어 있는지 파악했으니, Mock Data를 만들었어요. 이미지, 태그, 제목, 설명을 각각 키로 생성했죠! 그리고, 해당 카드가 카드 형태인지, 리스트가 들어있는 카드 형태인지, 그리고 리스트가 앨범형식으로 되어있는 카드 형태인지를 구분지어주기 위해 카테고리를 다르게 설정해줬어요.

CardData.json

[
  {
    "category": "card",
    "img": "https://t1.kakaocdn.net/friends/prod/main_tab/home/home_20201103134054_kr.jpg?type=thumb&opt=R329x247@2xa",
    "tag": "new",
    "title": "촉촉함을 원해요",
    "content": "재채기는 콜록 콜록 눈,코,입 모두 간질 간질. 이게 다 건조함 때문이라구! 건조함을 해결하러 온 꿀꿀꿀귀탱 가습기들, 구경해볼까요?"
  },
  {
    "category": "list",
    "img": "https://t1.kakaocdn.net/friends/prod/main_tab/home/home_20201106164745_kr.jpg?type=thumb&opt=R329x247@2xa",
    "tag": "good",
    "title": "통통미 폭발 구름 폭신 필로우",
    "content": "통통하고 말랑 말랑한 너희에게 내 하루 시작과 끝에서 힐링을 부탁해!"
  },
  {
    "category": "list-card",
    "img": "https://t1.kakaocdn.net/friends/prod/main_tab/home/home_20201111183631_kr.jpg?type=thumb&opt=R335x187@2xa",
    "tag": "theme",
    "title": "올 겨울엔 프렌즈랑 메리 화이트 크리스마스!",
    "content": "올해 크리스마스엔 눈이 올까요? 안오면 어때요. 이미 프렌즈들이 내 마음에 하얀 눈을 내려주고 있는걸!"
  }
]

그리고 해당 json파일을 부모 컴포넌트에서 cardData라는 state에 저장해줍니다.

const [cardData, setCardData] = useState([]);
  useEffect(() => {
    fetch("/data/CardData.json")
      .then((res) => res.json())
      .then((data) => setCardData(data));
}, []);

3. 부모 컴포넌트와 자식 컴포넌트

앞서, 데이터를 부모 컴포넌트에 저장했다고 했는데요. 저는 반복될 카드들을 자식 컴포넌트로 분리시켰어요. CardList는 부모 컴포넌트, 그리고 Card는 자식 컴포넌트로 관리해줬답니다.

// CardList.js (부모 컴포넌트)
const CardList = () => {
  // Mock Data 불러와 저장
  const [cardData, setCardData] = useState([]);
  useEffect(() => {
    fetch("/data/CardData.json")
      .then((res) => res.json())
      .then((data) => setCardData(data));
  }, []);

  return (
    <div>
      {cardData.map((data) => (
        <Card
          category={data.category}
          img={data.img}
          tag={data.tag}
          title={data.title}
          content={data.content}
        />
      ))}
    </div>
  );
};

5. 리스트가 포함된 카드라면?

# 리스트와 앨범형 리스트

리스트가 포함된 카드는 리스트를 보여줘야하고, 앨범형 리스트가 포함된 카드는 앨범형 리스트를 보여줘야해요. 쓰일 내용을 부모 컴포넌트로부터 props로 받아와서 사용했어요. 태그 스타일같은 경우 class이름도 태그 이름에 따라 변경될 수 있도록 해줬죠!

리스트도 두 가지 종류였기 때문에 category가 list인 경우에는 리스트 형태를 보여주고, category가 앨범형 리스트인 list-card인 경우에는 앨범형 리스트를 보여주도록 해줬어요.

# 개선해볼 수 있는 부분

하지만 list와 list-card의 경우도 class명만 다르기 때문에 아래 코드도 그리 효율적이지 않아 보여요. Mock Data에 리스트인지 앨범형 리스트인지도 구분할 수 있는 키를 만들면, class명을 해당 키로 구분할 수 있을거란 생각이 들어요!

// Card.js (자식 컴포넌트)
const Card = ({ category, img, tag, title, content }) => {
  return (
    <>
      <article>
        <div>
          <img alt="cardImg" src={img} /> // 이미지 url 변경
        </div>
        <div>
          <div>
            <span className={tag}>{tag}</span> // 태그 스타일과 태그 내용 변경
          </div>
          <h3>{title}</h3> // 제목 변경
          <div>
            <p>{content}</p> // 내용 변경
          </div>
          {category === "list" && ( // 리스트인 경우
            <ul>
              <li></li> 
              <li></li> 
              <li></li>
            </ul>
          )}
          {category === "list-card" && ( // 앨범형 리스트인 경우
            <ul>
              <li></li> 
              <li></li>
              <li></li> 
            </ul>
          )}
        </div>
      </article>
    </>
  );
};

로그인 시, 사용자가 input에 값을 입력했을 때 아이디란에는 @가 꼭 포함되도록 하고, 비밀번호의 길이는 5자 이상이 되도록 하고 싶었어요. 둘 다 제대로 입력했을 때 로그인 버튼이 활성화되도록 만들고자 했죠.
그래서 처음에 생각한 방식은 사용자가 input에 값을 입력할 때마다 onKeyUp이벤트 핸들러로 사용자가 조건에 맞게 작성했는지 확인하는거였어요.

✅ 리팩토링 전

💥 문제점

1. disabled속성을 state로 관리 : boolean인 disabled속성을 state로 선언해 따로 관리하고 있어요.
   
2. onKeyUp 이벤트 핸들러 : 사용자가 입력할 때마다 값을 확인해서 setState로 disabled속성을 조정해줍니다.

// Login 컴포넌트
const Login = () => {
  const [disabled, setDisabled] = useState(true);
  const handleDisabled = () => {
      let validation = userId.includes("@") && userPw.length > 4;
      return validation ? setDisabled(false) : setDisabled(true);
  };

  return (
    <form>
       <input onKeyUp={handleDisabled} />
       <button
      style={
        disabled === true
          ? { backgroundColor: "rgb(0, 149, 246, 0.3)" }
          : { backgroundColor: "rgb(0, 149, 246, 1)" }
      }
      disabled={disabled}
      >
      로그인
      </button>
    </form>
  )
}

✅ 리팩토링 후

🎉 해결 유효성 검사는 true or false로 판별한다는 것!
: 아이디나 비밀번호가 조건에 따라 제대로 쓰였는지에 대한 결과는 boolean값인 true나 false죠! 따라서, 이 조건을 바로 disabled속성에 적용시키면 돼요. 조건에 맞으면 true니까 버튼이 활성화될 것이고, 조건에 맞지 않으면 false가 돼 버튼이 비활성화 되겠죠!

// Login 컴포넌트
const Login = () => {
  const isInputValid =
  userId.includes("@") &&
  userPw.length > 4 &&;

  return (
    <form>
       <input />
       <button
        style={
          isInputValid
            ? { backgroundColor: "rgb(0, 149, 246, 1)" }
            : { backgroundColor: "rgb(0, 149, 246, 0.3)" }
        }
        disabled={!isInputValid}
       >
        로그인
       </button>
    </form>
  )
}