4 ms·

I work in an infra team in a large codebase for Microsoft. We are the people who do the sort of bug-analysis to figure out what technologies work well and what

by inglor 5y ago

I work in an infra team in a large codebase for Microsoft. We are the people who do the sort of bug-analysis to figure out what technologies work well and what needs improvements. Hooks are a constant area of struggle and people make tons of mistakes (forgetting to cleanup a useEffect, useState closures, and needless useCallback are the top 3) with it. I dare say that if we didn't have MobX things would have been much much worse. The annoying bit is that other frameworks like Vue or Solid have MobX like Reactivity baked in which makes things much much simpler.

jitl 5y ago
How does Mobx help your code work better? Does it specifically salve hooks wounds, or just because you don’t need to manually manage subscriptions in a component? I’ve looked at Mobx and am concerned about mutation. I would like a magically reactive state container that always returns immutable views of the state for local usage. Maybe I should stop worrying and switch everything to Mobx.
- cloverich 5y ago
  Because you don't need to manage subscriptions, there's a whole class of hooks you don't need to write in the first place. Then on top of that, you get extremely good performance. Having to rarely think about hooks and basically never think about performance, for me, free's up tons of cognitive space to focus on the actual implementation of the UI. Its not a perfect system, but I haven't found another I'd rather use.
brundolf 5y ago
+1 for MobX, can't recommend it enough [also a quick shill for the general-purpose language I'm working on which internalizes that mechanism at the language level :)] https://www.brandons.me/blog/the-bagel-language https://www.brandons.me/blog/the-bagel-language
purplerabbit 5y ago
I only wish Mobx's API was terser and more opinionated. Hard to derive a good Mobx pattern from their bloated API (>100 exports) I've created a wrapper library which is basically a more-opinionated, higher-level version of Mobx if anyone is interested: https://www.npmjs.com/package/r2v https://www.npmjs.com/package/r2v
holler 5y ago
I was curious and indeed confirmed that ember.js/glimmer.js @tracked properties were inspired by MobX. From /u/wycats "The rule in Octane is: "mark any reactive property as @tracked, and use normal JavaScript for derived properties". That's pretty cool!" https://news.ycombinator.com/item?id=21848929 https://news.ycombinator.com/item?id=21848929
softfalcon 5y ago
MobX from a quick Google seems to resemble the old Knockout.js We use Relay to define our state management, trigger global updates across many components, and also query/mutate our data. Does MobX have a way to do the global state management that Relay does? I’m curious because after using Relay, I’ve found most other types of state management to feel extremely heavy with boiler plate code. Thoughts?
- brundolf 5y ago
  One of the great things about MobX is that it works on plain data and plain operations on that data [0], not just the contents of a sanctioned Store, which means it has no opinions about where you put your data. Local objects captured by closures? Cool. Classes? Great. Mutating arguments? Go for it. Global singleton? Have fun. [0] Technically, it wraps all the different data structures in Proxies etc as soon as they get assigned into an observable structure. But the goal is for you to never have to think about them as anything other than plain data, and that abstraction very rarely leaks.
  - softfalcon 5y ago
    Ah, that’s so cool! I will have to carve out some time to test this because that sounds really powerful and flexible!
    - brundolf 5y ago
      It is! It can be overkill for very simple React apps, but I used it to build a power-user tool a couple years ago that would have been impossible to do with Redux or hooks.
      - softfalcon 5y ago
        Hooks are never the solution for state on their own. They're more for localized to a single component state. That's why I brought up Relay (this is not the same as React, but works with React), cause it's what FB uses to stitch together global state between hundreds of different sub-components. That being said, Relay does NOT have a simple object interactive state ability. It's an obscure "external store" with weird querying and mutating rules that can feel quite difficult to work with at times.
eatonphil 5y ago
If Solid or Svelte had a way to import React components (for 3rd party code) and a documented migration path for 1st party code I'd be interested in switching.
erokar 5y ago
For me it seems React has made some unfortunate choices in an attempt to go FP in a language that does not afford it very well. Instead of embracing JS and working in alignment with its limitations/offerings, the React team has introduced elaborate workarounds that gives a whiff of FP but introduces indirection and verbosity and does not solve basic problems of state (i.e. the example from the blog post with classes vs. closures). I prefer frameworks like e.g. Svelte that works with what JS affords. If you want to go full FP Elm or ClojureScript will give you more value for your money than React imo.
- WorldMaker 5y ago
  FP is a wide spectrum and JS can do some FP well. I'd argue the issue with what React is attempting with hooks is not that it is FP, but it is an attempt at particular "higher-kinded" monads when JS today mostly just has basic support for simple kinded monads (Promises/thenables and async/await syntax). The types of monads that hooks want to be are advanced and require a bunch of extensions even in "big FP" languages like Haskell. (In theory, if the biggest concern was no do-notation in JS, you could approximate it with async/await syntax. The mental model of async/await might not make sense to what you were doing with it, but the dualism with do-notation should be valid. What Hooks are trying to be needs things like GADTs and other extensions in Haskell from my understanding.) To me, I still think Hooks are useful for making that big swing attempt in JS despite needing so many crutches like hard education spikes in the learning curve and so many linters, but the problem with Hooks is definitely not that they are "FP" but that they are advanced FP that even FP still hasn't figured out all the bugs.
  - jokethrowaway 5y ago
    Not sure what you mean by higher kinded monads but hooks are kind of like dumbed down Arrows. You'll see some similarities with the haskell libraries auto and netwire. I'm not a fan of the pure JS implementation the react team did, I wish they went the compiler way like solidjs did. It results in an API that is close enough to react and works faster and without gotchas (or hooks rules).

