화면 크기에 따라 컴포넌트를 다르게 렌더링하고 싶을 때,

1. resize 이벤트 이용해서 화면 크기를 state로 저장해야 하는 건 알겠는데,
2. 매번 resize 이벤트 호출하면 낭비가 아닌가?에서 시작
3. debounce 발견!

예시

화면 크기에 따라서 다른 텍스트를 보여주는 버튼을 만들 때

• width > 768px일 경우
• 그 외

작성한 코드

1. 화면 크기를 담는 state를 설정한다.

  const [windowSize, setWindowSize] = useState({
    width: window.innerWidth,
    height: window.innerHeight,
  });

window : 현재 스크립트가 작동 중인 창 window.innerWidth : 브라우저 윈도우의 뷰포트 너비로, 수직 스크롤바가 존재한다면 포함

2. useEffect로 resize 이벤트가 있으면 변경된 화면 크기를 state에 저장하는 함수를 호출하도록 한다.

  useEffect(() => {
    window.addEventListener('resize', handleResize);
    return () => {
      window.removeEventListener('resize', handleResize);
    };
  }, []);

resize 이벤트는 document view의 크기가 변경될 때 발생

useEffect훅에서 함수를 반환하면 컴포넌트가 unmount될 때 clean-up 함수가 실행된다. useEffect에 빈 배열을 전달하면, 컴포넌트가 처음 mount될 때와 unmount될 때 실행되는데, 컴포넌트가 unmount될 때 이벤트 리스너를 삭제하지 않으면 컴포넌트가 자주 리렌더링될 경우 메모리 누수가 발생하므로 리스너를 삭제하도록 한다.

3. debounce를 이용해서 resize 이벤트가 일어날 때마다 state를 변경하는 것이 아니라 마지막 resize 이벤트가 실행되고 1초가 지나면 그때서야 state를 변경하도록 한다(딱 한번!).

  const handleResize = debounce(() => {
    setWindowSize({
      width: window.innerWidth,
      height: window.innerHeight,
    });
  }, 1000);

Debounce : 동일 이벤트가 반복적으로 시행되는 경우 마지막 이벤트가 실행되고 나서 일정 시간 동안 해당 이벤트가 다시 실행되지 않으면 그때서야 해당 이벤트의 콜백 함수를 한번만 실행

4. 화면 크기(state)에 따라 보여줄 텍스트를 다르게 리턴

  return (
          <StyledButton type="primary" ghost onClick={showModal}>
            {windowSize.width > 768 ? '+ Add a Card' : '+ New'}
          </StyledButton>
        )

stackoverflow에서 아래와 같이 해결하라는 글을 봤는데 keyCode는 deprecated되어서 다시 찾아보았다.

onKeyDown={(e)=> e.keyCode == 13 ? e.preventDefault(): ''}

해결 - KeyboardEvent.key

<Input
    onKeyDown={(e) => (e.key === 'Enter' ? e.preventDefault() : '')}
    placeholder="Title"
    allowClear
/>

참고 https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent/key

cards는 여러 card 객체들로 이루어진 배열이다. [{}, {}, {}] 요렇게 생긴!! cateIdArr의 각 요소의 값을 category_id로 가지고 있는 card만을 필터하려고 했다. 필터를 하면 원치 않는 객체가 빠진 [{}] 이 모양 그대로 유지되어야하는데 자꾸 배열 안에 또 배열 안에 객체가 하나씩 들어있는 구조로 출력되었다...;;;

수정 전 코드

1) 첫 번째 시도

    cateIdArr = [3, 4]

    const arr = cateIdArr.map((cateId) =>
      cards.filter((card) => card.category_id === cateId)
    );
    console.log('arr ', arr);

출력 결과

map(), filter()

map과 filter는 모두 배열을 리턴한다! map이 forEach와 달리 배열을 리턴하는 것은 알고 있었는데, filter가 배열을 리턴하는 지 몰랐기 때문에 왜 배열 안에 각 배열이 들어간 구조로 데이터가 출력되는지 이해할 수 없었다. 역시 MDN을 잘봐야 ㅠㅠ..

2) 두 번째 시도.. 당연히 안됨 ㅠ

     const arr = cateIdArr.map((cateId) =>
      cards.filter((card) => card.category_id.includes(cateId))
    );

출력 결과

includes()

