figma를 사용해보셨나요? 사용했을때의 장단점은 무엇이 있었나요?
(뇌피셜)
: figma는 코드 작성없이 컴포넌트의 디자인을 할 수 있게 해주는 유용한 도구였습니다.
figma를 사용함으로써 만들어야할 컴포넌트의 디자인을 가이드할 수 있었고, 좀 더 빠른 개발이 가능했다고 생각합니다.
하지만, 도구에 능숙하지 않다면 figma를 작성하는데 시간이 꽤 걸릴 것 같습니다.
그리고 디자인이 조금 어긋나 있을 경우, 보이는 컴포넌트와 똑같이 따라가려는 마음 때문에 figma를 잘못 작성하면 올바르지 않은 디자인 가이드가 될 수 있겠구나 생각했습니다.
Flux는 MVC의 어떤 문제를 해결했을까?
글이 다 날아 갔다.
- MVC의 문제점 위 MVC 패턴에서 Controller는 Model의 데이터를 조회하거나 업데이트 하는 역할을 수행하는데, Model이 업데이트 되면 View는 그것을 화면에 반영합니다.이런 양방향 데이터 흐름은 새로운 기능이 추가되거나할 때에, 시스템 복잡도가 기하급수적으로 증가시킬 수 있고, 예측 불가능한 코드를 만들게 됩니다.
- View는 Model도 업데이트 할 수도 있으며, Model이 업데이트 되어 View가 따라서 업데이트 되고, 업데이트 된 View가 다시 다른 Model을 업데이트 한다면 다시 View의 업데이트가 나타나고 ....
- 페이스북에서는 MVC의 가장 큰 단점이 양방향 데이터 흐름이라고 표현하고 있습니다.
- Flux는 어떻게 해결했을까 Flux는 양방향 데이터 흐름을 해결하기 위해서 단방향 데이터 흐름으로 설계되었습니다.데이터 흐름은 위와 같이, Dispatcher에서 Store로, Store에서 View로, View는 Action을 통해서 다시 Dispatcher로 데이터가 흐르게 된다.
- 이런 단방향 데이터 흐름을 취함으로써 데이터 변화를 훨씬 예측하기 쉽게 만들 수 있습니다
- Flux의 구성요소
- DIspatcherAction이 발생되면 Dispatcher로 전달되고, 전달된 Action을 보고, 전달된 콜백함수를 실행하여 Store에 데이터를 전달합니다.
- Dispatcher는 모든 Flux 데이터 흐름을 관리하는 허브역할을 하고, 1개의 인스턴스만 존재합니다.
- StoreStore가 변경되면 View에 변경되었다는 사실을 알려주기 위함입니다.
- 또한, Store는 싱글톤으로 관리됩니다.
- 어플리케이션의 모든 상태 변경은 Store에 의해 결정이 됩니다. Dispatcher로 부터 메시지를 수신 받기 위해서는 Dispatcher에 콜백함수를 등록해야 합니다. (listen)
- View
- VIew는 화면에 나타내는 것 뿐만 아니라, 자식 View로 데이터를 흘러보내주는 view-controller 역할도 함께 합니다.
- Action그 객체 인자가 바로 Action이다.
- Dispatcher에서 콜백함수가 실행되면 Store가 업데이트 되게 되는데, 이 콜백 함수를 실행 할 때, 데이터가 담겨있는 객체가 인자로 전달된다.
Flux 패턴에서 다양한 구현 라이브러리가 있는 이유는 무엇일까? (flux, redux, mobx, recoil 등)
https://www.npmtrends.com/flux-vs-mobx-vs-redux-vs-reflux
https://stackoverflow.com/questions/32461229/why-use-redux-over-facebook-flux
모두다 flux의 철학을 기반으로 하고 있으며,
flux에서의 기능들을 보완하여 출현하게 된 라이브러리이다.
https://lannex.github.io/blog/2020/redux-mobx/
https://woowabros.github.io/experience/2019/01/02/kimcj-react-mobx.html
- MobX
Store는 데이터를 받아오고Mobx는 렌더링할 State를 관찰대상으로 지정하고, State를 변경하면 React Component Render 메서드로 리렌더링되는 것을 기본으로 깔고 간다.
- 특징
- 객체 지향적이다. (캡슐화)
- ES6에서 추가된 Class를 이름뿐인 Class가 아니고 객체지향적으로 사용하고 개발하는 것을 권장한다.
- 서버개발자들에게 친숙하다.
- Java Spring Framework와 유사한 아키텍처구조를 지향하고 있어서, 서버개발자들에게 보다 친숙하고 낮은 러닝커브를 제공한다.
- DecoratorRedux에서 React Component와 state를 연결하기 위한 mapStateToProps, mapDispatchToProps, bindActionCreator 등등의 보일러 플레이트가 사라져서 깔끔한 코드가 생성된다.
- Mobx Configuration 설정으로 State를 오직 메서드를 통하여 변경할 수 있도록 Private하게 관리할 수 있다.
- (java의 어노테이션과 유사하다고 생각하면 됨.)
- 여러 개의 store를 가질 수 있다.
- 불변성을 더이상 신경 쓰지 않아도 된다. 상태로 class로 캡슐화가 잘 되어있기 때문인듯.
- 함수형 프로그래밍 원칙이 별로 적용되지 않았다. class위주로 구현됨
- 다른 라이브러리의 필요성이 낮아짐 (redux처럼 비동기 동작 등을 위한 thunk 미들웨어가 불필요하다.)
- 버전 별로 차이가 심하다. (특정 브라우저를 지원 안하는 버젼도 있다)
- 레퍼런스가 부족하다.
- Dev Tool이 별로다.
- 특징
- 또한, Java Spring Framework와 유사한 Layer 아키텍처를 지니고 있어서, 실제로 그런식으로 Layer를 분리하여 아키텍처를 구성한다.
- Component에게 전달해주고 렌더링한다는 원리이다.
- 데이터 흐름은 위와같이, Componenet가 Store에서 데이터를 요청하고,
- Mobx는 redux와 비슷한 종류의 State관리 라이브러리이다.
- Redux
- 하나의 store를 가진다.
- store의 데이터는 불변이다
- 상태를 컴포넌트 구조의 바깥에 두고, 스토어를 중간자로 두고 상태를 업데이트 하거나 새로운 상태를 전달 받을 수 있음.
- redux를 위한 보일러플레이트가 존재해서 러닝커브가 높은 편임
- 틀이 정해져 있어서 안정성이 높아질 수 있다.
- flux 아키텍처를 라이브러리로 구현한 것이 바로 redux이다.
- dev tool 지원이 잘되어 있다.
- Recoil
- 사용법은 아래 링크를 통해 참고하자. https://deview.kr/data/deview/session/attach/Recoil왕위를계승중.pdf
- atom과 selector가 주 개념임.
- 장점
- - React와 굉장히 잘 연계됩니다. - 사용법이 직관적이고 단순합니다.
- 단점
- - Hooks를 통해서만 사용할 수 있습니다. - 프로덕션 레벨에서 사용하기엔 아직 약간의 부담이 있습니다. - 현재는 디버깅 도구의 지원이 미미합니다.
요약!
https://deview.kr/data/deview/session/attach/Recoil왕위를계승중.pdf
- Context API등 상태 관리 라이브러리가 존재하지 않던 시절이 있었고,
- Flux 아키텍처가 등장했고 사람들은 그것을 사용했다.
- Flux 아키텍처를 라이브러리화한 redux와 mobx가 동시대에 출시되었다.
- redux가 react 상태관리 시대를 평정하게 되었다. (뇌피셜) 이긴 이유로는 hook의 등장으로 함수 컴포넌트가 class보다 우세하게 되었고 dev tool을 잘 지원하고 있으며 레퍼런스가 많고 틀이 딱딱 정해져있어서 안정성이 높았기 때문으로 생각한다.
- recoil이 등장했다. redux보다 직관적이고 코드의 양도 적어서 각광을 받게됨. 개발자들은 쉽고 단순한것을 좋아하기 때문 하지만 나온지 얼마되지 않아서 redux에 몸싸움으로 밀린다.
redux가 기존 flux와 다른 점은 무엇일까?
https://taegon.kim/archives/5288
페이스북은 Flux 아키텍처를 발표한 후에 Flux에 대한 구현체도 공개했는데,
그 때에는 dispatcher만 구현되어 있어서 Flux 프레임워크라고 부르기엔 다소 무리가 있었다.
그 때 많은 구현체들이 나타났는데 그것이 바로 redux이다.
Redux는 다른 구현체와 비교해서 사용법이 단순하고, ES2015도 잘 지원하고, 용량도 2kb로 상당히 작은 편이다. Flux를 만든 개발자들도 칭찬을 할 정도로 Flux원칙을 충실히 지켰다고 한다.
원래 페이스북이 고안한 Flux에서는 Action Creator가 dispatcher를 호출하는 작업도 했으나, 만에 하나라도 있을 수 있는 부작용을 없애기 위해서 action만 만드는 역할만 담당하도록 redux에서 개선되었다.
Redux는 dispatcher를 명시적으로 생성하지 않고도 Flux를 구현할 수 있도록 작성되어서, dispatcher를 생략할 수 있다. (store의 dispathcer를 사용하면 됨)
Redux는 Flux에는 없는 개념인 Reducer를 고안했다. Action은 어떤일이 일어났는지 알려주지만, 어플의 상태를 어떻게 바꾸어야 할지는 알려주지 않는다. Redux 프레임워크에서는 Reducer가 이 역할을 담당한다. => flux의 store객체를 업데이트하는 콜백함수와 역할이 비슷
Redux Store가 싱글톤으로 구현됨으로써 얻을 수 있는 이점은 무엇인가?
Having a single store enables using the Redux DevTools, makes persisting and rehydrating data simpler, and simplifies the subscription logic.
싱글톤으로 구현함으로써 Redux DevTools를 사용할 수 있게 되었고, 데이터 유지보수가 간단해지고, store와 관련된 로직도 단순해진다.
+ single source of truth
redux의 reducer가 지켜야할 규칙은?
https://taegon.kim/archives/5288
redux의 3가지 원칙은 무엇인가?
- single source of truth컴포넌트가 많아질 수록 state가 업데이트 된 이유를 알기 위해서 컴포넌트 트리를 추적해야하는데, redux는 단일 store에 상태를 저장해서 상태관리를 단순화 시켜주었다.
Redux는 Store가 1개로 이루어져서 이 원칙을 만족한다. - 상태는 읽기 전용
상태는 action을 통해서 명령을 내려 갱신할 수 있다. - 순수 함수로 변경이 이루어져야한다.Reducer는 이전 상태와 action을 인자로 받아서 새로운 상태를 리턴하는 순수 함수이다.
redux의 구성요소는 무엇인가?
store, reducer, action
react-router와 react-router-dom 라이브러리의 차이점은 무엇인가?
react-router란 클라이언트 사이드에서 주소값의 변경에 따라 페이지 혹은 컴포넌트의 변화를 제공하기 위한 라이브러리이다.
React-router-dom 은 react-router에서 DOM이 인식할 수 있는 컴포넌트들만 뺀 라이브러리 이다. Link, BrowserRouter 등이 여기 포함되어 있다.
SPA란?
Single Page Application의 약자이다.
말 그대로 페이지가 1개인 어플리케이션이다.
전통적인 어플리케이션 구조는 유저가 요청할 때 마다 페이지가 새로고침되며, 페이지를 로딩 할 때 마다, 서버로부터 리소스를 전달받아 해석 후 렌더링을 합니다. HTML 파일, 혹은 템플릿 엔진 등을 사용해서 어플리케이션의 View가 어떻게 보여질지도 서버에서 담당했었습니다.
요즘 시대에는 웹에서 제공되는 정보가 정말 많아서 속도적인 측면에서 문제가 있었고, 이를 해소하기 위해서 캐싱과 압축을 해서 서비스가 제공되었다.
렌더링하는 것을 서버쪽에서 담당한다는 것은, 그 만큼 렌더링을 위한 서버 자원이 사용되는 것이고, 불필요한 트래픽도 낭비됨을 의미한다.
그래서 React같은 라이브러리 혹은 프레임워크를 사용해서 뷰 렌더링을 유저의 브라우저가 담당하도록 하고, 어플을 브라우저에 로드한 다음에 정말 필요한 데이터만 전달받아서 보여준다.
싱글 페이지라고 해서, 한 종류의 화면만 있는 것도 아니다. 블로그 같은 경우에는 홈, 포스트, 목록, 글쓰기 등의 화면이 있을 것이다. 그리고 그 화면에 대한 주소도 있어야 한다. 주소가 있어야 유저들이 북마크도 할 수 있고 서비스를 사용자들에게 광고할 수 있다.
여기서, 다른 주소에 따라 다른 뷰를 보여주는 것을 라우팅이라고 한다!
리액트 자체에는 이 기능이 내장되어 있지 않기 때문에, 직접 브라우저의 API를 사용하고 상태를 설정해서 다른 뷰를 보여주어야 한다.
그럼 단점은?
앱의 규모가 커지면, js파일 사이즈가 너무 커진다는 것에 있다. 유저가 실제로 방문하지 않을 수도 있는 페이지의 렌더링 스크립트도 불러오기 때문이다. (그래서 code splitting을 사용한다.)
코드 스플리팅이란?
https://github.com/zereight/all-of-frontend-interview/blob/master/기술/files/코드%20스플리팅이란%3F.md
Currying vs Closure
'개발 > Web Programming' 카테고리의 다른 글
quiz.typeofnan.dev 문제 정리 - 4 (0) | 2021.06.18 |
---|---|
[리팩터링] 캡슐화 - 레코드 캡슐화 하기 (0) | 2021.06.14 |
내가 보려고 만든 "useEffect 완벽 가이드" 요약 (1) | 2021.06.13 |
우테코 react-payment 미션 학습로그 작성 (1) | 2021.06.13 |
styled-component를 작성할때 참고하면 좋은 곳 (0) | 2021.06.12 |