Jon Ator

Implementation idea * Extend `ObservableChainQuery` as `ObservableSSRChainQuery` for non-account query objects * Create an interface, `SSRStore`, that generically describes the ability to fetch and accept API data * Extend `RootStore`...

Re Research: when second+ page is fetched via `'next/link'` or `'next/router'`, `getServerSideProps` _is_ run on the new page. We now have 2 options: * We should avoid loading data on...

Re Research: for second bullet: Currently, our js bundle for every page is quite large at 1.7mb. We should investigate splitting the root store for stores on each page. Then,...

[Next.js + Mobx article](https://dev.to/ivandotv/mobx-server-side-rendering-with-next-js-4m18) May be semantically more correct to refer to store population as "hydration" as Next.js does.

Seems webpack tree shaking is unable to drop @ethereumjs/common & @ensdomains/resolver Perhaps a change to @keplr-wallet would help. We need [these](https://webpack.js.org/guides/tree-shaking/#conclusion) properties to allow for tree shaking.

In response to "Implementation idea" bullets: * `ObservableChainQuery` exposes `async waitFreshResponse()` and `setResponse()`, so an `*SSR*` interface/class would not provide functionality, and would just add complexity * ""

Iceboxing as we decided to optimize performance of pools page w/ React alone. If the Osmosis all pools query is fast, the page will also be fairly fast. We should...

We should look into adding a fun game while users are waiting -> http://www.sunnya97.com/osmo-runner/

- [ ] Look into ways to incorporate chain registry as we work on this project #158 #63 - [ ] Revert hardcoded frontier work (https://github.com/osmosis-labs/osmosis-frontend/pull/488/commits/9a16a0cac8b005e23c1b8be6669be9d30c60f777) by making "Frontier" it's...

5/31 meeting - this may be deprioritized and kicked down the road. With the frontier site and the asset/pools filter/sorting, it's harder to justify such a large overhaul to the...