Exploratory Flow diagram:

https://github.com/UCSD/campus-mobile/issues/1918

Code Branch:

GitHub - xxwwyytt1/campus-mobile at flutter_hooks_experiment

Migration Demo code segments:

• [x] AvailabilityCard (Timothy)
• [ ] ShuttleCard (Timothy)
• [ ] ParkingCard (Karen)
• [x] NewsCard (Aven)
• [x] EventsCard (Aven)

February 4, 2023

• Services/providers are the main pain point of our code base because of the amount of code redundancy there → Replace those service files with hooks
  • useFuture + useMemoized hook for fetching & caching data
  • if data is streamed, useStream + useMemoized hook will suffice

February 5, 2023

• Hooks only reduces code redundancy but doesn’t do state management

  • looked into several state management tool together, certain library(get_it_hooks, riverpod) discussed and mapped in above lucid chart

    flutter_riverpod | Flutter Package

    get_it_hooks | Flutter Package

  • came into conclusion that we should keep provider because it's not doing anything more for us that our current providers are doing.

    • see the discussion 👇

      Discussion screenshots

February 7, 2023

• Timothy talked to Charles, and Charles preferred fquery / custom over other state management tool.
  • Next step:
    • Contact get_it_hooks to see if he can maintain the package (make the package up-to-date)
    • Contact fquery team to see how they are planning to maintain the package and if not, how can ITS team make a fork out of fquery and maintain our own state manager
• We will be developing hook migration + ❓state manager on the small set of class to polish our proposal. After the proposal is approved, then start the app-wise migration
• Implement availability_card.dart to a hookWidget. UseListenable for using provider and useMemoized.
  • Demo code:
• Next step: use hooks to replace service but we need either fquery / get_it_hooks to do that. So blocker is the contacting.