20 Matching Annotations
  1. Oct 2020
    1. MobX - for me personally MobX is a far better way to manage state than React Hooks. It doesn't care about the UI layer so it can be used outside the React ecosystem, and it's simple to mutate data.
    2. The only downside is that it tracks data access and not the data itself, which can be a source of bugs if you don't keep it in mind.
  2. Oct 2019
  3. Sep 2019
    1. MobX as a data flow library, that enables you to roll your own state management architecture with minimal effort
    2. MobX cannot guarantee your data is JSON serializable, or whether it can be traversed in finite time
    1. types.refinement might be what you're looking for, you could combine that with for example react-final-form. it is not depending on redux anymore. a form component of react-final-form wrapped by an @observer and using an action within onSubmit callback of it to actually persist the state has worked out well for me recently.
    1. MobX makes state management simple again by addressing the root issue: it makes it impossible to produce an inconsistent state.
    2. data needs to be normalized, referential integrity can no longer be guaranteed
    1. reactions bridge reactive and imperative programming
    2. Using observable is like turning a property of an object into a spreadsheet cell. But unlike spreadsheets, these values can be not only primitive values, but also references, objects and arrays.
    1. Still, you have the option of moving the state that you want to read immediately into some sideways mutable object, especially if you don’t use it as a source of truth for rendering. Which is pretty much what MobX lets you do
  4. Jun 2017
    1. "Lazy", "stale", "reactive". Lots of buzzwords.

      Here's a simple explanation for the fullName/nickName magic (fullName stops being watched if nickName exists):

      On every component render, Mobx registers all the attributes they've accessed on state, so it will trigger a forceUpdate on them whenever one of these attributes change.

      If at one render (when there's a nickname) some attribute is not accessed (fullName), the MobX will not register an access on that attribute, so subseqüent changes of that attribute will not trigger forceUpdates anymore.

      If for some reason that attribute (fullName) is accessed ever again (either due to nickName ceasing to exist or due to some other internal component logic) that value is simply given to the component and it starts to be observed again and to trigger forceUpdates again on that component.