Week 5:

- [x] Begin looking into shared / monorepo options
- [ ] Evaluate beginning a Web migration branch..
- [ ] Go a bit further with React Native Testing Library setup and look for shared tools for setting up URQL and hook testing propertly in ways that are shareable with Web

Week 4:

- [ ] Complete Auth, Groups Drawer, Current Group Nav, Notifications List, and FeedList fetching through URQL while still extracting ReduxORM state
- [ ] Begin exploring best patterns for selection and enriching selection (i.e. "presenters", etc)

Week 3 - Ends 7/3:

- [x] Complete testing of 5.6.0
- [x] Release 5.6.0
- [ ] Add `useHyloMutation` to POC
- [x] Create `useQueryAction` which fetches via URQL and still extracts results to ReduxORM
- [x] Complete a POC from `AuthRootNavigator`, `Groups` and `GroupNavigation` using URQL but still selecting through ReduxORM
- [x] Explore data selection patterns (cache only vs fetch and cache, etc)
- [x] Configure URQL graphcache, etc
- [x] POC of loading of FeedList through `useQueryAction`
- [x] Refactor NotificationsList to functional components to reduce refactor diff
- [x] Refactor FeedList to functional components to reduce refactor diff
- [x] Update some tests to React Native Testing Library

Week 2:

- [x] App improvement pass: including load times and updating dependencies to latest, finalize and release proposals, i8n, anything else pending
- [x] Extend URQL POC for Post Detail to completion

Week 1:

- [x] Additional research related to these planning questions
- [x] Establish Mobile performance baselines

# Front-end data refactor

## I. Planning

1. Things that want/need done and released before starting major refactors:
* Look into over-querying to improve initial load time:
* Look into MeQuery overfetching (2-5 hrs)
* "We at least don't need to be loading groups, parent groups, groupTopics"
* Look into why Notifications query takes so long (3 seconds+), and if there is anything that can be done about it (2-5 hrs)
* Look into any other modest changes that can be made to improve initial load time
* not right now
* Merge (which) PRs?
* Proposals needs coordinate release
* i8n can be release independently
* Roles/Responsibilities probably doesn't need to be release coordination (in next ~1 week)
* Possible collective moderation POC incoming (within 4 months)
2. Can we progressively convert the app to the new URQL way?
* Given the expecations on the next 6 months, I am very concerned about the implications of making this large refactor blocking of most other feature work.
* Is it necesary to convert everything before releasing, or can the refactor be staged in some way? Any staging is going to require keeping ReduxORM and all its related pieces intact, while also having the URQL stuff somewhere. I think that is entirely possible, Akward, but potentially not so much so as to make it untenable or undesirable. It would be pretty valuable to be able to stay in a normal development > release lifecycle throughout.

4. Can we release HyloApp fully converted without converting Web?

* Generally my concern with the possible need to release web and mobile on the URQL refactor concurrently. It may be that we can bound the mobile refactor to not require any breaking graphql API changes, and that would make it unnecessary to have both web and the app ready at once. This however may be challening or confining in a way that forces us into hacks/work-around on the mobile refactor that may be counter productive to the spirit of "getting it all just right". That however might be the right compromise, and either way the place to start. We can then decide on something can wait to address until (if) the need to change the backend server appears in the course of the refactor.
* Secondarily, but related, is that I think we should consider switching to a monorepo for at least the front-ends, and likely also node, early in this project. This will put the things in place to be sharing all the to-be-shared grapqhl and URQL in the right place from the start, which I think is important.

## II. Establishing performance baseline:
* Total load time and data load time of initial load with an authenticated user with several groups, and navigating intitially to a large group
* Log query timing directly from graphql/ api Redux middleware to new log file...?
* Can I get Chrome Hermes profiling to include network requests
* Try Reactatron

## III. URQL POC

### graphql / URQL stuff
* How much can I convert into URLQ while leaving existing queries and ReduxORM stuff intact? Likely start URQL in its own new graphql root (graphql_urql) for clarity for now.
* Make a Redux / ReduxORM bridge from URQL graphql calls and attempt to move all fetching to URQL without yet re-writing selecting through ReduxORM?
* * Query and mutation naming scheme: CurrentUser, Stream, Fragments?
* When to use fragments, and which fragments to use: UserFragment, GroupFragment
* Do I need to explicitely use the `gql` tag or is that ok to let URQL manage?
* Should I perist URQL state in the POC? Feature flag it?

### Subscriptions support

* It is good that we have Yoga no hylo-node. We should probably explore what it take to move from 2.x to 3.x (latest) Yoga and turn on subscription support there. It may be helpful to deprecate some of our customizations of how we load things there and make them more Yoga-spec.. TBD.
* It might not be too hard, and basic Yoga subcription funcitonality MAY work to deprecate our current WebSockets implementation without a lot of effort. Fingers crossed.

## IV. Monorepo
* Check-out NX
* Dev workflow: Do we move forward always devloping and releasing Web and Mobile features in tandem? It would of course be important to support exceptions to this rule, but if the rule was to release in parity it likely better than the opposite...
* Other benefits
* Defacto open-sourcing of the mobile app (and desktop, unless we still want to keep that wrapped)
* The above makes it easier to get open source contributors to the mobile app

## V. For later
* Sentry monitoring for most impactful bugs
* Tree-shaking to reduce bundle-size (MS built a [metro plug-in for that](https://microsoft.github.io/rnx-kit/docs/guides/bundling#tree-shaking))
* Speaking of bundle-size... Switching away from moment would be an obvious win there. Its in our yarn.lock
* Lodash as a whole is imported and we could just `lodash/isEmpty` etc instead
* I'm sure there are a few others we could squeeze here
* An extra bundle minizing process is available for Android: ENABLEPROGUARDINRELEASEBUILDS (We currently have it set to false)
* [FlashList](https://shopify.github.io/flash-list/) (if needed!) for some drop-in replacements of FlatList
* Custom animations (for very fancy stuff...) [Rive intro](https://rive.app/community/doc/introduction/docvphVOrBbl)
* Find unused deps (npx depcheck)
* End-to-End testing (smoke tests) https://github.com/wix/Detox
* Pick a couple of key interaction flows