mobxjs/mobx

Keeps views automatically in sync with state. Unobtrusively. https://egghead.io/courses/manage-complex-state-in-react-apps-with-mobx

Daniel K.

@FredyC

@mkamranhamid careful about array length, in the moment you would remove & add to the array within a single action, it wouldn't react to that change
observing array is not a problem with MobX, but you would need to either iterate over that array under the observer, or use toJS so the change can be seen

Gorgi Kosev

@spion

why not simply use the observer decorator

GuestInCorle

@GuestInCorle

Guys, who does know, why MobX is called MobX?

I'm embarrassed to ask the author of the library, maybe someone here knows?

Jan-Willem Spuij

@jspuij

mobxjs/mobx#115 The history is there ;-)

GuestInCorle

@GuestInCorle

Okay, but why Mobservable? What does the letter "M" mean?

Daniel K.

@FredyC

mostly observable ? :) I don't know, just wild guessing :)

Anzor Bashkhaz

@anzorb

Folks, doing a knowledge transfer to our teams about mobX, and stumbled upon an interesting question. I have two examples of using mobX, with data mutation of data in place (https://codesandbox.io/s/mobx-101-mutation-jw2h6) and without (using observable.ref, and spread operators) (https://codesandbox.io/s/mobx-101-no-mutation-1uiv9). The React profiler shows me no difference in terms of re-render as react keys appear to optimize for that for list items (I have screenshots) between the two. Is there an advantage to one versus the other? If there isn't advantage in production I feel not mutating is more "native" to folks also using ReduX or functional programming. (ie. not having to learn MobxArray.remove(), and instead doing a splice and spread, and using a filter to delete items, etc. Thanks in advance, love mobX.

Daniel K.

@FredyC

or mighty observable, that sounds better

Jan-Willem Spuij

@jspuij

Michel Made Observables ;-)

(no idea)

GuestInCorle

@GuestInCorle

Michel Made Observables ;-)

I like this! 😁

But the question is still open...

GuestInCorle

@GuestInCorle

@anzorb In-place mutations are faster by definition. You are comparing performance of many little mutations. Consider comparing performance of few significant mutations. Also try that with many and few subscriptions. You will see the difference.

@jspuij mobservable... mweststrate... I think your assumption is correct.

Jan-Willem Spuij

@jspuij

@GuestInCorle There really is only one way to find out. Ask the developer. It was developed at Mendix. Also with an M. It's for mobile development. Also an M.

GuestInCorle

@GuestInCorle

@jspuij MobX is a general-purpose library. I don't think that it can be denoted as "for mobile development".

Anzor Bashkhaz

@anzorb

@GuestInCorle besides mutation/copy performance, is there any difference in number of re-renders (maybe down the component tree)? Regarding mutation/copy performance, is it correct to assume that doing MobX with mutation is faster than ReduX? Any data to show the delta? For most real world situations (where ReduX appears fast enough), how much of an anti pattern is it to use MobX in the way I displayed in the second codesandbox?

GuestInCorle

@GuestInCorle

@mweststrate Can you clarify what does "M" state for in "Mobservable", the original name of the MobX library?

@anzorb Have you seen this example?

Michel Weststrate

@mweststrate

@GuestInCorle mob as in "a mob of observables". Yeah it was far fetched....

GuestInCorle

@GuestInCorle

@mweststrate Thank you very much!

Anzor Bashkhaz

@anzorb

@GuestInCorle thanks! Haven't seen that one

GuestInCorle

@GuestInCorle

@anzorb Think of MobX and Redux as an architectural solution, not an engine, that runs faster or slower. The core of MobX's 5 version is implemented good enough to assume that the basic operations such as subsciptions, mutations and caching perform optimally in the JavaScript environment with Proxy. Instead of comparing the performance of the parallel examples written in MobX and Redux, better compare its code quality and scalability. As Donald Knuth said: "Premature optimization is the root of all evil (or at least most of it) in programming", you should consider thinking more about project architecture instead of its performance in such an insignificant nuance. The "pros" of MobX are minimal boilerplate and subscriptions to state changes. These two let you write concise and at the same time performant code. It's believed that it's better to choose the libraries whose functionality more closely matches your business logic. Best wishes.

Daniel K.

@FredyC

@anzorb I have summarized some reasons for MobX here if you want: https://mobx-react.js.org/observe-why

Anzor Bashkhaz

@anzorb

thanks @GuestInCorle and @FredyC That's my line of thinking too, but by that same logic, for a project of low complexity (with lots of flat-ish) arrays and basic data structures - is starting off using refs and spread/copy modifications and optimizing to in place when/as needed an approach? Or is it an anti-pattern that should be avoided from the start?

Daniel K.

@FredyC

@anzorb I suppose the main rule of thumb is to keep code readable and understandable ... anything else is just a crutch :)

I used to do various complex looking code just because it seemed cool, but seeing how people struggle reading it after made me change my stance

Ivan V.

@ivandotv

Is anyone using mobx-remotedev for connecting to the redux extension debugger?
https://github.com/zalmoxisus/mobx-remotedev
I can't make it work.

