[항해99] W3: 3주차 WIL - React 입문~React 숙련

joy_five·2022년 10월 9일
0

WIL

목록 보기
3/14

Hello, React!

항해99 3주차, 주특기 React 입문을 마치고 숙련주차 돌입!
React 👉 Javascript 👉 React 무한반복구간🤢
+) Redux, React-redux (new!)
상태관리 심화편(아니, 기초인가...?)

👏 리액트 입문 주차 회고

👍 배운 점

  • CRA
    npx create-react-app 의 놀라운 마법!
    명령어 하나로 프로젝트 폴더 뚝딱 만들어서 바로 시작할 수 있다니! 이건 혁명이다
    리액트 프로젝트에 대해 아무것도 몰라도 리액트 프로젝트에 필요한 기본 골격이 뚝딱 만들어지니, 편하기도 하고 역으로 기본 골격을 보면서 구조 이해를 하는데도 도움이 됐다.
  • Redux
    useState를 조금 더 자유롭게 사용하게 된것 같다고 안심한 순간 다가온 Redux란 녀석...동적인 데이터=상태, 상태관리=useState 로 생각했지만, 전역 상태를 관리하기 위해서는 context, reducer와도 친구가 되어야하고... Redux / Recoil / MobX / Zustand 같은 상태관리 라이브러리도 하나쯤 능숙하게 다룰 수 있어야한다니😂
    이제 막 시도해보고 있어서, 이번 주차에 redux까지 능숙하게 사용할 수 있도록 개념을 다잡아야지.

  • Redux+CRA
    +) 숙련주차로 넘어오면서 yarn add redux react-redux 명령어를 사용했는데, 아예 CRA할때 npx create-react-app my-app --template redux을 사용해서 리덕스가 포함된 프로젝트로 생성도 가능하다.

  • GIT & github
    아직 숙련되었다고 하기는 뭐하지만, 그래도 깃허브가 많이 익숙해졌다. W1에 처음으로 깃허브를 제대로 사용해본 것 같은데, 진짜 좌충우돌 얼렁뚱땅 우당탕탕으로 썼던걸 떠올려보면, 이정도면 제법 능숙하게 사용하고 있지않나😆
    잔디 심는 재미가 들렸다. 뭐, 아직은 유효한 코드가 많지는 않지만, 유튜브의 김버그님 영상을 보면서 html과 커밋메시지를 좀 더 체계화하고, 명료하게 작성해야겠다는 생각을 했다.
  • 클린코드
    이후 접한 토스의 SLASH21 웹을 통해 '실무에서 바로 쓰는 Frontend Clean Code'세션을 보았는데, 클린 코드란 무엇인지, 왜 클린 코드를 사용해야 하는지 등에 대한 이야기가 인상깊었다. 앞으로 코드를 작성할때 적합한(짧은 코드가 아닌, 적절한) 네이밍과 함수, 모듈 단위를 나누는 구조에 대해서도 인지한 상태에서 코딩하고 싶다.
    +) 클린 코드 책 사기📚

🥲 아쉬운점

  • html 구조 개판
    사실 html&css&javascript 마크업부터 기능개발까지 항해를 시작하면서 처음배우는거다보니, 내 html 코드는 죄다 div, div, div와 약간의 h1... 뜬금없는 h3... 같은 친구들로 뒤죽박죽 잡혀있기 일쑤다.
    김버그님 유튜브 영상을 보면서 구조적인 html의 중요성에 대해 되돌아보게 되었는데, pm을 3년을 해놓고 SEO나 웹접근성에 대한 고려는 없었다니, 아무리 타이니 마이크로 프로젝트여도 대실수다!!😡

  • 아직도 익숙치 않은 CSS
    프론트엔드 엔지니어라면 마크업부터 스타일링, 기능개발까지 클라이언트 단의 전반적인 컨트롤이 가능해야한다고 생각하기 때문에 계속해서 트라이해보고 있다.
    모양은 그럴듯하지만, 체계적인 구조가 잘 안잡히는 느낌이라, FLEX와 GRID 를 조금 더 공부해야겠다.
    모든 일은 ⭐️기획-계획-구조화-작업⭐️ 순으로, 기초부터 탄탄히 하기