1. 배열이 특정 요소를 포함하고 있는지 판별하고, 결과를 true 또는 false 로 반환한다.
2. 하나의 문자열이 다른 문자열에 포함되어 있는지_(대소문자 구분)_를 판별하고, 결과를 true 또는 false 로 반환한다.

수정 후 코드

  const arr = cards.filter((card) => cateIdArr.includes(card.category_id));
  console.log('arr ', arr);

1. 각 카드의 category_id가 cateIdArr에 있는지 확인하려면 includes를 쓸 수 없다(includes는 배열이나 문자열에만 쓴다). category_id는 배열이나 문자열이 아니기 때문에 배열인 cateIdArr가 category_id를 갖고 있는지 확인한다.
2. 위의 조건이 true인 카드들만 filter

몇 차례의 클론코딩 끝에 코딩이란 무엇인가 간신히 알게 된(?) 후에도 간단한 todo 리스트 조차 만들지 못하는 나를 발견했다! 프로젝트를 처음부터 스스로 해봐야 코딩 실력이 늘 수 있다고 판단했다(클론코딩은 사실 너무 우울하고 슬펐다).

그래서 지난 4월 알게 된 카우치코딩에서 리액트로 게시판을 만드는 프로젝트를 했다. 정말 많이 배웠다(클론 코딩의 저주에서 벗어나 활기찬 나로 돌아왔다!). '나 이젠 진짜 개발자 한다!!'를 외치며 이번엔 취업을 하기 위한 포트폴리오 프로젝트를 시작한다. 무려 협업_으로.. 개발자로 성장하는 좋은 기회가 될 것 같다!

무엇을 만들까

운동을 좋아한다! 내가 하는 운동에 대해 다른 사람들에게 열정적으로 떠드는 것도. 크로스핏, 필라테스, 요가 이것들은 정말 다 좋은데 무엇을 하는 운동인지 사람들이 정확히 모르는 경우가 많다. 나는 더 말하고 싶다고! 크로스핏 동작을 맞추는 간단한 퀴즈 웹사이트를 만들기로 했다. 이 동작들을 내가 크로스핏 시작하기 전에 모두 봤다면 애초에 시작을 안했을텐데...

나의 역할 / 기술 스택

우리 팀은 총 3명으로, Front-end / Back-end / Project Manager 역할을 각각 담당한다. 여기서 카우치코딩의 멘토님이 PM으로서 팀을 이끌어주시고, 나는 프론트엔드 개발을 담당한다. 이전의 내 프로젝트에 이어 ReactJS와 AntDesign, StyledComponent를 사용한다. 프로젝트가 끝나면 기술을 사용하는데 더 익숙해질 것이다. 나 자신아 기운내!!

화면기획서

화면 기획은 Whimsical이라는 툴을 사용해서 아이디어를 화면에 그려나갔다.

배운 것

프로젝트 아이템이 아쉽게도(?) only 내 머릿속에서 나온 아이디어였기 때문에, 기획자의 입장에서 기획자 - 개발자 간 커뮤니케이션을 어떻게 하는지 간접적으로나마 경험할 수 있었다. 회의를 통해 의견을 교환하고, 그 과정을 통해 프로젝트의 의도가 뭐였는지 돌아가서 다시 한번 기능에 대해 고민하고 수정하는 부분이 재미있었다. 내 머릿속으로는 이해가 이렇게 잘가는데 내 말은 이렇게 나온다니..? 나 자신에게 매우 어이없었지만 커뮤니케이션의 중요성을 다시 한번 깨닫는 시간이었다.

기능명세서(일부)

배운 것

화면 기획서를 만들면서 구체화된 사항들을 기능명세서를 작성하며 수정하는 경우도 있었고, 그 반대의 경우도 있었다. 개인적으로 나는 개념을 이미지나 도표로 이해하는 visual person이 아니기 때문에 커뮤니케이션을 하는 데 있어 기능명세서를 작성해 본 것이 더욱 도움이 되었다. (+ notion 잘 쓰고 싶다)

DB명세서

배운 것

화면 기획서를 보면서 백엔드 담당 개발자 분과 함께 회의를 통해(절대적 도움을 받음) 작성했다. 다시 한번 커뮤니케이션의 중요성을 느꼈다. '내가 만든 퀴즈/카드만 보기' 기능이 있는데, 여기서 쿠키, 세션, 토큰의 차이점에 대한 이야기가 나와서 회의가 끝나고 자세히 알아보았다.

API명세서(일부)

배운 것

• put과 patch의 차이점
• REST API 설계 규칙