# mobx
mobx todolist - chagGPT
MobX를 사용하여 간단한 to-do 리스트를 만들어 보겠습니다. MobX는 상태 관리 라이브러리로, React 애플리케이션의 상태를 관리하는 데 도움을 줍니다. 먼저, MobX와 관련 라이브러리를 설치합니다. MobX 스토어를 설정합니다. MobX 스토어는 애플리케이션의 상태를 저장하고 관리하는 곳입니다. React 컴포넌트를 작성합니다. MobX 스토어를 사용하여 to-do 리스트를 표시하고 상태를 변경하는 React 컴포넌트를 작성합니다. 애플리케이션의 진입점을 설정합니다. MobX 스토어를 React 애플리케이션에 연결하고 TodoList 컴포넌트를 렌더링합니다. 이제 간단한 MobX를 사용한 to-do 리스트 애플리케이션이 준비되었습니다. 필요한 경우 스타일링과 추가 기능을 구현하여 확장할 수 있습니다.
[MobX] MobX (version 6)
🔔 참고 > 이 포스트는 다음 글을 참고하여 작성하였음을 알립니다. MobX 공식 문서 0. 서론 React 또는 React Native에서 SPA 상태 관리 라이브러리로는 Redux가 전부이다. 현 회사의 App 프로젝트가 MobX로 되어 있기 때문에 이 참에 배워서 익힐 겸 포스트도 함께 작성한다. 1. MobX 위에서 언급했듯이 상태 관리 라이브러리 중 하나이다. RTK 가 나오기 이전의 Redux 는 러닝 커브가 높아 사용하기에 부담스러웠다. Action, Reducer, Dispatch, Store 등 숙지해야 할 개념도 많고 막상 사용하기도 쉽지 않았다. 이를 전부 간소화하고 가독성과 직관성을 높여 등장한 상태 관리 라이브러리가 바로 MobX 이다. MobX 는 어플리케이션에서 다
상태관리 레인저! 프론트엔드 상태관리 라이브러리들을 살펴보자 #2 (Redux)
지난시간에는 간단히 상태관리의 개념과 배경 그리고 몇몇 라이브러리들의 이름을 소개했다. 이번 시간에는 상태관리 라이브러리의 터줏대감들인 Redux 와 MobX를 살펴보는 시간을 가져보도록 하자. 들어가며... 이전 시간에 소개한대로 Flux 패턴이란 개념이 등장하고 나서 이러한 방식의 프로그래밍 설계 패턴을 도입하여 프론트엔드의 상태를 보다 관리하기 쉽도록 도와줄 수 있는 라이브러리들이 등장하기 시작했다. 현재의 상태관리 라이브러리들의 수가 꽤나 많게 느껴질지 모르겠지만, Redux (2015) 는 대부분의 라이브러리들보다 앞서 등장해 선두를 차지했다. 꽤나 오래전에 등장한 것처럼 느껴질지도 모르겠지만, Redux는 현재 까지도 계속 잘 관리되어지고 있으며 또 많은 사람들이 계속 사용하
상태관리 레인저! 프론트엔드 상태관리 라이브러리들을 살펴보자 #1 (상태관리의 시작)
React state를 전역 상태로 관리하고 싶다고? React 상태관리 레인저! 우리에게 맞겨라! 들어가며... React 를 사용하는 개발자라면 누구나 마주하게 되는 순간이 하나 있다. 그건 바로 props drilling. 내가 사용해야하는 state 가 쓸데 없이 번거로운 과정을 거쳐 필요 없는 코드량 만을 증가시키는 props drilling을 거쳐야만이 원하는 곳에서 사용할 수 있을 때, 혹시 이런 생각을 하지 않았는가? >"이거 꼭 이런 방식으로 사용해야하는 건가? 왜 한 곳에서 상태를 관리하고 그곳에서 불러다가 쓸 수는 없는거지?" 좋다. 그렇다면 우리는 이제 상태관리 레인저들에게 도움을 청해야 할 때가 된 것이다. >_"상태관리 레인저! 도와줘요! 내 state
Mobx 번역 후기
번역을 시작하게 된 계기 전 회사인 디어코퍼레이션을 다닐 때 회사에서 Mobx를 사용하고 있었는데, 렌더링 최적화를 하기 위해 주말에 따로 시간을 내어서 문서를 다 읽었었다. 그 과정에서 내가 모르던 부분에 대해 알게 되었고, 그 부분을 적용하니 앱 성능이 드라마틱하게 좋아져서 이를 여러 사람에게 공유하고 싶은 마음이 생겼고 Mobx에 대한 이해도를 높이고 싶었다. 그리고 무엇보다 내 성향이 모르는 부분에 대해 새롭게 아는 것을 즐기는 성향이라 번역하면서 많은 것들을 배울 수 있다는 생각이 들어 번역하기로 결심했다. 디어 앱 최적화 비교 Before After 
React 필수 지식 #2
SOLID 원칙 단일 책임 원칙 (Single Responsibility Principle) -- 함수나 클래스는 한 가지 기능만을 수행해야함 개방 폐쇄 원칙 (Open Close Principle) -- 확장에는 열려있고 변경에는 닫혀있어야함 -- 쉽게 말하면 기능은 변경될 수 있고 (트럭의 짐 유형), 기능의 작동을 작성한 코드 자체를 변경하지 않아야 함 (트럭 자체) 리스코브 치환 원칙 (Liskov Subsititution Principle) -- 파생 클래스는 기본 클래스로 대체 가능해야함 -- 자바스크립트 객체 지향 프로그래밍 측면의 큰 특징이기 때문에 상속을 사용해서 확장한다면 자동으로 적용됨 인터페이스 분리 원칙 (Interface Segregation Principle) -- 자신이 사용하지 않는 인터페이스는 구현하지 말아야함 의존성 역전 원칙 (Denpendency Inversion Principle) -- 고수준 모듈은 저수준 모듈
[React] 컴포넌트 구현하기 - 단일/다중 객체 Select 기능
🎣 단일/다중 객체 Select 기능 컴포넌트의 예시 위의 예시 코드에서는 ObjectComponent라는 각 객체를 표시하는 컴포넌트를 정의하고, ObjectList 컴포넌트에서 ObjectComponent를 사용하여 여러 개의 객체를 렌더링합니다. ObjectComponent 컴포넌트에서는 isSelected 변수를 사용하여 선택된 객체인지 확인합니다. 클릭 이벤트 핸들러인 handleClick 함수에서는 선택된 객체를 업데이트하고, updateSelectedObjects 함수를 호출하여 selectedObjects 상태를 업데이트합니다. 선택된 객체의 상태에 따라 CSS 클래스를 추가하여 선택된 객체를 시각적으로 나타냅니다. ObjectList 컴포넌트에서는 selectedObjects 상태와 updateSelectedObjects 함수를 선언하여 ObjectComponent에 전달합니다. 객체 리스트를 순회하며
[MobX] 🔦 observable과 observer의 활용
MobX에서 observable로 둘러 쌓인 객체는 상태만 있는게 낫지 않을까? observable로 둘러쌓인 객체에 함수가 있으면 코드 가독성이 떨어지는 거 아닌가? => observable 객체는 변화 상태를 감지하는 것뿐만 아니라 observable 객체에 종속되어 있는 함수를 자동으로 실행하는 역할도 한다! 🔗 observable 객체에 종속된 함수 observable로 둘러싸인 객체에 함수가 포함되는 것은 MobX에서 자주 사용되는 패턴 중 하나입니다. 이 패턴은 MobX의 핵심 기능 중 하나인 자동 반응(automatic reaction)을 통해 상태 변화를 감지하고 관련된 코드를 자동으로 실행할 수 있게 해줍니다. 함수가 observable 객체에 포함되는 것은 코드의 유연성과 효율성을 높일 수 있습니다. 몇 가지 이유로는 다음과 같습니다: 1. 상태와 관련된 로직을 객체 내부에 캡슐화: 함수를 observable 객
20230522 - RN, jest, mobX
이제 더 이상 문제는 없겠거니 했으나, 생각보다 mocking 해야 할 목록이 많았다. 우선 react-native-sound > https://github.com/zmxv/react-native-sound/issues/245#issuecomment-574658388 이런식으로 SoundMock class를 만들어서 mocking 해줘야한다. 그래도 계속
20230519 - RN, jest, mobX
현재 맡고있는 프로젝트의 코드 상태가 너무 엉망이어서 log를 찍어가며 작업하는 것은 무리였다. 고민을 하다가 이참에 RN 프로젝트에서 jest 테스트를 굴려볼까 생각하여 과감하게 진행 냅다 지피티한테 물어보고 생각보다 잘 뽑아줘서 놀람 현재 작업하는 RN 프로젝트의 버전이 0.68.1로 꽤 낮은 상태라 추가적인 환경설정이 필요해보였다. 
MobX에서 비동기를 해보자
안녕하세요 오늘은 MobX에서 비동기 처리하는 방법에 대해 알아보도록 할게요. 그럼 시작해볼까요? Q. MobX는 action 함수 내부에서 promise 작업을 한 이후 다시 action 함수를 호출해야 정상적으로 observable 값을 바꿀 수 있으나 runInAction을 사용하면, 함수 내부에서 observable값을 바꿀 수 있습니다. 라는데, 너무 말이 장황합니다. 이 문장을 한 번 다시 알아볼까요? MobX는 자바스크립트 상태 관리 라이브러리에요. 애플리케이션 상태를 간편하게 관리할 수 있게 도와주는 것이에요. 'runInAction'은 MobX에서 제공하는 유틸리티 함수로, action 내부에서 비동기 작업을 수행한 후에도 observable값을 바꿀 수 있게 해줘요. 먼저 async/await 에서 'runInAction'을 사용하지 않는 기본적인 MobX 사용 예제를 살펴봐볼까요? 위 코드에서 'increase' a
[React]MobX 적용
01 개요 리액트 2023년 현재 사용되고 있는 상태 관리 라이브러리(state management library) MobX를 사용해서 어플리케이션의 상태관리를 하기 위한 전반적인 내용을 다룬다. 최종수정일 : 2023.04.27 02 환경설정 >npm install mobx --save >npm install mobx-react-lite --save 03 주요 개념 03.01 개념 State : 객체, 배열, 원시 값, 참조 등 데이터 Action : state를 변경하는 모든 동작 Derivation : state로부터 추론될 수 있는 모든 데이터 Reaction : state의 변경에 수반되는 동작 03.02 사용 observable : 특정 객체를 MobX가 값을 추적하고 변경할 수 있는 객체로 만든다. computed : 특정 데이터 객체를 MobX가 연동된 값에 의해 계산해
Learn 상태 관리 라이브러리
상태 관리 라이브러리 ContextAPI, Redux, MobX, SWR는 상태 관리 라이브러리 혹은 패턴으로 React 프레임워크에서 사용되는 대표적인 상태 관리 방법이다.(State) Context API Context API는 React에서 기본적으로 제공하는 상태 관리 방법 중 하나이다. Context API를 사용하면 상위 컴포넌트에서 하위 컴포넌트로 데이터를 전달할 수 있다. 이를 통해 props를 이용한 데이터 전달이 필요 없어지므로, 중간 단계의 컴포넌트에서 별도의 코드 없이 데이터를 전달할 수 있다는 장점이 있다. 아래는 간단한 예시 코드 Redux Redux는 React에서 가장 많이 사용되는 상태 관리 라이브러리 중 하나이다. Redux는 전역 상태를 관리하는데에 사용되며, 상태를 변경하는 방법
MobX내 setter함수를 구조분해할당하여 사용하는 경우
프로젝트 마이그레이션을 진행하는 중 Mobx관련 setter함수를 사용할 때 있었던 문제를 정리해보려고 한다. 구현하고자 했던 기능은 스페이스 설정에서 유저가 해당 스페이스의 설정중 저전력모드라는 기능을 토글로 on/off할 수 있는 기능을 구현 중이였다. 구현 방향 해당 기능은 유저 즉, 플레이어마다 스페이스별로 개별의 설정을 갖고 있어야했다. 그래서 플레이어의 설정관련된 전역상태를 저장하고 있는 settingStore내에 playerSettings라는 속성을 만들고 거기엔 스페이스(hashId)별 playerSettings객체를 갖도록하고 해당 정보는 유저의 로컬스토리지에 저장하도록 구현하였다. 기존프로젝트(v1)에서는 추후 저전력모드 뿐만 아니라 플레이어별 설정들이 늘어날 것으로 예상하여 해당 서버 api를 통해 저장하도록 기능을 구현했었지만 서버개발자와의 소통을 통해 아직 추가될 개별설정은 없고 해당 특정 설정만을 위해서 매번 토글이 on/off될
React의 상태관리 방법
React의 상태관리방법 리액트의 상태관리방법은 크게 2가지로 나뉩니다. 부모 혹은 자신이 직접 컴포넌트 안에서 관리하는 로컬 상태 방법과 로컬 상태의 불편함을 개선한 전역 상태 관리 방법이 있습니다. 로컬 상태 (Local State) 특정 컴포넌트 내에서만 데이터를 관리하는 것으로, 함수형 컴포넌트에서는 리액트 hook 과 props 를 사용하여 상태관리를 하는 방법이다. 하위 컴포넌트에 데이터를 전달하기 위해, props를 사용하는 데 어플리케이션의 크기가 점점 커질 수록 props drilling이 증가하여, 반복작업이 많아지고 유지 보수가 어려워지는 단점이 있다. 전역 상태 (Global State) 전역 상태는 프로젝트 전체의 상태관리를 총괄하는 방법으로, 대표적으로 Redux, Context API 등이 존재한다. 전역에서 관리하기 때문에, 어떤 컴포넌트에서든 상태 값을 반영하고, 변경시키는 것이 가능하다. props 과정이 생략되어, 작업이 적
[TIL] - react mobx
mobX = 상태관리 라이브러리 = redux 보다 사용 간편 = 상태관리 라이브러리 사용 이유 -> component로만 개발시 비즈니스 로직이 component에 집중되어 스파게티 코드가 됌. 상태 관리 라이브러리 사용시 component는 controller 역할, 나머지 로직 분리 가능. mobX Observable(observer) = Rerendering 대상이 되는 state(관찰대상) = 값 변경시마다 Rerendering = store와 함께 쓰임 mobx store = observable state = singleton = Domain Stores, Ui Stores [ Domain Stores Example ] > Examples mobX store 전체 참고 > [mobx doc - optimization](https://mobx.
[Flutter] 상태 관리 9편(State Management) - Mobx
상태 관리 9편(State Management) - Mobx 상태 관리(State Management) 1편 - State Ful 상태 관리(State Management) 2편 - Value Listenerable 상태 관리(State Management) 3편 - Get X [Simple] 상태 관리(State Management) 4편 - Get X [Reactive] [상태 관리(State M
[Flutter] 상태 관리 8편(State Management) - Riverpod
상태 관리 8편(State Management) - Riverpod 상태 관리(State Management) 1편 - State Ful 상태 관리(State Management) 2편 - Value Listenerable 상태 관리(State Management) 3편 - Get X [Simple] 상태 관리(State Management) 4편 - Get X [Reactive] [상태 관리(Sta
[Flutter] 상태 관리 7편(State Management) - Cubit
상태 관리 7편(State Management) - Cubit 상태 관리(State Management) 1편 - State Ful 상태 관리(State Management) 2편 - Value Listenerable 상태 관리(State Management) 3편 - Get X [Simple] 상태 관리(State Management) 4편 - Get X [Reactive] [상태 관리(State