항해99 3주차, 주특기 React 입문을 마치고 숙련주차 돌입!
React 👉 Javascript 👉 React 무한반복구간🤢
+) Redux, React-redux (new!)
상태관리 심화편(아니, 기초인가...?)
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
을 사용해서 리덕스가 포함된 프로젝트로 생성도 가능하다.
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👊
time, count와 같이 동적인 값을 상태라고 일컬으며,
동적인 값을 핸들링하기 위해 useState 라는 훅을 사용하며, useState의 일반적인 형태는 아래와 같다.
const [state, setState] = useState(초기값);
👉 더 자세한 개념
1️⃣ state 변경
2️⃣ props 추가
3️⃣ 부모 컴포넌트가 렌더링 되었을 때
shouldComponentUpdate에서 true가 반환될 때 (1~3) 리렌더링이 이루어지므로, 리렌더링이 불필요하다고 판단될때는 shouldComponentUpdate 값을 임의로 'false'로 할당하여 리렌더링을 방지할 수도 있다.
그 외에도 forceUpdate가 실행될 때 리렌더링이 이루어진다.
“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 을 이용하고 있다.
서버리스 !== 서버가 없다
서버리스 모델은 서버가 없는게 아니라, 서버를 직접 컨트롤링 하지않는 모델이다. 일반적인 애플리케이션 개발과 달리 서버가 추상화되어있어, 컨테이너에 패키징만 하면 된다.
서버를 관리하기 위해서는 운영체제 및 파일 시스템 관리, 보안 패치, 부하 분산, 용량 관리, 스케일링, 로깅, 모니터링 등등 수많은 태스크를 컨트롤해야 하는데, 서버리스 모델에서는 이 모든 태스크를 클라우드 서비스 제공업체에 이관할 수 있기 때문에 개발자의 리소스를 줄일 수 있다.
서버리스 모델의 특징
1️⃣ stateless : 데이터 통합 간소화
2️⃣ 일회성 : 단기간에 실행 가능
3️⃣ 이벤트 트리거 : 필요에 따라 자동 실행 가능
4️⃣ 전체 관리 : 클라우드 제공업체에서 관리를 전담하므로, 상시 가동 애플리케이션 및 서버 대신 필요한 만큼만 사용하고 비용을 지불하는 시스템
5️⃣ 무상태적인 기능 구현 불가 : 작은 기능으로 잘게 나눠진 함수들은 요청마다 새로 호출되는데, 기동 전후의 상태를 공유할 수 없다. 데이터를 로컬 스토리지에서 읽고 쓰기 어렵다.
BAAS Backend-as-a-Service
주로 웹앱, 모바일앱에 사용되는 서비스로, 모바일 백엔드(MBaas)로도 알려져 있다. 단일 웹페이지, 모바일 앱 기반의 서비스에서 필요한 서버기능을 사용하기 위한 써드파티 애플리케이션 혹은 클라우드 서비스다.
FAAS Function as a Service
로직은 개발자가 설계하되, 서버가 아닌 클라우드 컨테이너에서 작동하는 경우를 의미한다. Baas보다 높은 수준의 제어 기능을 포함하기 때문에 보다 고도화된 서비스에 적합하다.