kubk

@kubk

@ivandotv I use it everyday. Which error did you get? You can see my setup here: https://github.com/kubk/react-mobx-starter

Ivan V.

@ivandotv

@kubk I have tried it with mobx MST and nothing happens. Nothing gets registered to the tools, but my cpu is running hot.
Can you take a look at the https://github.com/mobxjs/mobx-state-tree/tree/master/packages/mst-example-todomvc (mst todo)
It has the older version of remotedev
I'm gonna clone your project and check it out a little bit later. :)

kubk

@kubk

Unfortunately, I haven't worked with MST so I don't know how to connect it to remotedev

Martin Bayly

@mdgbayly

Has anyone tried/managed to get MobX decorators working with the legacy decorators migration package

Things work fine if I use just the @observable decorator and configure babel to use the legacy decorator specification. However, we'd like to setup our build to use the new specification so we can use some components that use the new decorator specification (e.g. LitElement). However when I wrap the @observable decorator on a class instance property with the decoratorCompat call I get an error from babel.

class MyClass {
    // @observable
    @decoratorsCompat([observable])
   myField = '';
}

Uncaught TypeError: The property descriptor of a field descriptor can't have a .get property

This is my babel config for when I'm trying to use the new specification:

        'plugins': [
            // ['@babel/plugin-proposal-decorators', { 'legacy': true }],
            // ['@babel/plugin-proposal-class-properties', { 'loose': true }]
            ['@babel/plugin-proposal-decorators', { 'decoratorsBeforeExport': true }],
            ['@babel/plugin-proposal-class-properties']
        ]

I'm new to MobX and don't really grok decorators, but it seems like the MobX decorator implementation is adding getters/setters to the field descriptor, and the babel injected decorator code has checks which throw the above error if it detects a getter on the descriptor.

According to this babel blog post, the whole point of the migration utility is so that the new spec can be used with libraries like MobX
https://babeljs.io/blog/2018/09/17/decorators#upgrading

Michel Weststrate

@mweststrate

That proposal is even more dead than the original one atm. Sigh. But anyways, if combining the two decorator proposals is a problem, don't use decorators for MobX and use the decorate utility instead, (see the docs), that should do the trick I think @mdgbayly

Adam Gerthel

@AdamGerthel

I have an issue where computed values are racing against each other (and affecting each other, in turn causing new computations). Is there a way to tell a computed value that it should not recompute when a specific computed value has changed?

Adam Gerthel

@AdamGerthel

It’s hard to supply the whole picture but I’ll try to simplify:

I have two computed values and one observable, let’s call them “apple”, “seed” and “seed-id”. When “apple” changes, I have a reaction that calculates which “seed-id” is the current one.

“seed” uses the “seed-id” to get the current seed from a list seeds available in “apple”.

When “apple” re-runs (let’s say that “tree” or whatever it uses for computation has changed), this happens, in order:

“seed” re-runs, but can’t find the seed using the seed-id because the apple has changed
“seed-id” is set through the reaction
“seed” re-runs and finds the seed

My problem is that when “seed” is re-run and can’t find the seed, it breaks a lot of other stuff that is observing the seed.

I don’t want “seed” to re-run unless “seed-id” has changed, but I have no choice (afaik) not to use the “apple” variable in “seed” because I need to look for the proper seed using the “seed-id”, but using it causes it to re-run prematurely.

I am aware that I probably shouldn't be using a reaction for the seed-id calculation, but I tried switching it to a computed instead, but that didn't help (same race-condition occurs)

Daniel K.

@FredyC

@AdamGerthel probably best if you can setup reproduction with eg. CodeSandbox, this is hard to follow (for me) ... the simplest repro the better

Adam Gerthel

@AdamGerthel

@FredyC Naturally, when I try to reproduce it, I fail. But that's always a good starting point because it means I'm getting closer to solving it.

Anyway, here's the codesandbox: https://codesandbox.io/s/mobx-decorators-zum6k

I changed the structure from apple -> seeds to tree -> apples to make it easier to understand

One question regarding my sandbox above: Why is this.apple not being re-run as a result of the reaction that changes this.appleId?

Adam Gerthel

@AdamGerthel

Because in my real-life use case, it does (and should, I mean it uses the value to generate its output).

But according to trace(), it's invalidated because of the change in this.tree only.

Adam Gerthel

@AdamGerthel

I would've expected this.apple to momentarily return null when this.treeId changes (because the previous appleId is not found in the new tree), before the reaction that sets this.appleId has run.

that's what happens in my codebase (which is admittedly more complex in total, but the principle is the same).

Daniel K.

@FredyC

@AdamGerthel sorry I tried to look but that's over my deep knowledge, if someone does not respond here, create a question issue with that repro and these details

Adam Gerthel

@AdamGerthel

Solved it! I had two problems - one was a pure bug which caused some confusion, and the other problem was solved by producing the value in a computed instead of as a result of a reaction.

I'm still not quite sure how this.apple in my codebox example doesn't re-run due to the reaction

but that wasn't my issue so

Where communities thrive

People

Repo info

Activity