by inglor 5y ago

jitl 5y ago

How does Mobx help your code work better? Does it specifically salve hooks wounds, or just because you don’t need to manually manage subscriptions in a component? I’ve looked at Mobx and am concerned about mutation. I would like a magically reactive state container that always returns immutable views of the state for local usage. Maybe I should stop worrying and switch everything to Mobx.

cloverich 5y ago
Because you don't need to manage subscriptions, there's a whole class of hooks you don't need to write in the first place. Then on top of that, you get extremely good performance. Having to rarely think about hooks and basically never think about performance, for me, free's up tons of cognitive space to focus on the actual implementation of the UI. Its not a perfect system, but I haven't found another I'd rather use.

brundolf 5y ago

+1 for MobX, can't recommend it enough [also a quick shill for the general-purpose language I'm working on which internalizes that mechanism at the language level :)] https://www.brandons.me/blog/the-bagel-language https://www.brandons.me/blog/the-bagel-language

purplerabbit 5y ago

I only wish Mobx's API was terser and more opinionated. Hard to derive a good Mobx pattern from their bloated API (>100 exports) I've created a wrapper library which is basically a more-opinionated, higher-level version of Mobx if anyone is interested: https://www.npmjs.com/package/r2v https://www.npmjs.com/package/r2v

holler 5y ago

I was curious and indeed confirmed that ember.js/glimmer.js @tracked properties were inspired by MobX. From /u/wycats "The rule in Octane is: "mark any reactive property as @tracked, and use normal JavaScript for derived properties". That's pretty cool!" https://news.ycombinator.com/item?id=21848929 https://news.ycombinator.com/item?id=21848929

softfalcon 5y ago

MobX from a quick Google seems to resemble the old Knockout.js We use Relay to define our state management, trigger global updates across many components, and also query/mutate our data. Does MobX have a way to do the global state management that Relay does? I’m curious because after using Relay, I’ve found most other types of state management to feel extremely heavy with boiler plate code. Thoughts?

brundolf 5y ago
One of the great things about MobX is that it works on plain data and plain operations on that data [0], not just the contents of a sanctioned Store, which means it has no opinions about where you put your data. Local objects captured by closures? Cool. Classes? Great. Mutating arguments? Go for it. Global singleton? Have fun. [0] Technically, it wraps all the different data structures in Proxies etc as soon as they get assigned into an observable structure. But the goal is for you to never have to think about them as anything other than plain data, and that abstraction very rarely leaks.
- softfalcon 5y ago
  Ah, that’s so cool! I will have to carve out some time to test this because that sounds really powerful and flexible!
  - brundolf 5y ago
    It is! It can be overkill for very simple React apps, but I used it to build a power-user tool a couple years ago that would have been impossible to do with Redux or hooks.
    - softfalcon 5y ago
      Hooks are never the solution for state on their own. They're more for localized to a single component state. That's why I brought up Relay (this is not the same as React, but works with React), cause it's what FB uses to stitch together global state between hundreds of different sub-components. That being said, Relay does NOT have a simple object interactive state ability. It's an obscure "external store" with weird querying and mutating rules that can feel quite difficult to work with at times.

eatonphil 5y ago

If Solid or Svelte had a way to import React components (for 3rd party code) and a documented migration path for 1st party code I'd be interested in switching.

erokar 5y ago

For me it seems React has made some unfortunate choices in an attempt to go FP in a language that does not afford it very well. Instead of embracing JS and working in alignment with its limitations/offerings, the React team has introduced elaborate workarounds that gives a whiff of FP but introduces indirection and verbosity and does not solve basic problems of state (i.e. the example from the blog post with classes vs. closures). I prefer frameworks like e.g. Svelte that works with what JS affords. If you want to go full FP Elm or ClojureScript will give you more value for your money than React imo.

WorldMaker 5y ago
FP is a wide spectrum and JS can do some FP well. I'd argue the issue with what React is attempting with hooks is not that it is FP, but it is an attempt at particular "higher-kinded" monads when JS today mostly just has basic support for simple kinded monads (Promises/thenables and async/await syntax). The types of monads that hooks want to be are advanced and require a bunch of extensions even in "big FP" languages like Haskell. (In theory, if the biggest concern was no do-notation in JS, you could approximate it with async/await syntax. The mental model of async/await might not make sense to what you were doing with it, but the dualism with do-notation should be valid. What Hooks are trying to be needs things like GADTs and other extensions in Haskell from my understanding.) To me, I still think Hooks are useful for making that big swing attempt in JS despite needing so many crutches like hard education spikes in the learning curve and so many linters, but the problem with Hooks is definitely not that they are "FP" but that they are advanced FP that even FP still hasn't figured out all the bugs.
- jokethrowaway 5y ago
  Not sure what you mean by higher kinded monads but hooks are kind of like dumbed down Arrows. You'll see some similarities with the haskell libraries auto and netwire. I'm not a fan of the pure JS implementation the react team did, I wish they went the compiler way like solidjs did. It results in an API that is close enough to react and works faster and without gotchas (or hooks rules).