😎 개선방향

  • html 구조 개편!
    3주차 개인과제는 div 떡칠된 코드로 제출했지만 3주차 시험에서는 나름 html 태그를 여럿 사용해서 구현해봤다.
    사실, <article></article> 태그가 더 적절했을 수도 있겠다 싶지만, 1page 구조인 점을 감안하여 투두리스트의 할일리스트와 완료리스트를 각각 <ul>로 구성하고, 개별 투두 아이템은<li> 태그를 활용하는 방식으로 구성했다.

  • Github 조금 더 알아보기
    깃 관련 포스팅이나 유튜버들의 설명을 보면 다들 깃허브 웹에서 레포지터리를 생성하고 프로젝트와 연결짓던데, 나는 프로젝트를 생성하고 프로젝트에서 레포지터리를 생성하면서 연결하는 방식이 편해서 왜 깃허브 웹에서 먼저 생성하는지 이유를 찾아보려고 한다🤔

  • JS & React 개념 숙달될때까지 Studying
    <혼자 공부하는 자바스크립트> 라는 책으로 Javascript 이론을 다지고, 거의 매일 모던 자바스크립트 튜토리얼과 모던 리액트 문서를 들락날락 거리고 있다🥲
    씹어먹을때까지 KEEP GOING👊

👊 이쯤에서 개념다지기

State: 컴포넌트의 상태

time, count와 같이 동적인 값을 상태라고 일컬으며,
동적인 값을 핸들링하기 위해 useState 라는 훅을 사용하며, useState의 일반적인 형태는 아래와 같다.

const [state, setState] = useState(초기값);

👉 더 자세한 개념

Props : 하위 컴포넌트에 데이터 전달하기

  • 부모 컴포넌트에서 자식 컴포넌트로 데이터를 전달할때 사용한다.
  • 리액트와 같은 단방향 데이터 바인딩 방식에서는 자식컴포넌트에서 부모 컴포넌트에 데이터 전달이 불가하므로, 읽기전용 데이터로 볼 수 있다.

리렌더링 발생 조건

1️⃣ state 변경

  • React.js 에서는 동적인 값을 변경할 때, 상태관리를 하여 데이터를 변경한다. 주로 리액트 훅 중에서도 useState를 활용하게 되는데, 이 state를 활용했을때, setState 로 변환한 값이 state로 업데이트 되는 시점에 리렌더링이 이루어진다.

2️⃣ props 추가

  • 부모 컴포넌트로부터 자식 컴포넌트에 props 값을 전달하게 되는데, 이 props 값이 업데이트 됨에 따라 리렌더링 된다.

3️⃣ 부모 컴포넌트가 렌더링 되었을 때

  • 새로운 props 데이터가 없을 때도 부모컴포넌트의 리렌더링 시점에 맞추어 자식 컴포넌트도 리렌더링이 이루어진다.

shouldComponentUpdate에서 true가 반환될 때 (1~3) 리렌더링이 이루어지므로, 리렌더링이 불필요하다고 판단될때는 shouldComponentUpdate 값을 임의로 'false'로 할당하여 리렌더링을 방지할 수도 있다.
그 외에도 forceUpdate가 실행될 때 리렌더링이 이루어진다.

DOM

DOM이란?

“DOM은 HTML, XML document와 상호작용하고 표현하는 API이다.
DOM은 browser에서 로드되며, Node(이하 노드) 트리(각 노드는 document의 부분을 나타낸다)로 표현하는 document 모델이다.
ex. element, 문자열, 혹은 코멘트”
출처: MDN

