4 ms·

This definitely clarifies things. Thank you for your trouble. With Mobx I'm not handling a regular object, but a wrapped object (I think). This wrapper provised

This definitely clarifies things. Thank you for your trouble. With Mobx I'm not handling a regular object, but a wrapped object (I think). This wrapper provised the observation capability for getters and updates to observers when using setters. So, the usage patterns look to be the same than with regular, unwrapped object, but the Mobx makes sure that when accessed it always gives the latest value and when updated, the update is messaged to its observers. It feels a rather clever use of JS getters and setters. I have an project coming up that's going to integrate several previously separate apps into one. I can't imagine how I would combine their state into one with Redux. With observables I could just get the app observe their state changes and affect changes in others without contained apps being aware of each other.

mweststrate 11y ago
Exactly. Integrating many apps is something we do as well. We have a large application that handles roughly 500 different domain classes (just scan through https://apidocs.mendix.com/modelsdk/latest/ https://apidocs.mendix.com/modelsdk/latest/ to see how vast that is). This approach enables our partners to write plugins that are not only simple to write, because they can just work with 'plain' javascript classes and arrays (and don't need to learn the whole, for example, redux architecture), but which are also really easy to integrate in our visual tools. Our UI stays always efficiently in sync with whatever mutations plugins make. In an architecture with explicit subscriptions, events or selectors this would be a lot harder to achieve.