TIL 20210926 [항해99 11일차]

Arong·2021년 9월 26일
0
  • 웹의 동작 방식


웹은 요청과 응답으로 굴러간다. 클라이언트가 서버에게 요청, 서버가 클라이언트에게 응답!

  • 서버리스란?

서버리스는 서버가 없다가 아니라, 서버를 신경쓸 필요가 없다.
이미 누군가가 구축해둔 서버의 일부분을 빌려서 쓸 수 있다.
우리가 인프라를 구축하고, 서버 스펙을 고민할 필요 없다는 소리!
우린 그냥, 우리한테 필요한 서버를 필요한만큼만 빌려 쓰면 된다.

  • SPA란?

Single Page Application!
말 그대로 서버에서 주는 html이 1개 뿐인 어플리케이션이다.
전통적인 웹사이트는 페이지를 이동할 때마다 서버에서 html, css, js(=정적자원들)을 내려준다면, SPA는 딱 한번만 정적자원을 받아온다.
html을 하나만 주는 이유는 많은게 있지만, 그 중 제일 중요한 건 사용성 때문이다.
페이지를 이동할 때마다 서버에서 주는 html로 화면을 바꾸다보면 상태 유지가 어렵고, 바뀌지 않은 부분까지 새로 불러오니까 비효율적이다.(사용자가 회원가입하다가 적었던 내용이 날아갈 수도 있고, 블로그같은 경우, 페이지마다 새로 html을 받아오면 바뀐 건 글 뿐인데 헤더와 카테고리까지 전부 다시 불러와야 한다.)
단점은 SPA는 딱 한 번 정적자원을 내려받다보니, 처음에 모든 컴포넌트를 받아온다.
즉, 사용자가 안들어가 볼 페이지까지 전부 가지고 온다. 게다가 한 번에 전부 가지고 오니까 아주아주 많은 컴포넌트가 있다면 첫 로딩 속도가 느려진다.

  • 라우팅이란?

SPA는 html은 딱 하나를 가지고 있지만, SPA도 브라우저 주소창대로 다른 페이지를 보여줄 수 있다. 이렇게 브라우저 주소에 따라 다른 페이지를 보여주는 걸 라우팅이라고 부른다.
전부 직접 구현하는 것이 아닌 이미 만들어진 라우팅 라이브러리가 있으며, 리액트 사용자들이 가장 많이 쓰는 라우팅 라이브러리를 가져와서 사용할 수 있다.

  • 리덕스를 통한 리액트 상태관리

리덕스는 여러 컴포넌트가 동일한 상태를 보고 있을 때 굉장히 유용한다!
또, 데이터를 관리하는 로직을 컴포넌트에서 빼면, 컴포넌트는 정말 뷰만 관리할 수 있다.
코드가 깔끔해질테니, 유지보수에도 아주 좋다.

  • 상태관리 흐름도

딱 4가지만 알아도 된다. Store, Action, Reducer, 그리고 Component!
아주 큰 흐름만 잘 파악해도 굳굳!


(1) 리덕스 Store를 Component에 연결한다.
(2) Component에서 상태 변화가 필요할 때 Action을 부른다.
(3) Reducer를 통해서 새로운 상태 값을 만들고,
(4) 새 상태값을 Store에 저장한다.
(5) Component는 새로운 상태값을 받아온다. (props를 통해 받아오니까, 다시 랜더링 되겠죠?)

  • 리덕스 개념과 용어

리덕스는 데이터를 한 군데 몰아넣고, 여기저기에서 꺼내볼 수 있게 해주는 친구다.
아래 용어들은 리덕스의 기본 용어인데, 키워드 삼기 좋은 용어들이다. 앞으로 자주 볼 단어들이니 미리 친해지기!

  • satate
    리덕스에서는 저장하고 있는 상태값("데이터"라고 생각해도 된다!)를 state라고 부른다.
    딕셔너리 형태({[key]: value})로 보관한다.
  • Action
    상태에 변화가 필요할 때(=가지고 있는 데이터를 변경할 때) 발생하는 것이다.