DOM은 문서를 노드와 객체로 분류하하는 시스템으로 DOM API가 Javascript와 같은 스크립트 언어를 이용해서 문서에 노드 추가, 삭제, 변경, 이벤트 처리 등과 같은 수정이 가능하도록 도와준다.

브라우저가 HTML을 받았을 때, 브라우저의 렌더 엔진이 이를 파싱해서 DOM 노드로 이루어진 트리를 만들고, 각 DOM 트리의 노드에서 attach 메소드가 실행된다. 스타일 → 레이아웃 → 페인팅 의 과정을 통해 우리가 알고있는 프론트 화면이 완성이 되는데, 구조가 복잡하고 사용자의 인터랙션 등에 의해 DOM이 문서를 구성하는 과정이 반복되는 횟수가 늘어나게 되면서 매번 레이아웃을 재계산하고 리렌더링 하는 불필요한 리소스가 발생될 수 있다.

이를 보완하기 위해, React는 Virtual DOM 을 이용하고 있다.

Virtual DOM

  • Virtual DOM은 뷰에 변화가 있을 때 DOM을 실제로 조작하는게 아니라, 가상 DOM에 변경사항을 모아두었다가, 최종 변경사항만 DOM으로 전달하여 브라우저 내에서 발생하는 연산 비용을 줄이기 위한 방안이다.
  • 사소한 변화가 발생할때마다 연결된 모든 연산을 브라우저에서 연산을 진행하지 않도록 방지한다고 해서 가상DOM을 사용하는 방식이 빠르다고는 할 수 없지만, 리액트는 노드 관리 과정을 수동으로 진행하지 않고, 자동화해줄 수 있는 가상 DOM을 이용하고 있다.

서버리스

  • 서버리스 !== 서버가 없다
    서버리스 모델은 서버가 없는게 아니라, 서버를 직접 컨트롤링 하지않는 모델이다. 일반적인 애플리케이션 개발과 달리 서버가 추상화되어있어, 컨테이너에 패키징만 하면 된다.
    서버를 관리하기 위해서는 운영체제 및 파일 시스템 관리, 보안 패치, 부하 분산, 용량 관리, 스케일링, 로깅, 모니터링 등등 수많은 태스크를 컨트롤해야 하는데, 서버리스 모델에서는 이 모든 태스크를 클라우드 서비스 제공업체에 이관할 수 있기 때문에 개발자의 리소스를 줄일 수 있다.

  • 서버리스 모델의 특징
    1️⃣ stateless : 데이터 통합 간소화
    2️⃣ 일회성 : 단기간에 실행 가능
    3️⃣ 이벤트 트리거 : 필요에 따라 자동 실행 가능
    4️⃣ 전체 관리 : 클라우드 제공업체에서 관리를 전담하므로, 상시 가동 애플리케이션 및 서버 대신 필요한 만큼만 사용하고 비용을 지불하는 시스템
    5️⃣ 무상태적인 기능 구현 불가 : 작은 기능으로 잘게 나눠진 함수들은 요청마다 새로 호출되는데, 기동 전후의 상태를 공유할 수 없다. 데이터를 로컬 스토리지에서 읽고 쓰기 어렵다.

  • BAAS Backend-as-a-Service
    주로 웹앱, 모바일앱에 사용되는 서비스로, 모바일 백엔드(MBaas)로도 알려져 있다. 단일 웹페이지, 모바일 앱 기반의 서비스에서 필요한 서버기능을 사용하기 위한 써드파티 애플리케이션 혹은 클라우드 서비스다.

  • FAAS Function as a Service
    로직은 개발자가 설계하되, 서버가 아닌 클라우드 컨테이너에서 작동하는 경우를 의미한다. Baas보다 높은 수준의 제어 기능을 포함하기 때문에 보다 고도화된 서비스에 적합하다.

profile
😤 Started in Sep. 2022 😎 I'm going to further!

0개의 댓글