hknd

I really want a heated cupholder now - how did I never hear for this before. This is a gamechanger.

Which will only get the price up for a short amount of time, it will be dumped after that anyway.

GME fundamentals haven't changed (much) - it's not worth much on paper, maybe $10, $20, $30?

Market behaves irrational rn, but at some point it will become rational again. And then GME stock will crash.

wow :cry:

Probably just re-using a footer component which wasn't updated yet

Literally the first thought which popped in my head.

Most of the stores not long-life objects.

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)

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.

Mobx is not a global state, you can create your stores as granular as you want them to.

Each widget can have a store, each section can have a store, each view can have a store, etc. You decicde what works for you.

(I use mobx in a large and complex trading application)

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.

notion.so