210920-26 2주차 항해99

0. 추석연휴 반납.

리액트(사실은 리덕스).

이번주는 TIL 로 많은 내용을 저장해두지 못해서,

어쩔 수 없이 WIL이 좀 길어질 것 같다.

(분명히 지난주에는 '이번주가 제일 길겠지' 라고 했는데 오늘이 더 길어질 듯, 이래놓고 다음주는....?)

 

 

1. 이번주 배운 것.

우선 배운 것 먼저 정리하자. 

사실 너무너무 많은 걸 머리에 쏟아부어서 (정말 머리에 뚜껑이 있다면 열어서 지식을 쏟아붓는 느낌이었다)

아직 하나하나 제자리에 정리는 안되어 있는 느낌이다.

쓰면서 정리하자. 

 

<DOM>

리액트에 들어가기 전에 프론트엔드의 기초로 맨 처음 배운 것.

HTML 단위 하나하나를 객체로 생각하는 모델 Document Object Model의 약자.

사실 이렇게 바로 이해가 되지 않았다.

자바스크립트를 이용해서 웹브라우저에 표시되는 웹페이지를 동적으로 (프로그래밍적) 접근하고 제어할 수 있게 해준 인터페이스.

여러 노드들, 요소 노드, 텍스트 노드들이 부모 자식 관계 처럼(족보나 계보? 느낌으로 이해했다) 상위, 하위의 구조로 이루어진 것.

즉, 트리 구조로 컴퓨터가 이해하기 쉽게 구조화 한 것.

(이걸 해리포터의 가문 계보, 특히 영화에 나오는 시리우스 블랙의 가문 그림이 마침 나무로 그려져 있어서 이걸 떠올리면서 이해했다.)

 

 

<Const, Let, Var 의 차이>

우선 Const 는 변수가 아니라 상수이다. 그렇기 때문에 한번 상수값을 설정하고 나면 재선언도 재할당도 안된다. 말그대로 상수.

Let는 재선언은 안되지만 재할당이 가능하다. 여기서 예를들면, 

let a = 1; 에서 'let a' 가 선언부에 해당하고, 'a=1;'이 할당부에 해당한다.

그래서 블록레벨 스코프, 쉽게 {} 안에서만 살아있다고 이해할 수 있다.

예를들어,

if(a===0){} 라는 if문 안에서 let, const를 지정해준 값과

if문 밖에서 let const 지정해준 값은 각각 살아 있을 수 있고,

콘솔로그가 if 안에서 찍히냐 밖에서 찍히냐에 따라 다른값이 나오는걸 확인할 수 있다.

Var 는 블록 밖까지가 해당되는 스코프이기 때문에, 예를들어 if문 안에서 값이 변경되면, 변경된 값이 적용되어 버린다.

이것을 함수레벨 스코프라고 한다.

 

<Spread 연산자>

많이 쓸것 같다.

어떤 객체 배열 안에 있는 항목들을 모두 풀어서 꺼낼 수 있는 문법이다.

쓰는 방법은 ... 말그대로 ... 사진을 첨부하자 ...

끝.

 

 <삼항연산자>

뭔가 수학 공부할 때 느낌이었다.

쉽게, return 안에서는 if 문을 원래 형식대로 쓸 수 없기때문에 쓰는 if문의 단축 형태.

조건 ? 참일경우 : 거짓일 경우

..... 이것도 사진이 빠를것 같다.

충분하쥬?

 

<JSX>

자바스크립트 안에 html을 넣어서 리액트 요소로 활용하는 것. 자바스크립트를 확장한 문법이다.

물론 html 과 완벽하게 똑같은것은 아니다.

 

<React>

리액트는...

쓰다보니 내용이 너무 많아져서 별도로 카테고리를 만들어 정리해야 겠다.

https://ne-dot.tistory.com/category/React

'React' 카테고리의 글 목록

 

<Redux>

리덕스는 사실 리액트 카테고리 안에 넣으려고 했는데,

마음이 바뀌었다.

리액트 라이브러리도 물론 중요하지만,

프론트엔드 공부를 하면서 가장 크게 느낀것이 '상태관리가 정말 중요하다' 라는 것.

그 상태관리를 해주는 것이 리덕스이다.

그래서 여유가 되는대로 리덕스를 깊이있게 공부해볼 생각이다.

여기서 또 하나의 카테고리와 링크가 생겼다.

정말 간단하게는, 

 

