[3월] 원티드 프리온보딩 프론트엔드 2회차

https://www.codenary.co.kr/

스타트업들의 기술 스택과 기술 블로그를 한눈에 살펴보세요 | 코드너리

기술 스택에 따라 기업을 볼 수 있음. 몇 개의 기업에서 사용중인지를 알 수 있다.

 

상태관리

- 모든 애플리케이션은 state 값이 있음

- 컴포넌트 간의 다른 상태를 공유함으로써 애플리케이션을 reactive 하게 유지할 수  있음

- state에서 변경 사항이 발생했을 때, 이 변경 사항을 사용하는 모든 뷰에서 반영이 되어야 함

- props drilling (중간 단계를 없애는 것을 방지!)

- 어떤 아키텍쳐를 사용하는 지에 따라서 데이터 흐름은 달라지고 뷰에 반영하는 방식도 달라진다. ex> MVC, Flux

 

MVC pattern

Model: 애플리케이션의 데이터를 처리함.

View : 데이터를 표시하는 역할을 하는 UI, ddata-flow의 마지막 단계

Controller: View와 Model 구성 요소 사이의 인터페이스

- 컴포넌트간 데이터가 흐름이 다방향으로 흐르는 건 문제 없음. 오히려 좋을지도, but 데이터가 여러 방향으로 진입될 때 서로 동기화가 되지 않을 가능성이 커짐

 

Flux pattern

react에서 Redux로 flux pattern을 차용한 것

단방향 데이터 흐름으로 뷰 컴포넌트 구성하는 것

 

MVC vs Flux

공통점 : 두 유형 모두 뷰에 데이터와 이벤트가 유입된다.

다른점 : 뷰에서 나오는 데이터의 유형

일반적인 뷰는 이벤트 핸들러 함수가 다른 컴포넌트와 통신할 때 제약이 없다.

사용자가 버튼을 클릭하면 뷰가 컨트롤러에 직접 동작을 호출하거나 모델상태를 변경하거나 다른 뷰의 상태를 변경할 수 있음

 

flux에서 뷰는 오직 액션을 전송하는 dispatch 역할만 할 수 있음. 진입점이 하나로, 스토어의 상태가 변경됨 단방향임

 

flux는 Store가 여러개 있을 수 있지만, redux는 1개의 스토어만 사용함.

flux 패턴에서는 각 스토어는 상태 변경을 독립적으로 처리할 수 있음. 이벤트와 콜백을 통해 상태가 업데이트 되고 스토어에서 비즈니스 로직을 처리함.

redux의 경우에는 reducer에서 상태변화를 처리하고 비즈니스 로직을 처리함 그다음 store를 업데이트 함

flux, redux 둘 다 데이터는 단방향으로 흐름

 

redux 3가지 원칙 (면접에서 잘 나옴)

- 전체 상태값을 하나의 객체 (store) 에 저장한다.

- 상태값은 불변 객체다.

- 상태값은 순수 함수 (reducer) 에 의해서만 변경되어야 한다. 리듀서를 통해서만 상태값이 변경된다는 뜻.

 

Single Source of Truth

- 데이터 관리 핵심 원칙

- 애플리케이션의 모든 데이터, 상태가 단 한 곳에서 관리되어야 한다.

- 일관성 : 모든 상태가 한 곳에서 관리 -> 상태가 불일치 되는 경우 없음

- 예측 가능성 : 모든 상태가 중앙관리가 되면 데이터 흐름을 쉽게 추적할 수 있음

- 재사용성 : 상태관리 로직을 중앙에서 관리하면, 다른 부분에서도 상태를 재사용할 수 있음.

 

Action 

- state에 변화를 주기 위한 동작을 의미함

- 액션은 객체임, 객체는 type, payload를 가지고 있다.

{

type: 'ADD_TODO';

payload: 'todolist1';

}

- type 고유한 값, 고유 이름

- redux-devtools 에서 이 type으로 확인할 수 있음

- Action Creator 액션 만드는 함수

action은 하나만 사용하지 않고 여러개 사용할 때도 많아서, 대신 만들어주는거임

 

Middleware

- 리듀서가 액션을 처리하기 전에 실행되는 함수

action - (middleware) -> reducer -> store

- 리듀서 호출 전후에 필요한 작업을 정의할 수 있음 (ex. 에러 핸들링, 비동기 처리, side effect)

- 만약 미들웨어가 없다고 하면 리덕스는 리듀서를 통해서 이전 상태에서 새로운 상태를 계산하기만 한다.

ex> Saga, thunk(Redux 툴킷에 내장되어있음 redux store와 상호작용)

 

Reducer (순수함수임. 똑같은 input- > 똑같은 Output)

- reduce 입력 값에 처리를 해서 원하는 결과로 축소시키는 것임

- (prevState, action) -> nextState

- action이 발생하면, action을 처리해서 State를 변경하는 함수

- action에 type 값에 따라서 상태에 변화를 준 뒤, 새로운 state를 만들어서 return 함

- 리듀서 내부의 모든 처리는 동기적이고 순수하다. 하지만 실제 애플리케이션에서는 ajax 비동기 요청이나 impure한 작업이 생길 수 있다.

