TL;DR:
- "almost fast as native code for web browsers” - in case you wanna do some expensive computing without a server
- "Compiling Existing Applications for the Browser" - port existing code into the browser (eg cpp apps)
Using webasm as a general purpose platform for the execution of untrusted code is also pretty interesting - this might be within server side code or non-browser desktop apps.
Agreed - first thought that popped into my head. Second thought: Wait, don't I do that already? I mean - there are certain news sources that I explicitly avoid (or at least, don't trust at all). Others that I check all the time and trust a lot. Then there's a slew in between that I check periodically and somewhat trust.
As much as my knee jerk reaction is against this, I also am asking myself: how's it really different from my own behavior? (and should I re-evaluate my own behavior).
The way that mobx is advised to be used, that is/was documented by its author, promotes the usage of a rootStore, which has as members all the various granular store objects. Is this how your organisation's stores are constructed?
We used to have that but moved to an approach with multiple "rootStores" per self-contained route (sometimes we have more than 1 root store in such a scenario).
But we also have multiple smaller stores which are not connected to the root store.
Think: multiple not-connected trees where each node is a store.
I must agree that both approaches have pros and cons, e.g. passing down data down a long path of stores is annoying.
> how do your 'not connected' stores know when, say, a user logs out?
If they need this information, it can be passed in from above, or pulled from context. But unless the store and component need to stay mounted when user logs out, they might not need to do anything. There's nothing wrong with a local store being created by a component that receives props and provides them via constructor arguments.
> write code, bespoke to each object, to be able to reset these objects too?
I almost never do this, and nearly always create a new store when the component mounts. The combination of `useLocalStore`[1] with mobx-react-lite makes this straight forward. So per the above example, your component could `useLocalObservable(() => new Store(props.user))`
To be honest I don't understand why people use mobx this way. I mean short life store objects, populated by props, that are recreated every mount. Might as well just use React state and save the overhead. You might say, because I have several components using the same business logic and fields and such, I can inject the same store into multiple components. I would say that logic can go in functions which take React state as their argument. You don't need a global state management tool to separate business logic from the view.
> Might as well just use React state and save the overhead.
Unless you mean conceptual overhead (i.e another library), it should be less overhead with mobx because there's no need to re-create objects on every re-render, and further re-renders in general are less common (since mobx precisely controls renders for you). Also localStore's need not be short lived by definition, just local. I have a notes app where the main components localStore stays mounted for (literally) days :)
It's more overhead in the sense that mobx needs to walk all your store objects and check for changes, on top of what React does. Anyway that's fine if you really need that precision. I just useMemo at the 'hotspots' and that is enough. Remember also that if vdom diffing doesn't pick up a change, nothing is flushed out to the DOM, so whether an object is created or long-life doesn't matter in this sense.
> mobx needs to walk all your store objects and check for changes, on top of what React does.
I don't think that is quite correct. I think it keeps a mapping of observed properties and which React components rely on them. Then, changing any property becomes a lookup (not a walk) of who is observering, and a `forceRender` on the results. So if no components are observing the property, there's no further computation. Its not "on top of what React does" because it short-circuits it (like useMemo) -- except you don't have to hand-craft any useMemo comparators, it does that for you by tracking which properties you access.
The current store holding most of the displayed data stays alive (while not switching to a different route), but everything else resets or gets recreated when needed.
(no need to keep stores alive if they are not required or used)
Stores for specific "sub" views (think dialogs, tabs, collapsibles, ...) are getting created/destroyed ad-hoc.
Main Store for a specific view holds the current data (which receives updates via gql subscriptions ~every second), the current filter which is applied to it's children (only show Apple related securities) and currently visible/hidden state of any children.
User/App/Global related attributes which don't change often are stored in a globally available object (and is easy for us as users don't log out or anything)
no, do you have source for that? Mobx is built on the concept of atom which you can put anywhere in your app, be it a module, a context or a component.
The status dashboard is something which will be updated by an operations employee manually (yes by hand), who is a couple of layers behind the actual SWE/SRE who gets the page.
Google has multiple internal alerting systems and people are aware of any disruption/delay/anomaly from the minute it happens.
The on-caller for the specific service decides on how to produce.
The status dashboard is something which will be (manually, yes by hand) updated by an operations employee, who is a couple of layers behind the actual SWE/SRE who gets the page.
