What is Redux?<\/h2>\n\n\n\n
As stated at redux.js.org<\/a>, it\u2019s \u201ca predictable state of container for JS<\/a> Apps<\/strong>.\u201d It was created by Dan Abramov and Andrew Clark in 2015. No surprise here, MobX <\/strong> is also a library for state management, it transparently applies functional reactive programming (TFRP) to make it simple and scalable. Similarly to the preceding library, its philosophy is described in 3 points: React<\/a><\/strong> is known for the serious boilerplate around the initial setup. You cannot neglect it. Especially when you have a bigger application with a lot of reducers and actions, you have probably already decided to keep the action types as constants in the strings, which is a good approach, but then there is even more code! Fortunately, the Redux Toolkit<\/a> is getting more popularity and it is now recommended to write Redux<\/strong> logic. If you ask me, I like it! Still, there is a lot to learn, but the simple basic setup with the Toolkit does the job.<\/p>\n\n\n\n When I looked at the MobX documentation<\/strong>, I was like a kid who accidentally landed in a chocolate factory. I was going through the examples and I kept asking how that could work, but it does and apparently does it well. But maybe handling all of the reducers, actions, middlewares, and other stuff makes it so easy to get fascinated by something else. Nevertheless, if you are familiar with OOP<\/a>, MobX<\/strong> will come naturally to you. There is much less initial coding and many things happen behind the scenes, so you do not need to care about them in most cases.<\/p>\n\n\n\n In Redux<\/strong>, we have to use primitives, arrays, or plain JS<\/strong> objects as data<\/a> for our state. In MobX<\/strong>, we make properties, entire objects, arrays, Map and Sets There is no need for normalization of data, as MobX<\/strong> We have a single source of truth in Redux<\/strong>. By keeping the state in one location, we make sure the data is not duplicated all over the app and it becomes easier to debug.<\/p>\n\n\n\n MobX<\/strong> actually encourages having at least two separate stores, one for the UI state and one or more for the domain state. That separation allows us<\/a> to reuse the domain in different applications.<\/p>\n\n\n\n Because we are not limited to JS<\/strong> plain objects, it seems natural to create its own classes for particular domain objects, as the authors suggest. Here, Mobx<\/strong> shines for those of you who like object-oriented programming. You can have methods, control over what should be observable or not. In addition, we can combine multiple stores and share the references.<\/p>\n\n\n\n Redux<\/strong> requires that the update of state does not mutate<\/em> the original state. So, if we want to add a new item to an existing array, we need to return a new instance instead of just adding that item to the current one.<\/p>\n\n\n\n Then, in MobX<\/strong>, we can mutate the observable properties, here: the What\u2019s more, we can even directly update the Personally, I really like the Chrome Redux DevTools extension<\/a>. It allows you to have a quick look at your app\u2019s state and has nice capabilities to go back and forth for every change to the state (time travel!). All that is possible because of the principle that you do not mutate the previous state.<\/p>\n\n\n\n The additional layer of abstraction to the store makes the process of debugging more difficult. The MobX Chrome extension<\/a> seems so cumbersome to me, especially if compared to the previous experience, but maybe I need some time to get used to it.<\/p>\n\n\n\n But we have, e.g., the When you look at the popularity, Redux prevails here. Near 4M downloads<\/a> from npm per week compared to 450k for MobX<\/a>. Also, the number of contributors (~870 > 270) and stars (57k > 24k) on GitHub\u2019s repository for each library shows that Redux is a well-known brand.<\/p>\n\n\n\n On the other hand, State of JS 2020 report<\/a> shows the satisfaction from using them at almost the same level, so it definitely won\u2019t help you decide which one to pick for your next project<\/a>.<\/p>\n\n\n\n The satisfaction in this chart was described as \u201cwould use again \/ (would use again + would not use again)\u201d<\/p>\n\n\n\n
It can be described by 3 principles<\/a>:<\/p>\n\n\n\n\n
What is MobX?<\/h2>\n\n\n\n
1. Straightforward – minimalistic, boiler-free code and no special tools required to operate it,
2. Effortless optimal rendering – it makes sure all computations are optimized well and there is no need to manually do so,
3. Architectural freedom – implementation is unopinionated and can be used without any UI framework.<\/p>\n\n\n\nMobX and Redux Comparison<\/h2>\n\n\n\n
Learning<\/h3>\n\n\n\n
Data structure – what is inside the state?<\/h3>\n\n\n\n
Also, there is a common practice when you store data in arrays, namely to normalize it for performance reasons. Unfortunately, even with the helper functions in Redux’s Toolkit (e.g., createEntityAdapter<\/code>) that still adds additional code.<\/p>\n\n\n\nobservable.<\/code> Yes, primitives are not mentioned here because their values in JS<\/strong> are immutable and because of that they need to be treated differently. All you need to know if you go with an observable<\/code> is that it will wrap the primitive in \u201ca box\u201d and the actual value getter and setter will be available via .get()<\/code> and .set(newValue)<\/code> respectively see observable.box(value)<\/a><\/p>\n\n\n\nimport { observable, autorun } from \"mobx\"\n\nconst cityName = observable.box(\"Vienna\") \/\/ same as observable(\"Vienna\")\n\nautorun(() => {\n console.log(cityName.get())\n})\n\/\/ Prints: 'Vienna'\n\ncityName.set(\"Amsterdam\")\n\/\/ Prints: 'Amsterdam'<\/code><\/pre>\n\n\n\n observable<\/code>` clones the object, makes it observable and, therefore, makes sure that all changes are reflected in the store once we update any of the observable properties.<\/p>\n\n\n\nLocation of data – store(s)<\/h3>\n\n\n\n
Immutable & Mutable<\/h3>\n\n\n\n
function todoReducer(state = [], action) {\n \/\/ here we create a new array and use a spread operator to keep the old values\n return [\n ...state,\n action.payload\n ]\n}<\/code><\/pre>\n\n\n\ntodos<\/code> array. Notice we mutate the original array in addTodo<\/code><\/p>\n\n\n\nclass ObservableTodoStore {\n todos = [];\n\n constructor() {\n makeObservable(this, {\n todos: observable,\n addTodo: action,\n });\n autorun(() => console.log(this.todos.length))\n }\n\n\n addTodo(task) {\n \/\/here we are just pushing the new item to the existing array!\n this.todos.push({\n task: task,\n completed: false,\n });\n }\n\n}\n\nconst observableTodoStore = new ObservableTodoStore();\nobservableTodoStore.addTodo(\"Some tough thing to do\");<\/code><\/pre>\n\n\n\ntodo<\/code> list and we will see that autorun<\/code> will be fired (it will notice a change in the observable array of todos<\/code>).<\/p>\n\n\n\nobservableTodoStore.todos.push(\"Some other tough task\");\n\n\/\/ What is more interesting, only when you update the particular to-do property\n\/\/ will MobX warn you (while in strict mode) that you shouldn\u2019t do that directly\nobservableTodoStore.todos[1].task = (\"Maybe something more effortless\");<\/code><\/pre>\n\n\n\nDebugging<\/h3>\n\n\n\n
autorun<\/code> track function that you probably will use a lot when starting to use the MobX<\/strong> and wanting to check when the state changes. You need to note that the function will only track the changes it observes. That is determined once the function runs for the first time. MobX<\/strong> will subscribe to all observables that were read during that first invocation and then it will be triggered every time they change.<\/p>\n\n\n\nPopularity<\/h3>\n\n\n\n
![\"State](\"\/app\/uploads\/2024\/05\/CgfmJjf.png\")
<\/figure>\n\n\n\nConclusion<\/h2>\n\n\n\n
![\"\"](\"https:\/\/thecodest.co\/app\/uploads\/2024\/05\/interested_in_cooperation_.png\")
<\/a><\/figure>\n","protected":false},"excerpt":{"rendered":"