// 액션은 객체이다. 이런 식으로 쓰이고, type은 이름같은 것! 자신이 정하는 임의의 문자열을 넣는다.
   {type: 'CHANGE_STATE', data: {...}}
  • ActionCreator
    액션 생성 함수라고도 부르며, 액션을 만들기 위해 사용한다.
  • Reducer
    리덕스에 저장된 상태(=데이터)를 변경하는 함수이다.
    우리가 액션 생성 함수를 부르고 → 액션을 만들면 → 리듀서가 현재 상태(=데이터)와 액션 객체를 받아서 → 새로운 데이터를 만들고 → 리턴해준다.
// 기본 상태값을 임의로 정함
const initialState = {
	name: 'mean0'
}

function reducer(state = initialState, action) {
	switch(action.type){

		// action의 타입마다 케이스문을 걸어주면, 
		// 액션에 따라서 새로운 값을 돌려준다!
		case CHANGE_STATE: 
			return {name: 'mean1'};

		default: 
			return false;
	}	
}
  • Store
    우리 프로젝트에 리덕스를 적용하기 위해 만드는 것이다!
    스토어에는 리듀서, 현재 애플리케이션 상태, 리덕스에서 값을 가져오고 액션을 호출하기 위한 몇 가지 내장 함수가 포함되어 있다.
    생김새는 딕셔너리 혹은 json처럼 생겼다.
    내장함수는 공식문서에서 확인가능!😉
  • dispatch
    디스패치는 우리가 앞으로 정말 많이 쓸 스토어의 내장 함수! 액션을 발생 시키는 역할을 한다.
// 실제로는 이것보다 코드가 길지만, 
// 간단히 표현하자면 이런 식으로 우리가 발생시키고자 하는 액션을 파라미터로 넘겨서 사용
dispatch(action); 
  • 리덕스의 3가지 특징

(1) store는 1개만 쓴다!
-> 리덕스는 단일 스토어 규칙을 따릅니다. 한 프로젝트에 스토어는 하나만 씁니다.
(2) store의 state(데이터)는 오직 action으로만 변경할 수 있다!
-> 리액트에서도 state는 setState()나, useState() 훅을 써서만 변경이 가능하다.
데이터가 마구잡이로 변하지 않도록 불변성을 유지해주기 위함이다.
불변성이란? 허락없이 데이터가 바뀌면 안된다는 말이다.
조금 더 그럴 듯하게 말하면, 리덕스에 저장된 데이터 = 상태 = state는 읽기 전용이다.
그런데... 액션으로 리듀서에서 변경을 일으키지 않나?
→ 그것도 맞다. 조금 더 정확히 해보자!
가지고 있던 값을 수정하지 않고, 새로운 값을 만들어서 상태를 갈아끼운다.
즉, A에 +1을 할 때, A = A+1이 되는 게 아니고, A' = A+1이라고 새로운 값을 만들고 A를 A'로 바꾼다.
(3) 어떤 요청이 와도 리듀서는 같은 동작을 해야한다!
-> 리듀서는 순수한 함수여야 한다는 말이다. 순수한 함수라는 건,

  • 파라미터 외의 값에 의존하지 않아야하고,
  • 이전 상태는 수정하지(=건드리지) 않는다. (변화를 준 새로운 객체를 return 해야한다.)
  • 파라미터가 같으면, 항상 같은 값을 반환
  • 리듀서는 이전 상태와 액션을 파라미터로 받는다.

추석이 껴있어서 이번주는 목요일부터 리액트 공부를 제대로 시작하게 됐는데 많은 개념들을 배우게되서 처음에는 이해가 잘 안되 너무 어렵게 느껴졌는데 숙제들을 만들면서 조금은 알것 같아서 결과물이 만들어질때마다 뿌듯했다. 특히 나를 얼마나 아는가? 퀴즈 만들기 숙제는 너무 재밌었고 더 잘 만들고 싶다는 욕심이 생긴다. 벌써 항해를 시작한지 이주가 지나가는데 아직은 많이 부족하지만 그래도 리액트도 조금씩 알아가는 모습에 앞으로의 성장이 기대된다!! 너무 어려워서 포기하고 싶다는 생각이 들때마다 할 수 있다 다짐하면서 이 과정을 이겨내고 성장할 내 모습을 자꾸 그려봐야겠다.

profile
아롱의 개발일지

0개의 댓글

관련 채용 정보