기본적으로 부모컴포넌트->자식컴포넌트의 관계로 state-props 형태의 데이터 전달방식을 쓰는 리액트를,

하나의 store에 데이터를 전달하고 각각의 컴포넌트들이 필요에 따라 데이터를 주고 받을 수 있게 하는 라이브러리.

 

사용자의 액션에 따라

1) 액션이 어떤 액션인지 미리 형태를 만들어 두고,

2) 그 액션 객체 payload를 리덕스로 dispatch하고,

3) reducer에서 새로운 state로 융합해, (여기서 reduce가 흔히 알고 있던 사전적 의미 '축소하다' 보다 '융합하다'는 뉘앙스가 더 가깝다)

각각의 컴포넌트(구독되어있는)에 전달.

 

정도로 정리할 수 있겠다.

하지만 지금 이미 리덕스의 중요성과 리덕스의 활용도에 대해 관심이 생겨버려서, 아마 틈나는대로 뎁스를 늘려갈 것 같다.

https://ne-dot.tistory.com/category/Redux

'Redux' 카테고리의 글 목록

 

<Serverless>

가장 먼저,

서버리스는 백엔드리스가 아니다!

간단하게, 서버 설정이나 사양 등이 미리 되어있는 서버를 빌려 쓸 수 있는 서비스를 이용하는것.

즉 서버 쪽 인프라 활용을 내가 별도로 작업하지 않고 가능하게 하는것.

이번 주차 개인과제에서는 이 서버리스, Firebase의 firestore를 이용해서 데이터 관리하는 방법을 배웠다.

너무나도 당연한 것이,

리액트에서 리덕스를 이용하여 상태관리를 하지만,

결국 데이터베이스가 저장이 되어있어야 로드가 가능하고, 생성, 업데이트, 삭제 CRUD가 가능해진다.

기능을 작동하게 구현하는 것을 지금 프론트엔드 리액트로 배우고 있지만,

사실상 기능이 작동하더라도 그 기능에서 다루는 데이터들이 저장되어 있지 않으면 아무 의미가 없다.

여기서 한번 더 백엔드와 프론트엔드의 상호관계를 좀 더 이해할 수 있게 되었다.

지금은 물론, 리액트에 집중하고 있는 과정이기 때문에 서버리스를 활용하고 있지만,

본격적으로 협업하게되면 백엔드와의 상호관계를 이해해야할 것이기 때문에 

이 서버리스 개념을 지금은 백엔드대리 정도로 여기면서 진행하고 있다.

 

 

2. 처음에 개발을 배우기 시작했을 때는, 

내가 공부하고 학습한 것들이 어떤 카테고리로 구분되어지고,

어떻게 접근해서 심화학습을 해야하는지 몰랐다.

(그래서 내가생각할때 겨우 TIL에 담는게 전부였던것 같다.)

하지만 그럴 때마다

다른 훌륭한 개발자 블로그들을 보며,

'아 나도 저런 전문적인? 개발자다운? 카테고리 정리가 되면 좋겠다' 라는 갈증을 느꼈다.

 

오늘 이번주에 배웠던 것들을 되짚어보다보니,

나에게도 그런 카테고리가 생긴것 같다.

물론, 이 각각의 카테고리들을 나눈 것도 아직은 맞는 것인지 잘 모른다.

하지만 지식에는 어느정도 정답이 있을지 몰라도,

학습 과정에는 무조건적인 정답은 없다고 생각한다.

그래서 우선은 내 머릿속에 있는 지식들을 하나하나 책꽂이 제자리에 꽂아두듯 정리하면서,

그걸 블로그에 남겨보는 걸 시작해보려고 한다.

 

아마 게시글 하나 하나를 올리는 것도 시간이 걸릴지 모른다.

내가 아는 내 성격상 내가 다 뜯어보고 이해하고 맛보고 즐기고 할 수 있어야,

정말 내 것이다, 내가 습득했다 라는 느낌이 들 것이기 때문.

스스로 피곤한 성격이라 생각하며 살았고,

그 덕분에 사실 지금의 개발 공부도 그렇듯, 빠른 편은 아니지만

늘 제대로된 경험이 축적되어 온 것은 부정할 수 없다.

나는 내 길을 내 과정과 내 속도로 살아왔고 후회는 없다.

이번 개발 공부도 언젠가 분명히 내것이 될것이다.

 

그런 의미에서 이번주는, 지난주보다 7만큼은 더 성장한 것 같다.