새벽에 쓰지 못한 채로 뻗어서 다음 날 쓰는 TIL
오늘도 간단히 다시 정리하고 싶은 부분만 적어두기로 한다😊
1. Route로 연결한 컴포넌트에는 history 객체가 전달된다. (feat. match, location)
history
객체는 컴포넌트 내에서 라우터에 직접 접근하도록 해준다.
이 말은 history
를 이용하면 언제든 다른 route로 보내버릴 수 있다는 것이다.
withRouter
로 전달해야 하는 줄만 알았지만, Route
로 연결한 컴포넌트에는 history
객체 뿐 아니라 match
, location
객체까지도 props
로 전달된다.
<Route path="cat/:cat_name" component={Cat} />
const Cat = (props) => {
return (
<button type="button" onClick={() => props.history.goBack()}>
뒤로 가기
</button>
)
}
react-router-dom 공식 문서에서 history
객체의 메소드들을 확인할 수 있다.
2. url parameter 받아오기
위의 Cat
컴포넌트에서 props.match
를 콘솔에 찍어보면 아래와 같은 결과를 얻을 수 있다. 이 중 params
에서 가져오면 끝💪🏻
{
path: "/cat/:cat_name",
params: {cat_name : "nabi"},
url: "cat/nabi"
}
3. Redux의 세 가지 특징
1) store는 프로젝트 당 하나
2) store의 state는 오직 action으로만 변경 가능
3) 어떤 요청이 와도 reducer는 같은 동작을 해야 한다.
(reducer는 순수 함수✨)
4. Ducks 구조
리덕스를 사용하기 위해서는 액션, 리듀서, 액션 생성 함수를 작성해야 한다.
큰 프로젝트를 할 때는 각각의 내용이 많아서 따로 파일을 작성한다.
하지만 지금의 나처럼 공부를 하거나 작은 프로젝트를 할 때는 나누는 것이 오히려 불편해진다.
그 때 사용할 수 있는 것이 Ducks구조다. (공식문서)
Ducks 구조를 만든 분이 제안하는 구조는 다음과 같다.
// widgets.js
// Actions
const LOAD = 'my-app/widgets/LOAD';
const CREATE = 'my-app/widgets/CREATE';
const UPDATE = 'my-app/widgets/UPDATE';
const REMOVE = 'my-app/widgets/REMOVE';
// Reducer
export default function reducer(state = {}, action = {}) {
switch (action.type) {
// do reducer stuff
default: return state;
}
}
// Action Creators
export function loadWidgets() {
return { type: LOAD };
}
export function createWidget(widget) {
return { type: CREATE, widget };
}
export function updateWidget(widget) {
return { type: UPDATE, widget };
}
export function removeWidget(widget) {
return { type: REMOVE, widget };
}
// side effects, only as applicable
// e.g. thunks, epics, etc
export function getWidget () {
return dispatch => get('/widget').then(widget => dispatch(updateWidget(widget)))
}
ducks 구조를 이용할 때 유의할 점이 있다.
전에 조금씩 공부했던 운영체제, 네트워크나 정보처리기사 필기 시험 범위와 겹치는 부분이 많아서 다시 한 번 개념을 머리 속에 정리하는 느낌으로 읽었다.
내용 중 온프레미스(On-premise)라는 단어는 사실 처음 알게되었는데, 단순히 데이터 센터나 서버실을 직접 관리하는 것을 의미한다.
단순히 온프레미스보다 클라우드의 장점이 월등히 많을 거라 생각했는데, 두 가지는 장단점이 명확하고 목적도 조금은 다른 점이 흥미로웠다.
온프레미스 : 서버가 죽지 않는 것을 목표
클라우드 : 인스턴스가 죽으면 다른 인스턴스로 빠르게 대체
이런 이유로 절대 잠깐이라도 서버가 끊어지지 않아야한다면 온프레미스를 선택한다는 것이다.
또한 보안 입장에서도 물리적 저장 장소를 명확히 알고 있어야 한다면 클라우드를 이용하기는 어렵다는 점도 생각하게 되었다.
무엇이든 한 가지가 완벽할 수는 없는 것 같다.
계속 그 장점들을 혼합하고 싶어서 '하이브리드-' 방식이 나오지만 그 마저도 완벽한 해법이 되지는 않는 듯 하다😅