이런걸  함수형 프로그래밍에서 sideeffect 부작용이라고 한다.

- combineReducers() : Reducer 합쳐서 rootReducer 만들어서 configureStore에 넣어준다.

 

Store

- 앱의 전체 상태 트리를 가지고 있는 저장소. 객체로 이루어짐

- 상태가 담긴 곳

- configureStore() : 리덕스 관련해서 설정값들 지정할 수 있음. 리듀서 조각들을 자동으로 합쳐주고, 기본 제공되는 redux-thunk를 포함해서 지정한 미들웨어를 더해주고 ReduxTools 사용가능

 

useDispatch()

- dispatch : action을 실행시키는 함수

- dispatch를 이용해서 컴포넌트 내부에서 action을 실행함

- useDispatch() hook 을 사용하여 dispatch를 정의함

 

useSelector()

- Store의 state에서 필요한 데이터만 select 하게 해주는 훅

- action이 dispatch 됐을 때 이전 결과값과 현재 값을 비교해서 값이 바뀌었을 때만 컴포넌트가 리렌더링 된다.

- const user = useSelector((state) => state.userSlice.user)

 

createSlice()

- slice : 특정 값에 대한 action과 reducer가 정의된 function

- slice에 reducer와 state에 해당하는 action creator와 action type이 만들어짐 (한꺼번에 만들어줌)

- Store를 slice해서 state, action, reducer를 만든다 이런 뜻임

- 이름과 상태 초기값, 리듀서 함수들로 이루어진 객체를 받아 그에 맞는 액션 생산자와 액션 타입을 포함하는 리듀서를 자동으로 만들어 줌

 

createAsyncThunk()

- thunk 특정 작업을 나중에 할 수 있도록 Redux Store와 상호 작용을 하는 함수

- 비동기 처리시 사용

- 액션 타입 문자열과 프로미스를 반환하는 함수를 받아 pending / fulfiled / rejected 액션 타입을 디스패치 해주는 Thunk를 생성함 (분기처리)

- 3가지 파라미터

 type : 액션 타입으로 문자열이 들어감. 이 값을 기반으로 pending 등 타입이 생성되어 reducer가 생성됨

payloadCreator : 콜백함수, 프로미스를 반환하는 비동기 함수

option : 객체

비동기 처리할 때 사용, 분기처리 가능, Extrareducers 나 값들을 써서 3가지 타입으로 디스패치 하는 thunk를 생성할 수 있음

 

extraReducers

- Reducer에서 끝내지 못한 일들을 할 수 있게 해주는 함수

- slice reducer에 맵핑된 액션함수가 아니라, 외부의 액션을 참조하기 위해 사용됨

- 일반적으로 thunk를 핸들링할 때 사용해서, addCase로 api call 한 것을 분기처리 해줄 수 있다.

 

현업에서 react-query, recoil 많이 사용 (어드민 만들 때)

전역상태관리하는 상황 : state 값을 보내주려면 props로 보내줘야 하는데, 타고타고 보내주면서 상태를 보내줄 수 있는데 그렇게 하는건 너무 낭비여서.. 로그인 상태같은 경우! navbar같은거 만들 때  store에서 바로 값을 내려줄 때!

react-query, RTK 같이 사용하는 경우.

https://codesandbox.io/p/sandbox/small-framework-un8my?file=%2Fsrc%2FApp.test.js

https://codesandbox.io/p/sandbox/small-framework-un8my?file=%2Fsrc%2FApp.test.js

 

DdRum

Sentry

디버깅할 때 좋게 만드는 모니터링 서비스 . 에러로깅도구

 

이력서 피드백

 

- 트러블 슈팅, 개발 이슈 써주기

- 개발 관련 링크 중요하게 사용하기 어떻게 개발했는지? 공부했던 블로그 어필

- 개발적인 내용을 많이 넣으면 좋음 좀 자세하게

- 어떤거 개발했는 지 어필! 자기가 할 때 어떤식으로 하는 지.  어떤식으로 일한다 어떤것에 가치를 느낀다.

- 프로젝트 관련 길게 쓰게해줌 Error Fix 같은 느낌으로 어떻게 고쳤는지 issue로 등록해서 깃허브를 잘 사용하고 있는 지도 파악해서 관리하면 좋음

- 개발을 하면서 발생할 수 있는 내용들 상세하게 작성

커밋도 잘 써야 함

똑같은 프로젝트는 양산형일 수 있어서, 본인의 프로젝트 느낌을 살려서 해야 함

어떤 것을 배웠고 어떤 것을 궁금해하는 지 이런거 좀 중요

러닝커브 중요. 러닝커브가 적은 사람인지? 어떤식으로 극복하는 지

개인 프로젝트보다는 팀프로젝트 선호

사이드프로젝트 할 때 짧은 개발 마이너스 요소 오히려 길게 고도화할 수 있는 그런 느낌으로 사이드프로젝트 시작하기

~경험이 있습니다. <- 좋은 어투 아님. ~예정입니다. 활용 예정입니다 쓰지말기 결과물만.