Data store improvements

[jonator]

Problem

The organization of our query and data stores was somewhat emergent from the organization of the chain queries and not planned at a high level. We have a lot of query stores that fetch and do highly-coupled compute on low-level chain data/primitives (notably gauges, locks, etc), then we have some data stores that wrap those query stores and do additional computations. Those data stores are not in the root store, but are created and used as needed, which may or may not be inefficient as the user navigates the pages, and sometimes causes us to repeat/copy&paste the computations (I've spotted this most noticeably in the various pool card views).

Proposed Solution

We may be able to remove a lot of repeated (or dead) code by investigating the following:

• Separate calculations from query stores. The query stores should simply query the data, and provide computed properties that return that data in a parsed format with clean TypeScript types that include parsed keplr-wallet/unit objects, Durations, Dates, etc.
  • We should create a document or FigJam that identifies all the view-dependent data models that we currently use, and we should collaborate on finding co-dependencies and then organizing them into logical data-oriented stores. Our focus should be on only performing calculations as needed for the user as they navigate the various views. Make heavy use of map stores. Some of this work already emerged in the pool details store and superfluid pool store.
  • We should move data stores into map stores in the root store. For example, the aforementioned pool detail store and superfluid pool store should be a map store from poolId->store in the root. If we do that alone, we could save computation as a user navigates to/from pool detail pages and pools/assets pages (for the pool cards on those pages). Furthermore, the pool cards could reference those stores for calculating the metrics on the various flavors of pool cards we have.
• New data stores could contain a hydration mechanism. Currently, from the pool query optimization/pagination work, the imperator pools query also contains a lot of attached asset price and pool liquidity data. Currently, to avoid anything hacky, we simply ignore those values and refetch them separately later (bearing the additional resource load for both this pools query and future imperator metrics queries). If we were to do this refactor with a hydration mechanism, we may be able to populate a lot of those values from the pools query store and avoid some querying later in the app lifecycle. In effect, we should have query stores be dependent on our data stores, as they should be loading data then "hydrating" (populating) the various relevant data stores. Note: the hydration mechanism proposed here would inverse the dependency relationship (data<-query) outlined in the query store computed property comment in the first bullet point.
• All query stores should only fetch data as needed. The base keplr-wallet MobX query store is very powerful (cancellation, caching, revalidation, stale requests, etc.) but it's default is to fetch from the provided endpoint when it is constructed/initialized, when the root store is initialized on app load. We should formalize (perhaps by creating our own base store) what was done in the new ObservableQueryFilteredPools class by only fetching data as it is requested by the views (by overriding the canFetch function). This let us avoid a full pools query in the pool detail page, amongst other areas. Though, some of our current query stores extend the HasMapStore which will only initialize a query store (and thus kick off a query) as keys are encountered (example, gauges). We may be able to leave those HasMapStore child query classes alone, but we should make sure we're only requesting data as needed with the rest of the query stores. To accomplish this, we could look into extending the HasMapStore in more places, as it results in a small amount of code to maintain.

[jonator]

Further, still, since we'd do this refactor it may be worth investigating using react-query to handle this work of fetching/caching/invalidating data, then we could use wrapper hooks as the data stores on the resulting query data. We could rest in peace knowing the data is only queried once in the app lifecycle. Then, we could remove the use of MobX entirely for managing queried data, though I still think it's useful for the UI config stores. This may let us remove the keplr-wallet/stores dependency entirely.

See this article: https://www.andronio.me/2021/11/15/migrating-from-mobx-state-tree-to-react-query/