저번 글에 이은 mobX 3탄입니다. 저번엔 MobX 의 API에 대한 이야기는 제쳐두고, 갑자기 React MobX의 설계론에 대한 이야기를 해버렸습니다. 이번 편에는 개인적으로 MobX의 조금 알기 힘들고 조심해야겠다고 느낀 기본적인 부분에 대해서 적어보겠습니다.【DevTools】이미 MobX의 코드를 만들어본 분중에, DevTools를 도입하지 않은 분이 있다면 꼭 도입해봐주십시오. 이 페이지에 를 마운트해서 도입하는 방법이 소개되어있습니다 .ChromeExtension를 도입해두면, 마운트없이 같은 기능을 이용가능하게 됩니다. 본편의 내용을 이해하는데 도움이 될것으로 보입니다.observable형에 대해서observable값에는, JS프리모티브, 참조, 플레인오브젝트, 클래스 인스턴스, 배열, 맵..
저번 글에 이은 2탄입니다. MobX에는 Redux와는 다르게, 복수의 Store가 존재하며, 복수의 Provider를 보유할 수 있습니다. Redux에도 Provider가 있지만, 그것은 컴포넌트의 루트에 한개만 존재하고, 초기 설정만 끝마치면 평소에는 의식할 일이 없는 존재입니다. MobX에서, Store를 어디에서 생성하고 어떻게 Provider를 전달하는게 좋은 설계일까요. 이 관점에 대해 깊이 고찰한 글을 찾을 수 없었기 때문에, 독자방침이지만 끄적여보도록 하겠습니다 (친절한 태클을 기다려봅니다. )Redux 답습 패턴Redux 구현 경험자도, 또 경험이 없는 분도 이 방법이 가장 이해하기 쉽다고 생각합니다. 'Provider를 한개만 갖도록 한다' 입니다. 이렇게 하면 모든 컴포넌트가 전체의 ..
- Total
- Today
- Yesterday
- Qiita
- 쿠로키 하루
- mobx
- 편육
- 브이로그
- 덴뿌라
- 리액트 네이티브
- 청계천 맛집
- 일본여행
- 필동면옥
- android
- 평양냉면
- 맛집
- observable
- 평양면옥
- 을지면옥
- 야키니쿠
- 수요미식회
- react native
- 여행
- 일드
- 리액트
- 우래옥
- Redux
- 리액트네이티브
- 중쇄를찍자
- 안드로이드
- 을지로3가
- 도쿄맛집
- 도쿄
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 | 31 |