일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | ||
6 | 7 | 8 | 9 | 10 | 11 | 12 |
13 | 14 | 15 | 16 | 17 | 18 | 19 |
20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 28 | 29 | 30 |
Tags
- 고루틴 채널
- go 마스코트
- clean architecture middleware
- gin middleware
- go 맥
- go recover
- go 캐릭터
- go 환경변수
- go 패닉
- golang gopher
- go air 환경변수
- go디자인패턴
- gopath 환경변수
- 골랑 고퍼
- go air
- go panic
- air 환경변수
- gin recovery
- go 대기그룹
- git
- go 맥 air
- go middleware
- go clean architecture
- 좀비고루틴
- 신입개발자
- go
- go channel
- go 맥 air 환경변수
- gin logger
- 개발자
Archives
- Today
- Total
뽀미의 개발노트
MobX란? 본문
- 상태 관리 라이브러리. 상태 관리 라이브러리로는 Redux도 있지만 우리는 MobX를 사용한다. MobX는 Redux와 달리 코드를 깔끔하게 쓸수 있고 oop기반으로 되어있다.
- 한 컴포넌트에서 state(변수)를 만들고, 다른 컴포넌트에서 저 변수를 갖다가 쓰려면 props 문법을 써야함. 두 컴포넌트가 중간 단계가 여러개면은 그 갯수만큼 props를 써줘야함! 그럼 컴포넌트가 100개쯤 중첩되어 있으면 state를 전해주기 위해서 props를 엄청 많이 써야하는것!! 그럴때 MobX같은 상태 관리 라이브러리를 설치해서 편하게 쓸수 있음.
- MobX를 깔면 state를 저장하는 store를 따로 만들 수 있음. 그래서 state(변수)를 거기 저장하면 모든 컴포넌트들이 store에서 그 state를 직접 가져와서 쓸 수 있음!! 그래서 코드가 훨씬 간단해짐
- 근데 여러 컴포넌트들에서 그 state를 수정하다가 버그가 생기면 버그를 일으킨 컴포넌트가 무엇인지 범인을 추적해야함 -> 컴포넌트 갯수도 많은데 힘듬.. 그래서 쓰는 방법 : store에 state를 수정하는 방법을 여러개 적어놓음. 그럼 컴포넌트들은 그 수정방법을 보고 store에 이거 해주세요 저거 해주세요 요청만 할 수 있음!! 직접 state를 수정하는게 아니라! 암튼 그러면 버그가 났을때 store에 있는 그 방법에서 버그가 난 거라서 잡기 쉬워짐.
- MVVM 모델에서 컴포넌트가 View, store가 ViewModel이라고 보면 됨.
'회사 업무 정리' 카테고리의 다른 글
Chromium과 V8엔진 (0) | 2023.10.20 |
---|---|
Typescript란? (0) | 2023.10.20 |
DOM과 Virtual DOM (0) | 2023.10.20 |
Javascript heap out of memory 문제 해결..? (급한 불 끄기) (0) | 2023.10.18 |
리눅스 node.js 설치 (0) | 2023.10.18 |