@mweststrate
JS / TS fanatic. Creator of MobX
Nothing here yet.
Nothing here yet.
No blogs yet.
Check Comparisons with other state management libraries section on the mobx-awesome list for some interesting comparisons and background in the fundamental differences, or this post on hashnode itself: https://hashnode.com/post/redux-vs-mobx-by-example-part-i-intro-and-exploring-redux-cito5m0nn0sssxi53c7zq7jpr
UPDATED ANSWER Tough question to answer. The rough equivalent of MobX without MobX would be to have an event emitter for each object property, array entry etc. that lives in your state. Then there would be a function (computed) that you would need to subscribe to the correct event emitters to fire them whenever a value changes. After which you would need to notify your own observers. This mechanism is in general terms covered in this blog post: https://monterail.com/blog/2016/how-to-build-a-reactive-engine-in-javascript-part-1-observable-objects Then you just have the raw inefficient basics covered; you would need to make sure after that that no events are fired if the values don't actually change even if they are recomputed, and that if a computed value depends on another computed value, the event emitters, which are completely unaware of each other, are triggered in the right order :) How that is done is explained in this MobX specific Magic MobX talk and blog In depth explanation of Mobx After that, create a nice api around all that, so that the event emitters are hidden inside property getters / setters. If you want to have a rough general idea what MobX does for you, check: Manage Javascript Application State with MobX or this talk Practical MobX , both by Matt Ruby. If you want a framework which you can mimic in 100LoC, go #Redux :) ORIGINAL ANSWER Here is an example of MobX + yoyo: http://embed.plnkr.co/xZEiC9vzS0ann8CXQpc8 (see main.ts) (Ok, actually it is typescript, but nothing typescript specific in there). Otherwise, please specify the question in more detail, what would you like to see? It is quite open-ended now :)
I noticed that in your question you is highlighted three times. The point of a good OSS project is I think that is not about you, how awesome your library is, or how it is better / faster / cleaner / smarter / nicer than what everybody else is doing. Most people don't care about that. It is about your (potential) users. Does it make their jobs easier? If that is not the case, you have hard sell. If it is the case, finding some early adopters that use it in their (pet) projects and are really enthusiastic about it. Their enthusiasm is more worth than blogs, readme's or demo's. Directly approach people in the field to give your lib a try regularly works for this. Selling to the first users is mainly a thing of getting your idea across. I see too many libraries that dump code examples in their readme, but don't make it clear to my why I would want to take that approach, or how they treat the problem domain different then before. So my 2 cents: Make sure you solve a real problem Make sure your idea behind the solution, your vision is clearly written down. Find some enthusiastic early adopters That is what worked for MobX at least so far :)
Not sure if you are interested in just a solution within the Redux space, but since the question has a MobX label as well, here is what your object would look like in MobX, with properties that would get automatically recomputed if your React components are marked with observer : With plain objects: var doc = observable({ id: 1111 , revision: 5 , title: 'Lorem Ipsum' , items: [{...}, {...}] get reference ( ) { return this .id + '-' + this .revision; } get totalQuantity ( ) { return thisitems.reduce(function(total, item) { return total + item.quantity; }, 0 ); } }) You can also use classes & decorators, or utility functions that leverage extendObservable to mix the computed properties afterwards into the objects. Selectors are not needed as MobX will track for you which data needs to be selected and reacted to.
In excel there are two basic concepts: data cells and formulas. Whenever you update a data cell you don't worry about which formulas (or charts) should be recomputed, and which ones shouldn't. Because Excel knows which formulas depends on which data cells. This concept is called transparent tracking. MobX takes this concept to the javascript and applies it to primitives, objects, arrays and maps. So for example: const myOrder = observable({ product: "laptop" , price: 17 , quantity: 3 , get total ( ) { return this .price * this .quantity } }) Now if you change the price or quantity (data cells) of the order, MobX will make sure total (formula) is updated, and everything that uses that total value. However, if you change the product field, it won't attempt to recompute the total, it has tracked that that value is not relevant for the formula. I hope that helps!
React Native is supported out of the box. Just make sure to import everything from "mobx-react/native" . Remember to slice() / toJS() before passing them to built-in components and you should be good to go. If you want to use decorators, remember to enable them in .bablerc (I saw there is also a preset for that in RN: "presets": ["stage-2", "react-native-stage-0/decorator-support"] )
I've heard from people migrating from Redux to MobX in production apps. You can use them side by side and migrating first a few components with their local state, and then feature by feature should go well. To get an idea: you can connect to a Redux store and then receive the new props and put them in some observables by a smart component which you pass down the component tree. The other way around you should be able to dispatch Redux actions from observer components.
I think the trick is to move from "must know all" to "what is the problem at hand". What is your current pain? That is where your research and read efforts should go I think, for the rest it should suffice to do some headline scanning. For example: I originally started out with browserify because I found it simpler to setup then webpack. After a while I run into some limits of browserify and researched whether webpack could address those (only started really reading about it at that point, before it I just knew the name). Now there is quite some buzz about rollup. It might be better, feature wise or conceptually. Yet I don't invest time in it at this point because I don't have any urgent pains with webpack and I'm comfortable with it. If I would start on a green field, long term project, I would probably invest time in reading about rollup because it might be a better investment in the long term. TL;DR: pick your battles, focus on your current pains. Nobody expects you to know everything. (... and if you are desperate to learn new things, try MobX ;-))